MS Windows NT Server 4.0 Internet Guide

Microsoft Corporation

The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted.

Microsoft may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft.

© 1996 Microsoft Corporation. All rights reserved.

Microsoft, MS, ActiveX, BackOffice, MS-DOS, MSN, Visual FoxPro, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

AppleTalk and Macintosh are registered trademarks of Apple Computer, Inc.

AS/400, DB2, OS/2, RPG/400, and VM/ESA are registered trademarks and ES/9000 is a trademark of International Business Machines Corporation.

DEC, Digital Alpha Systems, PATHWORKS, and VMS are trademarks of Digital Equipment Corporation.

Intel and Pentium are registered trademarks and EtherExpress is a trademark of Intel Corporation.

UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd.

Other product and company names mentioned herein may be the trademarks of their respective owners.

Document No. xxxx
12345-6

Printed in the United States of America.

This book is dedicated to Windows NT Webmasters around the world.

Contributors to this book include the following:

Technical Writers:

Peggy Etchevers, Jeff Howard, Laura Sheppard, Maureen Sullivan,

Technical Consultants:

Greg Allen, Noland Angara, Carl Calvello, Ty Carlson, Doug Hebenthal, Jerry Hittle, Cliff Hudson, Aaron Lee, Richard Lerz, Ryan Marshall, Sam Patton, Lester Waters, Valerie Whitcomb, Jim Yagelowich, and numerous other hardworking Windows NT Developers, Program Managers, and Product Support Specialists

Technical Editor:

Kate Robinson

Managing Editor:

Sonia Marie Moore

Software Program Managers:

Louis Kahn, Ryan Marshall

Software Developer:

Martin Holladay

Writing Manager:

Peggy Etchevers

Product Support Liaison:

Todd Hafer

Technical Marketing Liaison:

Ty Carlson

Indexers:

Jane Dow, Barbara Sherman

Production Team:

Karye Cattrell, Nikole Faith, Jay French, Patrick Ngo, Cathy Pfarr, Keri Segna, Jeff Weaver, Todd White

Lead Graphic Designer:

Chris Blanton

Design Support Team:

Johnni Cutler, Amy Iffland, Casey McGahan, Wendy Salvatori, Gabriel Varela, Sue Wyble, Jan Yeager


Introduction

Welcome to the Microsoft® Windows NT® Server Resource Kit: Windows NT Server Internet Guide.

The Microsoft Windows NT Server Resource Kit for version 4.0 consists of three new volumes and a single compact disc (CD) containing utilities for both Windows NT Workstation and Windows NT Server. An online version of the new, comprehensive Windows NT Workstation Resource Guide is also available on the CD. Update books for the Windows NT Server Resource Kit will be released on a semi-annual basis. They will contain new information and major revisions of existing topics.

The Windows NT Server Internet Guide presents detailed information on the Microsoft Internet Information Server, some scenarios for its use on the Internet/intranet, descriptions of Internet-related tools provided on the Windows NT Server Resource Kit CD, and suggestions for troubleshooting. Update books will contain more extensive Internet-related information. Some of the scenarios provided here use a fictitious company, Terra Flora, as an example to demonstrate challenges and solutions. The Terra Flora network is based on a real network that has been created at Microsoft in the Windows NT Server Resource Kit Interoperability Lab. The networking model that Terra Flora will implement is shown in the network diagram on the inside back cover of this book.

This information is intended to be a technical supplement to the printed and online documentation included as part of the Windows NT Server version 4.0 product. It does not replace that information as the source for learning how to use the product features and utilities. It is also supplementary to the networking information presented in the Windows NT Server Networking Guide.

This Introduction includes the following types of information you can use to get started.

  • The first section outlines the contents of this book, so that you can quickly find pertinent technical details.
  • The second section introduces the Windows NT Server Resource Kit CD.
  • The third section describes the support policy for the Windows NT Server Resource Kit.


About the Windows NT Server Internet Guide

This book includes the following chapters.

Chapter 1, "Internet Information Server Architecture," provides an overview of the architectural structure of Microsoft Internet Information Server (IIS) and a foundation for understanding the technical concepts presented in the following chapters.

Chapter 2, "Connecting Windows NT Server to the Internet," provides a conceptual overview of the requirements for connecting to the Internet.

Chapter 3, "Server Security on the Internet," describes Internet Information Server authentication and security and then illustrates secure topology configurations for connecting to the Internet.

Chapter 4, "Desktop Scenarios," presents IIS intranet scenarios that use single computers and describes their configuration running Peer Web Services (PWS) and Internet Information Server.

Chapter 5, "Enterprise Scenarios," presents IIS intranet scenarios involving simulated or multiple servers and describes their configuration using IIS virtual servers, IIS database applications, and the IIS FTP service..

Chapter 6, "Internet Connectivity Scenarios Using the Remote Access Service," presents scenarios that use the Windows NT Remote Access Service to provide remote clients access to the Internet.

Chapter 7, "Internet Tools," describes Windows NT Server Resource Kit utilities and Microsoft products that can be installed on a Microsoft Internet Information Server to provide a variety of information publishing services.

Chapter 8, "Troubleshooting an Internet Information Server Installation," presents troubleshooting tips that are useful for both IIS and PWS.

Glossary of Internet-related terms used in this book.

Index to this Windows NT Server Internet Guide.


Resource Kit Compact Disc

The Windows NT Server Resource Kit CD includes a wide variety of tools and utilities to help you work more efficiently with both Windows NT Workstation and Windows NT Server. Notes describing some of the enhancements made to the existing tools and utilities and introducing new ones that have been added for this version 4.0 release are provided in the Introduction to the Windows NT Server Resource Guide.

The CD that accompanies the Windows NT Server Resource Kit contains utilities that apply to information in the Windows NT Workstation Resource Guide, the Windows NT Server Resource Guide, the Windows NT Server Networking Guide, and the Windows NT Server Internet Guide. This new CD replaces all previous ones. It includes a collection of information resources, tools, and utilities that can make networking and working with the Windows NT platform even easier.

Note

The utilities on this CD are designed and tested for the U.S. version of Windows NT version 4.0. Use of these utilities on any other version of Windows NT may cause unpredictable results.

A large Help file with explanations and user actions for the majority of the messages included in Windows NT version 4.0, and a large Help file of Performance Counter Definitions are just two of the major items included on the Windows NT Server Resource Kit CD. Updates to these files and others will be provided, when available, on the Microsoft Internet web site for the Windows NT Resource Kits. See the Rktools.hlp file for the exact site address, as well as the addresses of other Microsoft information sites.

After installing the Windows NT Server Resource Kit, please refer first to the following three files.

  • The Readme.wri file, which contains a complete list of all the tools and utilities on the Windows NT Server Resource Kit CD and additional setup instructions for some of them.
  • Either the Rkdocw.hlp (for Windows NT Workstation) or the Rkdocs.hlp (for Windows NT Server) file, which provides a single entry point for all of the major components of the Resource Kit's online documentation.
  • The Rktools.hlp file, which provides an overview of the Resource Kit tools and utilities and basic instructions on how to use many of them, along with links to additional documentation and, in some cases, to the actual program files.

The most current corrections to those tools and utilities and their documentation, as well as the POSIX and Perl source code files, are available on the Internet at the following Microsoft FTP site.

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt40/


Resource Kit Support Policy

The SOFTWARE supplied in the Windows NT Server Resource Kit is not officially supported. Microsoft does not guarantee the performance of the Window NT Server Resource Kit tools, response times for answering questions, or bug fixes to the tools. However, we do provide a way for customers who purchase the Windows NT Server Resource Kit to report bugs and receive possible fixes for their issues. You can do this by either sending Internet mail to RKINPUT@MICROSOFT.COM or by referring to one of the options listed in the Start Here book, which is included with your Windows NT Server product. This mail address is only for Windows NT Server Resource Kit related issues.

The SOFTWARE (including instructions for its use and all printed and online documentation) is provided "AS IS" without warranty of any kind. Microsoft further disclaims all implied warranties, including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the SOFTWARE and documentation remains with you.

In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the SOFTWARE be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the SOFTWARE or documentation, even if Microsoft has been advised of the possibility of such damages.


Chapter 1 - Internet Information Server Architecture

Microsoft Internet Information Server is a network file and application server included with the Microsoft Windows NT Server operating system.

This chapter explains design principles and the architecture behind Internet Information Server. Internet Information Server supports three information protocols: HTTP, FTP, and Gopher. This chapter explains how these protocols work with Internet Information Server and how to configure their operation.


Internet Information Server Design Priorities

The design goal for Internet Information Server was to build a set of integrated server services to support File Transfer Protocol (FTP), Gopher, and Hypertext Transport Protocol (HTTP) services.

Internet Information Server is designed for maximum performance, integration, and extensibility.

  • Performance. Internet Information Server maximizes speed while using the minimum amount of memory (RAM). Internet Information Server uses approximately 400K of RAM when running all three services (HTTP, FTP, Gopher).
  • Integration. Internet Information Server is integrated with Microsoft Windows NT Server. Internet Information Server uses the same directory database (user accounts) as Windows NT Server. Using the same directory database eliminates the need for additional user account administration. Internet Information Server administration also uses existing Windows NT Server tools such as Performance Monitor, Event Viewer, and Simple Network Management Protocol (SNMP) support to maintain similar administrative procedures.
  • Extensibility. Internet Information Server is extensible. Internet Information Server supports the Internet Server Application Programming Interface (ISAPI). By using ISAPI you can extend the functionality of the HTTP service: You create programs that can preprocess and postprocess data sent to and from Internet Information Server. ISAPI is also used in Internet Information Server to create connectors, such as the Internet Database Connector. Internet Information Server uses connectors to use the services of other servers, such as ODBC databases.


Architecture Overview

All of the standard Internet services (FTP, Gopher, and HTTP) reside in a process called Inetinfo. This process is about 400K in size. In addition to the Internet services, this process contains the shared thread pool, cache, logging, and SNMP services of Internet Information Server.


Internet Information Server Connectors

Extensions are built into Internet Information Server in the form of connectors. A connector is an ISAPI dynamic-link library (DLL) that acts as a communication pipe between Internet Information Server and a service. The following connectors are supported.

  • Microsoft BackOffice™ connectors
    • Microsoft Exchange Server/Web connector supports public folder integration with Internet Information Server.
    • Internet Database Connector (IDC) connector allows communication with any ODBC-compliant database engine.
  • Common Gateway Interface (CGI) was developed for UNIX-based systems to extend Web server software. Internet Information Server supports CGI applications for backward compatibility.
  • ISAPI filters preprocessing packets before they enter or leave the Internet Information Server process. These filters give added flexibility to the Internet Information Server architecture. Secure Sockets Layer (SSL) is one example of an ISAPI filter.


Internet Service Manager

Internet Service Manager enables administrators to manage many Internet Information Server sites from a single location anywhere on the Internet. Internet Service Manager communicates by using remote procedure calls (RPCs). Internet Information Server can be used locally or remotely because of its support for RPCs.


Logging

Internet Information Server logging enables you to track which users access your site and when they access your site. Tracking users helps to identify security and performance issues. Logging can be directed either to a log file that can be processed offline and offers faster performance, or to an ODBC Data Source Name (DSN) for dynamic evaluation.


WWW Service

The World Wide Web (WWW) service uses the Hypertext Transport Protocol. HTTP is implemented through an interface to Windows Sockets. Internet Information Server version 2.0 (included with Windows NT Server version 4.0) supports HTTP version 1.0.

The Hypertext Transport Protocol is an application-level protocol. HTTP is a distributed, collaborative, hypermedia information system that has been in use since 1990. HTTP technology has enabled what most commonly refer to as the World Wide Web.

HTTP grew out of a need for a universal protocol to simplify the way users access Internet information. HTTP is generic, stateless, and object oriented. It can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). Because HTTP types and negotiates data representation, systems based on it can be built independently of the data being transferred.

The current specification reflects common usage of the protocol referred to as HTTP/1.0, and is the basis for the information in this section.

Discussion and improvement of the HTTP standard is ongoing. You can find extensive information about HTTP at the Internet address http://www.w3.org/pub/WWW/.


HTTP Communication Process

Hypertext Transport Protocol is a client/server protocol. This means that the client and server interact to perform a specified task. For example, when a user clicks a link on a Hypertext Markup Language (HTML) page, it apparently causes that page to be replaced with the new page. What actually happens is more complex.

  1. The client browser uses HTTP commands to communicate with the HTTP server.
  2. A connection is established from the client to the server by means of TCP port 80 (the default).
  3. The request message is sent to the server. The requests are typically for a file consisting of images, audio clips, animation clips, video clips, or another hypertext document.
  4. The server sends a response message with the requested data to the client.

For example, when the user clicks a link on an HTML page, the data in the response message comprises the code used to build the page on the client computer.

  1. The server (in most cases) closes the connection.

Table 1.1 defines some of the terms used to refer to the roles played by participants in, and objects of, the HTTP communication process.

Table 1.1 Terms Used in HTTP Communication

Term | Meaning
connection | A virtual circuit (in the transport layer) established between two application programs for the purpose of communication.
message | The basic unit of HTTP communication. It consists of a structured sequence of octets and is transmitted through the connection.
request | An HTTP request message.
response | An HTTP response message.
resource | A network data object or service that can be identified by a URL.
entity | The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body.

HTTP Requests

The Simple-Request message to the server is sent in the form of a request method, Uniform Resource Locator (URL), and protocol version. The following is an example of an HTTP request.

get http://www.w3.org/hypertext/WWW/TheProject.html HTTP/1.0

This request uses the elements described in Table 1.2.

Table 1.2 Elements of an HTTP Request

Element | Purpose
get | Specifies the request type.
http: | Specifies the request protocol.
//www.w3.org/hypertext/WWW/TheProject.html | States URL for the object requested.
HTTP/1.0 | Indicates that version 1.0 of HTTP will be used.

In a Full Request message, the additional information is followed by a Multipurpose Internet Mail Extensions (MIME) message containing request modifiers, client information, and sometimes body content.

HTTP Server Response Messages

When an HTTP server receives a request, it responds with a status message that includes the message's protocol version and a success or error code, followed by a MIME message containing server information, entity metainformation, and sometimes body content.

Table 1.3 lists examples of server status messages and their meanings. For more information, see Chapter 8, "Troubleshooting an Internet Information Server Installation."

Table 1.3 Explanations for Server Status Messages

Message | Type | Explanation
1xx | Informational | This series of responses is not currently used. They are reserved for future use.
2xx | Success | The action was successfully received, understood, and accepted.
3xx: | Redirection | Further action must be taken in order to complete the request.
4xx | Client Error | The request contains incorrect syntax or cannot be fulfilled.
5xx | Server Error | The server failed to fulfill an apparently valid request.


URLs

In all Internet protocols, including HTTP, a client must locate Internet resources by using a Uniform Resource Locator. The URL for an HTTP address can be broken into three parts.

  • How (scheme). Defines how the request is made. When the HTTP scheme is used, network resources are located by means of the Hypertext Transport Protocol.
  • Where. Defines the host.
  • What. Specifies the complete path to the object and the object's name that is being requested by the client.

For example, this is the syntax for a URL that uses the HTTP scheme:

http: //host[:port]abs_path

where

host

A legal Internet host domain name or IP address (in dotted-decimal form), as defined by Section 2.1 of RFC 1123.

:port

Port 80 is used if no port is specified. However, by using this optional parameter, you can specify any port.

abs_path

The full path and filename.

The type of scheme used depends upon the object being requested. The following schemes are currently supported by Internet Explorer.

File | Mailto | Telnet
FTP | News | WAIS
Gopher | NNTP |
HTTP | Prospero |

For more information about these and other schemes, see the Internet address http://www.w3.org/pub/WWW/Addressing/schemes.html.


HTTP Browser

On the client side, the browser issues a command when the user either clicks an object or types a URL in the location field.

Included with Microsoft Internet Information Server is a browser (Microsoft Internet Explorer) you can use to access Internet sites. After you connect to the Internet, you can use Internet Explorer to view information on the Internet. You can incorporate this information into your documents, or save it to a file on your computer.

To begin exploring the Internet, click an item in the Internet Explorer main window.


Monitoring HTTP Sessions

You can monitor HTTP sessions by using the netstat TCP/IP utility and the Performance Monitor.

The netstat utility shows static information at a given point in time. Netstat is best used to determine the status of connections. Table 1.4 provides examples of netstat syntax and the results of each.

Table 1.4 Netstat Command Examples

Example syntax | Result
netstat | Displays protocol (TCP or User Datagram Protocol) being used, local and foreign (remote) addresses by their friendly names, the port number used on the local computer, and the state of the connection.
netstat -n | Displays protocol (TCP or UDP) being used, local and foreign socket addresses, and the state of the connection.
netstat -s -p tcp | Displays active opens, passive opens, failed connection attempts, reset connections, current connections, segments received, segments sent, and segments retransmitted.

For more information on the netstat utility, see the online Command Reference in Windows NT Help.

Performance Monitor shows events happening in real time. Performance Monitor is best used to check the status of users. Table 1.5 shows real-time statistics that Performance Monitor displays for HTTP as well as FTP and Gopher.

Table 1.5 Statistics Displayed by Performance Monitor

Counter | HTTP service | Objects for FTP service | Gopher service
Aborted Connections | NA | NA | ü
Bytes Received/sec | ü | ü | ü
Bytes Sent/sec | ü | ü | ü
Bytes Total/sec | ü | ü | ü
CGI Requests | ü | NA | NA
Connection Attempts | ü | ü | ü
Connection/sec | ü | NA | NA
Connections in Error | NA | NA | ü
Current Anonymous Users | ü | ü | ü
Current CGI Requests | ü | NA | NA
Current Connections | ü | ü | ü
Current ISAPI Extension Requests | ü | NA | NA
Current NonAnonymous Users | ü | ü | ü
Directory Listings Sent | NA | NA | ü
Files Received | ü | ü | NA
Files Sent | ü | ü | ü
Files Total | ü | ü | NA
Get Requests | ü | NA | NA
Gopher Plus Requests | NA | NA | ü
Head Requests | ü | NA | NA
ISAPI Extension Requests | ü | NA | NA
Logon Attempts | ü | ü | ü
Maximum Anonymous Users | ü | ü | ü
Maximum CGI Requests | ü | NA | NA
Maximum Connections | ü | ü | ü
Maximum ISAPI Extension Requests | ü | NA | NA
Maximum NonAnonymous Users | ü | ü | ü
Not Found Errors | ü | NA | NA
Other Request Methods | ü | NA | NA
Post Requests | ü | NA | NA
Searches Sent | NA | NA | ü
Total Anonymous Users | ü | ü | ü
Total NonAnonymous Users | ü | ü | ü


Modifying HTTP Ports

For most installations of Internet Information Server, you keep the HTTP server port number set at the default 80 to allow HTTP clients access to your site. However, it is simple to modify the well-known (standard) port numbers for HTTP.

Warning

Using Registry Editor incorrectly can cause serious, systemwide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

When possible, change configuration through Control Panel settings. However, as in the procedure that follows, there are settings that can be changed only by using Registry Editor.

To change the port used by the HTTP service

  1. Start the Registry Editor, Regedt32.exe.
  2. Click the HKEY_LOCAL_MACHINE window and locate the following key:

\System

\CurrentControlSet

\Control

\ServiceProvider

\ServiceTypes

\W3SVC

  1. Click W3SVC, then double-click the TcpPort entry on the right side of the screen.

The DWORD Editor dialog box appears.

  1. Click Decimal, then enter the port number in the Data box.
  2. Click OK and close Registry Editor.
  3. Stop and restart the WWW service.

Your HTTP server now monitors the specified port for all HTTP client requests.

Note

This situation affects the default port on the HTTP server only.


Troubleshooting HTTP with Netmonitor

By using the Microsoft netmonitor utility, you can reveal the contents of a specific frame. By examining the HTTP messages, you can determine whether the correct messages were sent.

Netmonitor captures the full frame before it reaches the network components and the browser client. Thus, you can isolate the symptoms of events that occur before the frames reach the host computer.

For more information about netmonitor, see the Windows NT Server Concepts and Planning Guide.


FTP Service

FTP is the protocol used to transfer files between two computers on a network that uses Transmission Control Protocol/Internet Protocol (TCP/IP). FTP was one of the earliest protocols used on TCP/IP–based networks and the Internet. Although the World Wide Web has replaced most functions of FTP, FTP is still the only way to copy files from a client computer to a server over the Internet.

To use FTP to transfer files between two computers, both computers must support their respective FTP roles. In other words, one needs to be an FTP client and the other an FTP server. The FTP client can issue commands to the server, such as commands to download files, upload files, create directories on the server, and change directories on the server.

FTP uses TCP as its transport protocol for all communication and data exchanges between the client and the server. However, Internet Information Server communicates with Windows Sockets, then Windows Sockets communicates with TCP.

TCP is a connection-oriented protocol. "Connection-oriented" means that the communications session is established between the client and the server before data is transmitted. The connection remains active during the entire FTP session. Connection-oriented sessions are known for their reliability and error-recovery features. This means that FTP file transfers are very reliable.

TCP has the features described in Table 1.6.

Table 1.6 TCP Connection Features

Feature | Description
Flow control | Both client and server computers participate in the transmission of the packets, which virtually eliminates potential problems with packet overflows and lost packets.
Acknowledgment | The computer sending data packets expects an acknowledgment message (ACK) from the destination computer. This acknowledgment verifies that the packet was successfully received at the destination.
Retransmission | If the sending computer does not receive an ACK in a specified period of time, it assumes the packet became lost or corrupted and retransmits the packet.
Sequencing | All packets are numbered and sent in order so that the receiving computer reorganizes the data correctly.
Checksum | All packets contain a checksum to ensure integrity of the data. If the data is corrupted somewhere during the transmission, the checksum is used to indicate that the data is not the same data that was sent.

Note

Do not confuse FTP with Trivial File Transfer Protocol (TFTP). TFTP is a fast, simple file transfer protocol that uses the User Datagram Protocol (UDP) transport. UDP, unlike TCP, is a connectionless protocol and cannot retransmit packets. This means that UDP is not as reliable as TCP.


TCP Ports and Sockets

Three identification numbers are commonly used when referring to TCP sockets.

  • The IP address identifies the computer on the network.
  • The TCP port number identifies a process or application inside the computer.
  • The socket identifies both the computer and the process simultaneously. A socket is used as an endpoint.

Note

TCP ports are known by a variety of names. These names include TCP port number, TCP port address, TCP port, port number, port address, port, and data port.

Any application or process that uses TCP for its transport is assigned a unique identification number called a TCP port. TCP ports specify the path of communication between client and server applications. These ports are numbered beginning with zero. Port numbers for client applications are dynamically assigned by the operating system when there is a request for service. Port numbers for server applications are preassigned by the Internet Assigned Numbers Authority (IANA) and do not change.

IANA is the group that assigns processes to port numbers 0 through 1023. This range of numbers is reserved for services. A client application or process that uses TCP as a transport is assigned a port number greater than 1023 by the operating system.

A server application or process that uses TCP as a transport has at least one preassigned port number. For example, the preassigned port numbers for FTP server services are 20 (data) and 21 (control). These port assignments are called the "Well Known Port Numbers" and are documented in RFC 1700 (see http://ds.internic.net/std/std2.txt). Table 1.7 is a short list of some Well Known Port Numbers. (For more port numbers, see Appendix B, "Port Reference for Microsoft TCP/IP," in the Windows NT Server Networking Guide.)

Table 1.7 Some Well Known Port Numbers

Port number | Process name | Description
1 | TCPMUX | TCP Port Service Multiplexer
5 | RJE | Remote Job Entry
20 | FTP-DATA | File Transfer Protocol - Data
21 | FTP | File Transfer Protocol - Control
23 | TELNET | Telnet
25 | SMTP | Simple Mail Transfer Protocol
42 | NAMESERV | Host Name Server
49 | LOGIN | Login Host Protocol
53 | DOMAIN | Domain Name System
69 | TFTP | Trivial File Transfer Protocol
70 | GOPHER | Gopher
80 | HTTP | HTTP
103 | X400 | X.400
110 | POP3 | Post Office Protocol version 3
137 | NETBIOS-NS | NetBIOS Name Service
139 | NETBIOS-DG | NetBIOS Datagram Service
150 | NETBIOS-SS | NetBIOS Session Service
156 | SQLSRV | SQL Server
179 | BGP | Border Gateway Protocol

Port numbers are used in conjunction with an IP address to form a socket. Sockets always have a number (or address) associated with them and designate an endpoint. Examples of socket numbers are shown in Table 1.8.

Table 1.8 Socket Examples

IP address | Port number | Socket number
10.155.22.99 | 1028 | #10.155.22.99(1028)
172.16.16.10 | 21 | #172.16.16.10(21)


FTP and Ports

When FTP is running on a server, it constantly monitors port 21, the FTP control port, for a request for service from the FTP server. To connect to the FTP server, the FTP client computer sends a request to TCP port number 21 on the server computer.

For example, assume that computer A is the FTP client, computer B is the FTP server, and that they have the following IP addresses.

Computer A (FTP client) | Computer B (FTP server)
IP address: 172.16.16.10 | IP address: 10.155.22.99

The communication between the FTP client and FTP server follows this process.

  1. At the command prompt on computer A, the user types the following information:

FTP 10.155.22.99

  1. The operating system assigns a TCP port number greater than 1023 (for example, 1028) to the FTP client application.
  2. TCP creates a packet that includes the following information:

Source IP Address | 172.16.16.10
Source TCP Port Number | 1028
Destination IP Address | 10.155.22.99
Destination TCP Port Number | 21

  1. The packet is sent across the network to IP address 10.155.22.99.
  2. Computer B receives the packet and TCP forwards the packet to port 21 (FTP control).
  3. The FTP service on computer B sends an acknowledgment (ACK) back to computer A by using both the IP address (172.16.16.10) and the port number (1028).

The packet cannot be accidentally delivered to a wrong port address on the server because the packet contains the correct port number before it leaves the client computer.


FTP Control and Data Connections

FTP uses two TCP connections to communicate between the client and the server. These connections are called the control connection and the data transfer connection. Connections can be ready in one of two states: passive open (waiting for a transmission) or active open (initiating the transmission).

The control connection starts the communication between the FTP client and the FTP server. The control connection is maintained for the duration of the FTP session. The control connection uses port 21 on the server and an open port that is greater than 1023 on the client.

The control connection is managed by a set of programs called the server Protocol Interpreter (server-PI) and the user Protocol Interpreter (user-PI).

The server-PI maintains a passive open state at port 21 waiting for the arrival of an FTP connection request from a client. When a request arrives, the server-PI establishes a control communication connection, receives standard FTP commands from the user-PI, sends replies, and governs the server Data Transfer Process (server-DTP).

The user-PI initiates the control connection (active open) from its TCP port to the server-PI, initiates FTP commands, and governs the user Data Transfer Process (user-DTP).

The data transfer connection exists only when there is data to be transferred between the client and the server. The data transfer connection closes each time a data transfer is completed. The control connection remains open.

Because of this, a new client data port must be opened each time a new data transfer begins. The server data port is always 20.

The data transfer connection is managed by a set of programs called the server Data Transfer Process (server-DTP) and the user Data Transfer Process (user-DTP). The server-DTP establishes the data connection (active open) with the user-DTP, sets up the parameters for transfer and storage, and transfers data on command from the server-PI. The user-DTP waits at its FTP port (passive open) for a connection from the server-DTP.


Using FTP

This section describes a typical FTP session.

To start an FTP session and connect to an FTP server

  1. Start a command prompt and type the following information:

ftp IPaddress

where IPaddress is a valid IP address. Then press Enter.

Note To test TCP/IP on your computer, you can always use the IP address 127.0.0.1. This address is known as the loopback address for your computer. The loopback address uses loopback drivers to reroute outgoing packets back to the source computer. By going through the loopback drivers, the packets can bypass the network adapter card completely and be returned directly to the computer that is performing the test.

  1. When you are prompted to log on with a user name, log on as Anonymous.
  2. When prompted for a password, press enter. An ftp> prompt appears.

At the ftp> prompt, you can enter FTP commands. Some of the common FTP commands are described in Table 1.9. (For a complete list of FTP client commands, see Appendix A, "TCP/IP Utilities Reference," of the Windows NT Server Resource Kit Networking Guide.)

Table 1.9 Common FTP Commands

Command | Purpose
bye | Ends the FTP session with the remote computer and exits FTP.
delete | Deletes files on the remote computer; requires appropriate permissions.
dir | Lists the remote directory's files and subdirectories.
get | Copies a remote file to your computer.
help | Displays descriptions for FTP commands.
open | Connects to the specified FTP server.
put | Copies a file from your computer to the remote computer; requires appropriate permissions.
mkdir | Creates a directory on the remote computer, requires appropriate permissions.
! | Returns you to the Microsoft MS-DOS® shell. FTP is still active; type exit to return to the >ftp prompt.
!command | Executes an MS-DOS command on the local computer from the FTP session.

For example, to copy a file from the server computer, type the following command at the >ftp prompt.

get filename

This command copies the specified file from the server to the client.

After you enter a command, you receive a series of return codes from the FTP server on a number of lines. The return codes let you know the status of each command. Table 1.10 shows some of the common return codes listed in RFC 640. Information in italics is supplied by the server. (A complete list of return codes in RFC 640 can be found at http://andrew2.andrew.cmu.edu/rfc/rfc640.html.)

Table 1.10 FTP Server Return Codes

Code | Meaning
119 | Terminal not available, will try mailbox.
120 | Service ready in nnn minutes.
125 | Data connection already open; transfer starting.
225 | Data connection open; no transfer in progress.
150 | File status okay; about to open data connection.
151 | User not local; will forward to user@host.
152 | User unknown; mail will be forwarded by the operator.
250 | Requested file action okay, completed.
200 | Command okay.
211 | System status, or system help reply.
212 | Directory status.
213 | File status.
214 | Help message.
220 | Service ready for new user.
221 | Service closing Telnet connection.
226 | Closing data connection; requested file action successful (for example, file transfer or file abort).
227 | Entering passive mode.
230 | User logged in; proceed.
331 | User name okay; need password.
332 | Need account for login.
350 | Requested file action pending further information.
450 | Requested file action not taken: file unavailable (for example, file busy).
421 | Service not available, closing Telnet connection. This can be a reply to any command if the service must shut down.
425 | Cannot open data connection.
426 | Connection closed; transfer aborted.
530 | Not logged in.
532 | Need account for storing files.
550 | Requested action not taken.


Modifying FTP Ports

It is easy to modify the Well Known Port Number for FTP. However, to allow FTP clients access to your site, keep the FTP server port number set at 21 for most installations of Internet Information Server.

If you want to limit access to your FTP server, you can change the control connection (port 21) to a TCP port number greater than 1023 to "hide" your site.

You can change FTP server TCP port numbers by modifying the Systemroot\System32\Drivers\Etc\Services file or by changing their values in the Registry. The setting in the Services file takes precedence over the Registry setting in all cases. That is, by changing the Services file, you affect both the FTP client and the FTP server. By changing the Registry, you affect only the FTP server.

To change the TCP port in the Services file

  1. At a command prompt, change directories to Systemroot\System32\Drivers\Etc.
  2. Use a text editor to search the Services file for the following two entries:

    3. ftp-data 20/tcp
    ftp 21/tcp

  3. Modify port 21 to a number greater than 1023. See the following example.

    4. ftp-data 20/tcp # The # sign designates a comment.
    ftp 1234/tcp # FTP port changed to 1234, was 21.

  4. Save and close the file. To implement the change, stop, then restart the FTP service.

Note This affects the default TCP ports on both the FTP client and the FTP server.

Your FTP server now waits at port 1234 for all FTP client requests and your FTP client connects only to an FTP server at port 1234.

To verify the new FTP port settings

  1. At a command prompt, type the command ftp.

    2. The ftp> prompt appears.

  2. Type the command open 127.0.0.1 21 and then press enter.

    3. The IP address 127.0.0.1 is the loopback address for your computer. You are specifying 21 as the destination port address. The following message appears:

    -> ftp: connect:Connection refused

  3. Type the command open 127.0.0.1 and then press enter.

The port now reverts to the default number specified in the Services file: 1234. You are prompted with the following logon message:

User <127.0.0.1:<none>>:

This verifies that both the FTP client and FTP server are using port 1234.

To change the Registry entry for FTP

  1. Start the Registry Editor, Regedt32.exe.
  2. Click the HKEY_LOCAL_MACHINE window and locate the following key:

\System

\CurrentControlSet

\Control

\ServiceProvider

\ServiceTypes

\MSFTPSVC

  1. Click MSFTPSVC and then double-click the TcpPort value.

The DWORD Editor dialog box appears.

  1. Click Decimal and enter 5678 in the Data box.
  2. Click OK and close the Registry Editor.
  3. At the command prompt, type the following information:

cd %systemroot%\system32\drivers\etc

ren services services.ok

This prevents the FTP server from using the port address in the Services file after it has been restarted.

  1. To implement the change, stop and restart the FTP service.

Note This situation affects the default port only on the FTP server.

If you have completed the preceding steps, your FTP server now monitors port 5678 for all FTP client requests and your FTP client connects to an FTP server at port 1234 only.

To verify the new FTP port settings

  1. At a command prompt, type ftp, then press enter.

    2. The ftp> prompt appears.

  2. Type the following commands:

open 127.0.0.1

open 127.0.0.1 21

open 127.0.0.1 1234

The following message appears:

-> ftp: connect: Connection refused

  1. Type the command open 127.0.0.1 5678 and then press enter.

The port defaults to the number specified in the Registry: 5678. You are prompted with the following logon message:

User <127.0.0.1:<none>>:

This procedure verifies that both the FTP client and FTP server are using port 5678.


Customizing FTP Server

When a client connects to an FTP server, the user often lacks site information. Without site information, the user does not know if this is the correct FTP server, or what the files at the site contain. By adding a welcome message, exit message, and directory contents message, you can supply such information to visitors to your FTP site.

You can use two methods to add information about your FTP site. Both methods can enhance its usability.

You can use the Internet Service Manager to add default Welcome or Exit messages to the FTP server. Double-click the FTP service, then click Messages to add or change FTP service messages.

You can also add an FTP directory description file. For examples of this process, see Chapter 5, "Enterprise Scenarios."

To enable the FTP directory description file

  1. Click the Start button, then point to Run. In the Open box, type regedt32.exe and then click OK.

    2. The Registry Editor appears.

  2. Click the HKEY_LOCAL_MACHINE window and locate the following key:

    3. \System

    \CurrentControlSet

    \Services

    \MSFTPSVC

    \Parameters

  3. On the Edit menu, click Add Value.

    4. The Add Value dialog box appears.

  4. In the Value Name text box, type Annotate Directories.
  5. In the Data Type box, select REG_DWORD and then click OK.

The DWORD Editor dialog box appears.

  1. In the Data text box type 1 and click OK.

The Registry Editor adds the new value to the Parameters key.

  1. Close the Registry Editor.
  2. To implement these changes, stop and restart the FTP service.

To add an FTP directory description file

  1. Using a text editor, create the file ~ftpsvc~.ckm
  2. In the file, type the following lines:

Directory for the Terra Flora FTP Server

------------------------------------------------------

  1. Save the file in the root directory of the FTP server and close the editor.
  2. At the command prompt in the root directory of the FTP server, type the following information and then press Enter.

attrib +h ~ftpsvc~.ckm

This step hides the file.

To verify the customized FTP server

  1. At the command prompt, type the following information.

ftp 127.0.0.1

This step uses the IP loopback address to start an FTP session on your local computer.

The FTP client prompts you to log on.

  1. Log on as Anonymous.

    2. The introductory message and the annotated directory listing appear.

  2. At the ftp> command prompt, type the following information.

BYE

The exit message appears.


Monitoring FTP Sessions

You can monitor FTP, just like HTTP sessions, by using the netstat TCP/IP utility and the Performance Monitor.

The netstat utility shows static information at a given point in time. Netstat is best used to determine the status of connections. You can run netstat from a command prompt or inside an FTP session by using the ! command. For examples of netstat command syntax, see Table 1.4, earlier in this chapter.

Performance Monitor shows events happening in real time. Performance Monitor is best used to check the status of users, file transfers, and byte transfers. For a listing of real-time statistics displayed by Performance Monitor for the FTP service, see Table 1.5, earlier in this chapter.


Gopher Service

Gopher is client/server–oriented software that uses a simple protocol to search for and retrieve files from Gopher servers on the Internet. The Gopher service was developed by the University of Minnesota in 1991 to overcome some limitations of the FTP service. Gopher has an easier-to-use interface and also allows administrators to create links to other computers or services, to annotate files and directories, and to create custom menus.

Gopher is not just an Internet tool. Many organizations use Gopher on their local area network to help people within the organization find the information they need quickly and efficiently.

The user of the Gopher client can download files, switch directories, or link to other Gopher servers by using a series of menus. The Gopher server generates menus, links, and annotations by using a series of tag files.

Gopher presents information in a hierarchical structure. Depending on which client software is used and what selections are available on the Gopher server, the user can choose how to view information—for example, as a text file, as a Microsoft Word for Windows document, or in a particular language.

A Gopher client presents the individual user with directory lists. If the user chooses a subdirectory from the displayed list, the listing for that subdirectory is displayed. If the user chooses a file, it is downloaded. Each directory and file can be on a different Gopher server.

You can also configure a Gopher server to search local Wide Area Information Server (WAIS) databases.

Gopher uses TCP as its transport protocol for all communication and data exchanges between the client and the server. Internet Information Server communicates with Windows Sockets, then Windows Sockets communicates with TCP.

TCP is a connection-oriented protocol (that is, the communications session is established between the client and the server before data is transmitted). However, unlike FTP, Gopher does not maintain the connection between requests; this is also known as a stateless connection.

For a description of TCP connection features, see Table 1.6, earlier in this chapter.


Gopher Ports and Connections

The Gopher protocol consists of a client and a server communicating through a TCP connection. The server waits at port 70 for a client request. The client, after initiating the connection, sends a selector to the server. A selector is a line of text that can consist of a series of characters or a null string. The server responds with a block of text terminated with a period on a line by itself. After receiving an acknowledgment from the client, the server closes the connection.

Similar to FTP, the Gopher client always communicates on a port whose number is greater than 1023. This port number changes each time a new transaction begins between the client and the server.


Designing a Gopher Site

Because most computer users are familiar with a hierarchical file system, you should design a Gopher site to resemble a directory tree structure. That is, the root directory contains names of subdirectories, links to other sites, and an explanation (Readme) file. The actual content is stored in subdirectories on the server.

When using Microsoft Internet Information Server, the default root directory is Systemroot\System32\Inetsrv\Gophroot.


Gopher Types

Gopher servers contain Gopher objects and each object has an associated Gopher type. The Gopher type signals the client what to do when that object is selected from the menu. Table 1.11 explains the Gopher types.

Table 1.11 Gopher Types and Client Behavior

Type |  | Description |  | Client action
0 |  | Text file, typically an ASCII document |  | Usually displayed on the screen.
1 |  | Directory listing |  | Expect another Gopher menu.
2 |  | CSO phone book server |  | Expect to be queried for a person's name.
3 |  | Error |  |
4 |  | Macintosh® BinHex file |  | Expect the file to be transferred.
5 |  | MS-DOS .zip or other archive file |  | Expect the file to be transferred.
6 |  | UNIX UUENCODE file |  | Expect the file to be transferred.
7 |  | Search item |  | Expect to be queried for a relevant search string.
8 |  | Telnet session |  | Expect the Telnet program installed on your computer to start.
9 |  | Binary file |  | Expect the file to be transferred.
T |  | 3270 session |  | Expect the tn3270 program installed on your computer to start.
S | Sound file |  | Expect the file to be transferred and then played by a sound application on your computer.
g | Graphics file |  | Expect the file to be transferred and then displayed by a graphics application on your computer.
M | MIME file |  | Expect the file to be transferred and then displayed by an application on your computer.
h | HTML file |  | Expect the file to be transferred and then displayed by an application on your computer.
I | Image file |  | Expect the file to be transferred and then displayed by an application on your computer.
i | In-line text type |  | Used to suppress item numbers in text-only clients.


Gopher Tag Files

You use Gopher tag files to set up links to other Gopher servers and resources, and to give descriptive names to files and directories on Gopher servers. Gopher tag files are configured by using the gdsset utility. This utility creates hidden tag files (*.gtg) in the \Inetsrv\Gophroot directory. The examples in the following three sections demonstrate how to use tag files to customize the Gopher site.

Changing Filename Display

In this example, you have two Readme files and a subdirectory in the \Inetsrv\Gophroot directory on your server. When a Gopher client accesses your computer, the following menu displays.

1 README1.TXT
2 README2.TXT
3 SUBDIR

Readme1.txt describes the mission of this Gopher site. Readme2.txt describes how to contact the site administrator. And Subdir is a subdirectory that contains the content of this Gopher site.

To change these filenames to a descriptive name format, type the following gdsset commands at a command prompt.

gdsset -c -g0 -f "The Mission of this Gopher Site" README1.TXT
gdsset -c -g0 -f "Contact the Site Administrator" README2.TXT
gdsset -c -g0 -f "Contents of this Gopher Site" SUBDIR

These commands create three hidden tag files in the \Inetsrv\Gophroot directory: Readme1.txt.gtg, Readme2.txt.gtg, and Subdir.gtg. The tag files set up an association between the descriptive name and the filename. The next time a Gopher client accesses your computer, the following menu displays.

1 The Mission of this Gopher Site
2 Contact the Site Administrator
3 Contents of this Gopher Site

When a user clicks The Mission of this Gopher Site, the Gopher client displays the contents of Readme1.txt. Clicking Contact the Site Administrator displays the contents of Readme2.txt, and clicking Contents of this Gopher Site displays the contents of the directory Subdir. The original filenames and directory names are hidden from the Gopher client.

Creating Links to Directories

In this example, you have five subdirectories under the root Gopher directory (\Inetsrv\Gophroot) on your server.

\Inetsrv\Gophroot\Subdir1\Subdir2\Subdir3\Subdir4\Subdir5

When a Gopher client accesses your machine, the user sees the following menu display.

SUBDIR1

If a user wants to access files in Subdir5, the user must access four additional subdirectories to access Subdir5.

To establish a link to Subdir5 from the root directory and provide a descriptive name format for Subdir5, use the following gdsset commands at a command prompt.

gdsset -c -l -g1 -f "Microsoft Windows Printer Drivers Location" -s \Subdir1\Subdir2\Subdir3\Subdir4\Subdir5 link.subdir5

This command creates a hidden tag file, called Link.Subdir5.gtg, in the \Inetsrv\Gophroot directory.

Note

All link files must start with the prefix "link"; however, do not use the prefix "link" for any other tag files.

The next time a Gopher client accesses your computer, the following menu is displayed.

SUBDIR1
Microsoft Windows Printer Drivers Location

Clicking Microsoft Windows Printer Drivers Location brings the user directly to Subdir5.

Creating Links to Other Gopher Sites

To link to another Gopher site, add the host name or IP address to the gdsset command. For example, to link to the Greater London, England Gopher Server, you issue the following command from an >ftp command prompt.

gdsset -c -l -g1 -f "Link to the Greater London, England Gopher Server"
-s -hgopher.london.com link.london

The links, files, friendly names, and directories that appear on the server are in alphabetical order.


Using Gopher

Internet Explorer works as a Gopher client. To connect to a Gopher server, start Internet Explorer and enter a Gopher address in the address box. For example, you can enter

gopher://gopher.college.edu/

If the name or IP address of the Gopher server is known, but the server is not using the standard TCP port address (70), you can alter the address on the client to match the server. For example, if the Gopher server is monitoring port 1938, use the following command.

gopher://gopher.college.edu:1938


Modifying Gopher Ports

For most installations of Internet Information Server, you keep the Gopher server port number set to the default 70 to allow other Gopher clients access to your site. However, if you want to limit access to your Gopher server, you can change the control connection (port 70) to a port number greater than 1023 to "hide" your site.

You can change Gopher server port numbers by modifying the Systemroot\System32\Drivers\Etc\Services file or by modifying their values in the Registry. The setting in the Services file takes precedence over the Registry setting in all cases. By changing the Services file or the Registry, you affect only the Gopher server.

Note

By changing the port number, you can break some or all of your tags and links. You must rebuild these by using the -p option of the gdsset command to change the port number. For example, if you change the port number to 2345, you rebuild the new tag by typing the following line:

gdsset -c -g0 -f "The Mission of this Gopher Site" Readme1.Txt -p2345

To change the Gopher port in the Services file

  1. At a command prompt, change directories to Systemroot\System32\Drivers\Etc.
  2. Use a text editor to search the Services file for the following entry.

    3. gopher 70/tcp

  3. Modify port 70 to a number greater than 1023 and add a comment (#) to show the default. For example, if you change to port 2345, add the following line.

    4. gopher 2345/tcp # gopher 70/tcp

  4. Save and close the file.
  5. To implement the change, stop then restart the Gopher service.

Note This affects the default ports on the Gopher server.

Your Gopher server now waits at port 2345 for all Gopher client requests.

To verify the new Gopher port settings

  1. Start Internet Explorer. In the address box, type gopher://127.0.0.1 and then press Enter.

The following message appears.

The attempt to load 'gopher:127.0.0.1' failed.

  1. Click OK to dismiss the message.
  2. In the address box, type gopher://127.0.0.1:2345 and then press Enter.

The Gopher menu appears on your screen.

To change the Registry entry for Gopher

  1. Start the Registry Editor, Regedt32.exe.
  2. Click the HKEY_LOCAL_MACHINE window and locate the following key.

\System

\CurrentControlSet

\Control

\ServiceProvider

\ServiceTypes

\GOPHERSVC

  1. Click GOPHERSVC and then double-click the TcpPort value.

    2. The DWORD Editor dialog box appears.

  2. Click Decimal and enter 6789 in the Data box.
  3. Click OK and close the Registry Editor.
  4. At the command prompt, type the following information:

    5. cd %systemroot%\system32\drivers\etc
    ren services services.ok

    This step prevents the Gopher server from using the port address in the Services file after it has been restarted.

  5. To implement the change, stop and restart the Gopher server.

Note This affects the default port only on the Gopher server.

Your Gopher server now monitors port 6789 for all Gopher client requests and your Gopher client connects to a Gopher server at port 6789 only.

To verify the new Gopher port settings

  1. Start Internet Explorer. In the address box, type gopher://127.0.0.1 and then press Enter.

The following message appears.

The attempt to load 'gopher:127.0.0.1' failed.

  1. Click OK to dismiss the message.
  2. In the address box, type gopher://127.0.0.1:6789 and then press Enter.

The Gopher menu appears.


Monitoring Gopher Sessions

You can monitor Gopher sessions by using the Performance Monitor and, to a lesser extent, netstat.

The netstat utility can be difficult to use with Gopher because Gopher sessions are very short and you cannot always activate netstat in time to receive any meaningful data. Netstat shows static information at a given point in time. Netstat is best used to determine the status of connections.

You can run netstat from a command prompt. For an explanation of netstat command syntax, see Table 1.4, earlier in this chapter.

Performance Monitor shows events happening in real time. Performance Monitor is best used to check the status of users, file transfers, and byte transfers. For a listing of real-time statistics displayed by Performance Monitor for Gopher, see Table 1.5, earlier in this chapter.


Chapter 2 - Connecting Windows NT Server to the Internet

In the near future, it might be as common and simple to connect to the worldwide Internet as it is to connect to the worldwide telephone system. However, it is now a complex endeavor to connect servers or networks to the Internet. This chapter presents an overview of the concepts you use in connecting a server or network to the Internet. The chapter explains:

  • The basic process of connecting a server to the Internet.
  • Typical requirements for the server.
  • Where to find more detailed information about procedures.
  • Example network scenarios for connecting a computer or network to the Internet.

You can find extensive information on these topics by searching the Internet itself. It is recommended you seek resources on the Internet for more information on any topic. In addition, Table 2.1 lists references you can find in the Windows NT documentation and in the Microsoft Windows NT Server Resource Kit, version 4.0.

Table 2.1 Additional Information about Using Windows NT on the Internet

For information about |  | See
Connecting to the Internet as a client |  | Microsoft Windows NT Workstation Resource Kit: Windows NT Workstation Resource Guide
NetBIOS names |  | Windows NT Server Networking Supplement and Microsoft Windows NT Server Resource Kit: Windows NT Server Networking Guide
TCP/IP networking, including IP addresses and subnet masks, and DHCP and WINS servers |  | Windows NT Server Networking Supplement and Microsoft Windows NT ServerResource Kit: Windows NT Server Networking Guide
Securing a server on the Internet |  | Windows NT Server Internet Guide, Chapter 3, "Server Security on the Internet"
Creating Internet Information Server sites | Windows NT Server Internet Guide, Chapter 4, "Desktop Scenarios," and Chapter 5, "Enterprise Scenarios"
Specific Internet server services or client applications included in the Windows NT Server Resource Kit | Windows NT Server Internet Guide, Chapter 7, "Internet Tools"
Troubleshooting Internet Information Server | Windows NT Server Internet Guide, Chapter 8, "Troubleshooting an Internet Information Server Installation"


Establishing an Internet Connection

You must establish an Internet connection to enable worldwide access to your site. Before you establish an Internet connection, you should:

  • Understand your network and how TCP/IP operates.
  • Select an Internet service provider (ISP) and determine what Internet services you will use.

This section explains network protocols and intranets, the formal requirements and procedures for participating in the Internet, Internet service providers, and how to choose the right connection.

When you connect a computer to the Internet, you must do a thorough security review and implement measures to protect your computer and network (if the computer is also connected to a private network) from intruders. For more information about securing computers and networks connected to the Internet, see Chapter 3, "Server Security on the Internet."


Network Protocols and Intranets

The Internet is a group of interconnected networks. When you create an Internet server, you are adding another network to the network of networks. The network you add to the Internet can be one computer, a small workgroup, or your entire corporation's local area network.

Network protocols are similar to language. Languages have different words, word patterns, and punctuation. A network protocol serves a similar role for computers attempting to communicate. The network protocol used on a network determines how packets (units of data) are configured and sent over the network cable. For more information about network protocols, see the Windows NT Server Networking Supplement and Windows NT Server Resource Kit Networking Guide.

The Internet primarily uses the TCP/IP (Transmission Control Protocol/Internet Protocol) network protocol. That means your computer must use the TCP/IP network protocol to participate. (TCP/IP is actually a suite of protocols. Internet Protocol is one of the protocols in the suite of protocols.) You can install TCP/IP during or after installation of Windows NT.

If you use TCP/IP on your internal network, as shown in Figure 2.1, your computer can act as a gateway to the Internet. By configuring Windows NT as a TCP/IP router you can pass packets of information in both directions— to the Internet from the intranet, and from the Internet into your intranet.

Figure 2.1 Windows NT–based computer connected to two networks

For more information about TCP/IP and the routing capabilities in Windows NT Server, see the Windows NT Server Networking Supplement, the Windows NT Server Networking Guide, and Chapter 3 in this book, "Server Security on the Internet."


IP Addresses and Domain Names

Each computer on the Internet has a unique address (the IP address). An IP address is in the form of four period-delimited octets consisting of up to 12 numerals—such as 172.16.16.189. Information is transmitted on the Internet in data packets. Each packet is addressed to a specific computer's IP address.

Because IP addresses are difficult to remember, the Domain Name System (DNS) was created for the Internet to pair a specific IP address, such as 172.16.16.189, with a "friendly" domain name, such as microsoft.com. When you use a domain name in an Internet browser, the browser first must contact a DNS server to resolve the domain name to an IP address, then contact the computer with that address.

This has two implications for your server running Internet Information Server (IIS server):

  • You must have a permanent IP address assigned to a server on the Internet.
  • You must register a domain name in the Domain Name System for your permanent IP address.

To establish a World Wide Web (WWW) server, you need a permanent IP address. To connect a TCP/IP network to the Internet, you need a valid IP address for each computer or device you want to be accessible from the Internet.

You must use a domain name if you want Internet users to be able to reach your Internet server or servers by the friendly domain name, such as microsoft.com. Both a registered domain name and an IP address are required for your Internet service to be seen and used by others on the Internet.

Most Internet service providers assign your IP addresses and can also register your domain names. Contact the Internet Network Information Center (InterNIC) or your ISP for more information about DNS registration.

To contact the InterNIC to register domain names and obtain IP addresses, connect to the Internet address http://internic.net.

If you must apply for your own domain name or IP addresses, you must have a good understanding of DNS and of TCP/IP networking. For more information about DNS and TCP/IP networking, see the Windows NT Server Networking Supplement and Windows NT Server Networking Guide.


Internet Service and Providers

You establish a connection to the Internet by leasing a line from an Internet service provider (ISP) or a telephone company. Your provider installs a cable at your site that is plugged into the network interface card (NIC) in your computer. Usually, a router is also installed between your computer and the ISP.

The services available on the Internet vary widely. The basic services required by Internet clients and servers are:

  • An Internet gateway (default gateway).
  • IP addresses and subnet mask.

An Internet service provider must provide the required services and often provides optional Internet services, such as DNS name resolution, domain name registration, electronic mail, and Internet news.

It is important to note that not all ISPs are alike; you need to find out their capabilities. Some questions to ask an ISP can include:

  • How are you connected to the Internet (backbone)? (For example, a T1, multiple T1s, or a T3 connection.)
  • What type of dedicated access do you offer? (For example, Frame Relay or shared T1.) Do you guarantee a minimum bandwidth?
  • Do you offer dial-up access to allow connections through telephone modems?
  • Do you offer Integrated Services Digital Network (ISDN) access?
  • What type of security do you offer?
  • What are your installation costs for each type of connection?
  • What are your monthly costs for each type of connection?

Internet service providers are local, regional, or national providers. Local ISPs are connected to the Internet through larger ISPs or through a regional network. Local ISPs usually have only one location. The larger regional and national ISPs have multiple locations. If your site has enough traffic to require a high-speed T3 line (45 megabits per second) to your ISP, consider connecting directly to a regional network.

Regional networks are sites selected by the National Science Foundation (NSF) to provide a common connection point to the Internet. Regional networks connect to other regional networks at 155 megabits per second through a backbone carrier—such as US Sprint, MCI MAIL, or AT&T.

Companies that require a large bandwidth for their Internet sites can connect directly to a regional network. Requirements vary by regional network provider, but usually a T3 line is the minimum bandwidth of a connection. For more details, contact the vendor who operates your local regional network.

The Microsoft Network (MSN™) is an Internet service provider. You can find other Internet service providers listed in your local phone book (usually under "computer network services"). Internet service providers also frequently advertise in local newspapers or computer magazines.


How to Choose the Right Internet Connection

You connect to the Internet through a network adapter card or other network device, such as a modem or ISDN card. Internet bandwidth is measured in bits per second (bps).

Your Internet bandwidth determines how fast data gets to your computer and also how many requests can be serviced simultaneously. As more computers get data through your Internet connection simultaneously, delays or failures can occur if you do not have enough bandwidth.

When you lease an Internet connection, your ISP installs a network cable to your site. Leased connection speeds range from 56,000 bps (or 56 kilobytes per second) with Frame Relay to 45,000,000 bps (or 45 megabytes per second) with a T3 connection. A dial-up ISDN line can offer speeds up to 128,000 bps (or 128 kilobytes per second).

The connection types described in Table 2.2 represent typical levels of service for full Internet connections in North America and Japan. The Internet services offered through Internet service providers in your country might differ significantly.

Table 2.2 Common Internet Service Connection Types

Connection type | Maximum bandwidth | Approximate number of users supported
Dedicated PPP/SLIP | Modem speed | 2-3
56K (Frame Relay) | 56,000 bps | 10-20
ISDN (using PPP) | 128,000 bps | 10-50
T1 | 1,540,000 bps | 100-500
Fractional T1 | Varies as needed | Varies as needed
T3 | 45,000,000 bps | 5,000+

To understand these speeds in practical terms, assume a page of text is 42,240 bits. (One character is 8 bits. Therefore, 8 bits x 80 characters in a line x 66 lines per page = 42,240 bits per page.) A 28.8 Kbps modem can transfer .67 pages per second. A 128,000 bps ISDN line can transfer three pages per second. A 1,500,000 bps T1 line can transfer 35.5 pages per second.

For example, a light-duty server can use a 56 Kbps link or ISDN. A server with medium traffic might have a T1 line or some fraction of a T1 line installed. Large businesses that expect heavy Internet traffic might need fractional or multiple T1 lines or even T3 service in order to handle thousands of users.

Modem connections to the Internet are available, but are typically used for individual client browsing and are not recommended for servers. A connection to the Internet that uses a phone line and modem can service only two or three users simultaneously. (Modem connections might be used for text-only Internet servers with only a small number of potential users.) Modem connections are often called "slow links" because data is transmitted at the speed of the modem, typically from 9600 to 28,800 bps. This is far too slow for efficient operation of a World Wide Web server, for example.


Selecting Hardware and Software to Run Internet Information Server

Many variables influence hardware and software selection. The guidelines and case studies in this section are presented to help you determine the best choices for your situation.


Internet Information Server Hardware Guidelines

The type of processor and the amount of RAM you choose for your system can affect the performance of your server. For example, in laboratory conditions an 80486DX/50 computer with 52 MB of RAM running Microsoft Windows NT Server and Internet Information Server can handle more than 100 simultaneous users or sessions.

The number of simultaneous users your server can handle varies according to the type of session that is open and other factors. A server is able to accommodate more users when they are running sessions that are not processor-intensive, such as electronic mail (e-mail), Telnet, and FTP. Sessions that are processor-intensive include those that run Common Gateway Interface (CGI) scripts, make database queries, and download Hypertext Markup Language (HTML) files.

Table 2.3 lists the minimum and recommended hardware needed to run Microsoft Windows NT Server 4.0 and Internet Information Server.

Table 2.3 Hardware Requirements and Recommendations

Hardware requirement | Minimum | Recommended
Processor | 50 MHz 486 | 90 MHz Pentium®
RAM | 16 MB | 32 to 64 MB
Free hard disk space | 50 | 200
Monitor | VGA | Super VGA
CD-ROM drive | 3X | 6X

RAM

The amount of RAM needed by your server is dependent on a number of factors, including:

  • The number of simultaneous users.
  • The number of Hypertext Transfer Protocol (HTTP) users (high memory use) versus Gopher and FTP users (lower memory use).
  • The amount of RAM used for cache.
  • The size of swap file.
  • The amount of free disk space.
  • The amount of RAM used for video.
  • The number of services running.
  • The type of processor.
  • The SQL database searches.

Taking into consideration all of these variables, a general guideline is to allow about 256K of RAM per simultaneous user.

www.microsoft.com

The Web site for Microsoft, www.microsoft.com, handles three million requests a day. In a 24-hour time period, this averages more than 2,000 hits per minute.

The www.microsoft.com Web site consists of two computers running Internet Information Server on Microsoft Windows NT Server. Each computer has multiple 66-MHz Intel Pentium processors, 8 GB of usable hard disk space, and 128 MB of RAM. One computer uses four Pentium processors and the other uses two.


Internet Information Server Software Requirements

Internet Information Server runs on Windows NT Server 4.0. You should install the latest service pack. Windows NT 4.0 service packs are available through The Microsoft Network (MSN), CompuServe, and on the Internet at http://www.microsoft.com.

Table 2.4 shows a typical software configuration for your Internet server.

Table 2.4 Software Requirements and Recommendations

Software | Description
Operating system | Windows NT Server 4.0 or later, with the latest service pack
Server software | Internet Information Server (included with Windows NT Server 4.0)
HTML creation | Microsoft Word for Windows® 95 and Microsoft Internet Assistant for Word


Internet Networking Scenarios

This section describes Internet and intranet scenarios that use Windows NT Server. The components used on the Internet or to connect to the Internet are identified and explained. The components are applied to Internet scenarios. And finally, an intranet is defined and scenarios for connecting your intranet to the Internet are illustrated.


Networking Software for the Internet

Windows NT Server provides all the networking software necessary to connect an information server or network to the Internet. The Windows NT software used is defined in Table 2.5.

Table 2.5 Networking Software Used for Connecting to the Internet

Windows NT software component | Function
Infrastructure |
TCP/IP protocol | Is required to communicate with other computers on the Internet.
DHCP server | Dynamically assigns TCP/IP configuration to computers on a network.
WINS server | Provides name resolution for NetBIOS names.
DNS server | Provides name resolution for Domain Name System names.
HOSTS file | Provides name resolution for DNS names.
LMHOSTS file | Provides name resolution for NetBIOS names.
Connectivity |
Remote Access Service | Enables incoming connections from remote clients that are using Dial-Up Networking or other PPP or Serial Line Internet Protocol (SLIP) dial-up software.
Dial-Up Networking | Provides low-speed connections to the Internet. Primarily used by clients connecting to a Remote Access Service server or Internet service provider.
RIP (routing information protocol) for Internet Protocol | Provides routing for high-speed connections to the Internet (or other networks). Primarily used on small to medium-size networks.
Publishing |
Internet Information Server | Enables file and application sharing by using the HTTP, FTP, and Gopher protocols. Requires a computer running Windows NT Server.
Peer Web Services | Enables file and application sharing by using the HTTP, FTP, and Gopher protocols. Requires a computer running Windows NT Workstation.
Internet Explorer | Enables access to shared files and applications by using Internet protocols.

To complement these primary tools, you can also use tools in the Windows NT Resource Kit (see Chapter 7, "Internet Tools"), public domain programs available on the Internet, or commercial products that include more features and technical support.

You also need a connection to the Internet. Depending on your needs, the connection can be a 28.8 Kbps modem and dial-in Point-to-Point Protocol (PPP) account, or a dedicated high-volume line supplied by an Internet service provider for an Internet server or providing an Internet gateway for an intranet.

For information about | See
The physical connection to the Internet | "Establishing an Internet Connection," earlier in this chapter
The Internet tools in this Resource Kit | Chapter 7, "Internet Tools"


Using Windows NT Server on the Internet

This section explains typical Internet scenarios with Windows NT Server .

Internet Client

The simplest way to connect to the Internet is as a client. As a client you use Internet Explorer or other tools to search for information.

This configuration allows outbound traffic to the Internet only, as illustrated in Figure 2.2. (For more information about client connections to the Internet, see the Windows NT Workstation Resource Guide, Chapter 35, "Using Windows NT Workstation on the Internet.")

Figure 2.2 Windows NT as Internet client

In this scenario, the computer running Windows NT Server (or Windows NT Workstation) uses Dial-Up Networking and a modem to connect to an Internet service provider. After successful connection to the Internet service provider, the user can start and use any TCP/IP–based applications, such as Internet Explorer or the command-prompt FTP client.

For this type of scenario, you need to install and configure the following hardware or services:

  • Internet client tools, such as Internet Explorer, FTP, or Telnet
  • TCP/IP networking protocol
  • Dial-Up Networking
  • A modem
  • PPP or SLIP dial-in account to an Internet service provider

Internet Web Server

Expanding the preceding configuration, you can create two-way communication with the Internet as illustrated in Figure 2.3.

Figure 2.3 Windows NT Internet Information Server and client

In this scenario, the computer running Windows NT Server has a leased line to an Internet service provider. You install Internet Information Server and make information available to remote users on the Internet. In addition, the computer running Windows NT Server can use any TCP/IP–based applications, such as Internet Explorer or the command-prompt FTP client.

For this scenario, you need to install and configure the following hardware or services:

  • Internet Information Server
  • TCP/IP networking protocol
  • Network interface card
  • Leased line to an Internet service provider
  • Domain name registration, as described in the section, "Establishing an Internet Connection"

For more information about Internet servers, see Chapter 4, "Desktop Scenarios," and Chapter 5, "Enterprise Scenarios."

Note

Security becomes an important issue when you are connected to the Internet. This section describes only basic Internet scenarios. Many options that are not mentioned in this chapter exist to protect your computer or intranet from external intruders. For more information on security, see Chapter 3, "Server Security on the Internet."


Using Windows NT Server on an Intranet

An intranet is a private local area network that uses Internet technology. The functions on an intranet are identical to the functions on the Internet. You can install Internet Information Server on any computer on your intranet that runs Windows NT Server, and it can be accessed by Internet Explorer or any other client that supports the HTTP, FTP, and Gopher protocols.

To operate on an intranet, you need to provide a networkwide name resolution system by using WINS servers, DNS servers, or a HOSTS or LMHOSTS file. (For more information about using HOSTS and LMHOSTS for name resolution in an Internet scenario, see Chapter 5, "Enterprise Scenarios." For more information on using HOST and LMHOSTS in general, see the Windows NT Server Networking Supplement.)

Heterogeneous clients can use all the resources on your network, such as Internet Information Server, databases, DHCP servers, and WINS servers, as shown in Figure 2.4.

Figure 2.4 Typical intranet components

In this scenario, you install Internet Information Server and make information available to local users on the network.

For any intranet scenario, you need to install and configure the following hardware or services:

  • A computer running Internet Information Server
  • TCP/IP networking protocol on every computer that will use the IIS server
  • Network interface cards on all computers
  • An Internet browser, such as Internet Explorer, on every computer that will access the IIS server
  • Domain name resolution, as described in the section, "Establishing an Internet Connection"

Connecting Your Intranet to the Internet

You can configure your network to allow intranet clients to be able to access the Internet. You create two-way communication with the Internet by configuring Windows NT and configuring RIP for Internet Protocol routing as shown in Figure 2.5.

Figure 2.5 Intranet access to the Internet by using Windows NT

In this scenario, the computer running Windows NT Server has a leased line to an Internet service provider. The RIP for Internet Protocol service is installed. An Internet service provider router uses the routing information protocol (RIP) to communicate with the computer running Windows NT Server RIP for Internet Protocol service. By using RIP, the Internet service provider's router learns the IP address of all computers on the private network. This enables traffic from the Internet to be routed to computers on the private network, and traffic from private network computers to be routed to the Internet.

For this scenario, you need to install and configure the following hardware or services:

  • A computer running the RIP for Internet Protocol service
  • TCP/IP networking protocol on every computer that will use the Internet
  • Network interface cards on all computers
  • An Internet browser, such as Internet Explorer, on every computer that will access the Internet
  • Internet-wide domain name resolution, as described in the section, "Establishing an Internet Connection"

For more information about the RIP for Internet Protocol service (part of Windows NT Server multiprotocol routing functionality), see the Windows NT Server Networking Supplement and Windows NT Server Networking Guide.

Connecting Intranet Clients to the Internet with Remote Access Service

The Windows NT Server Remote Access Service (RAS) can be added to the above configuration to provide remote clients with an Internet gateway. This type of configuration expands your intranet configuration as illustrated in Figure 2.6.

Figure 2.6 Remote client Internet gateway

In this scenario, the computer running Windows NT Server has a leased line to an Internet service provider. The RIP for Internet Protocol service and Remote Access Service are installed on this server. An Internet service provider router uses the routing information protocol to communicate with the computer running Windows NT Server RIP for Internet Protocol service. By using RIP, the Internet service provider's router learns the IP address of all computers on the private network. This enables traffic from the Internet to be routed to computers on the private network, and traffic from private network computers to be routed to the Internet.

By using the Remote Access Service, Windows Dial-Up Networking clients or other dial-up clients can connect to the RAS server and the local network. Because the RIP for Internet Protocol service is also on the network and routes packets to and from the Internet, remote clients also have access to the Internet. Thus, local network clients and remote RAS clients can use the local network and the Internet.

For this scenario, you need to install and configure the following hardware or services:

  • A computer running the RIP for Internet Protocol service and the Remote Access Service
  • TCP/IP networking protocol on every computer that will use the Internet
  • A multiport adapter, which allows multiple remote clients to dial in to the computer running RAS
  • Network interface cards on all computers
  • An Internet browser, such as Internet Explorer, on every computer that will access the Internet
  • Dial-Up Networking on remote clients that will dial in to the RAS server
  • Internet-wide domain name resolution, as described in the section, "Establishing an Internet Connection"

For more information about the RIP for Internet Protocol service and the Remote Access Service, see the Windows NT Server Networking Supplement and Windows NT Server Networking Guide.

On a small intranet (that is, an intranet with less than 20 computers), the RAS server can use Dial-Up Networking, simple TCP/IP routing, and a PPP connection to its Internet service provider in place of a leased line and the RIP for Internet Protocol service. In this configuration you can connect both intranet clients and remote Dial-Up Networking clients to the Internet, as shown in Figure 2.7.

Figure 2.7 Internet gateway for a small intranet with remote clients

In this scenario, the computer running Windows NT Server has a Dial-Up Networking connection to an Internet service provider. Simple TCP/IP routing is enabled, and a static routing table is created for the computers on the private network. You must also provide routing information to the Internet service provider because simple TCP/IP routing does not use the routing information protocol to communicate with the Internet service provider's router. The routing information you supply enables the routing of Internet traffic to and from the computers on the private network.

The Remote Access Service, installed on the server, accepts incoming calls from remote clients that use Dial-Up Networking or other dial-up client software. The Remote Access Service enables Windows Dial-Up Networking clients or other dial-up clients to connect to the RAS server and the local network. This configuration can also support a light-duty IIS server.

For this scenario, you need to install and configure the following hardware or services:

  • A computer running simple TCP/IP routing and a static routing table
  • TCP/IP networking protocol on every computer that will use the Internet
  • The Remote Access Service
  • A multiport adapter, which allows multiple remote clients to dial in to the computer running Remote Access Service
  • Network interface cards on all computers
  • An Internet browser, such as Internet Explorer, on every computer that will access the Internet
  • Dial-Up Networking on remote clients that will dial in to the RAS server
  • Internet-wide domain name resolution, as described in the section, "Establishing an Internet Connection"

For more information about simple TCP/IP routing and the Remote Access Service, see the Windows NT Server Networking Supplement and Windows NT Server Networking Guide.

For more information about creating an Internet gateway, see Chapter 6, "Internet Connectivity Scenarios Using the Remote Access Service."


Chapter 3 - Server Security on the Internet

You must provide a secure base to use Internet Information Server (IIS) and participate in the Internet. In this chapter, security refers to providing selective access to documents through Internet Information Server and preventing Internet users from maliciously tampering with your intranet.

This chapter presents:

  • Authentication and security controls in Internet Information Server.
  • Scenarios for connecting an intranet to the Internet.
  • Suggestions on using monitoring tools to detect, monitor, and prevent security breaches.

For information about | See
Windows NT security | Windows NT Server Concepts and Planning or the Microsoft Windows NT Workstation Resource Kit: Windows NT Workstation Resource Guide
Windows NT security integration with Internet Information Server | Windows NT Server Microsoft Internet Information Server Installation and Administration Guide online HTML book, Chapter 6, "Securing Your Site Against Intruders"

Note

The Microsoft Windows NT Administrator's Security Guide gives you the information you need to set up your Windows NT–based system to be eligible for C2-level security certification. Along with general topics on high-security installations for system administrators, the Administrator's Security Guide contains the "Microsoft Report on C2 Evaluation of Windows NT," which describes the evaluation process and gives directions for duplicating the computer systems that were evaluated by the National Computer Security Center (NCSC).

The NCSC evaluated version 3.5 of the Windows NT operating systems, but you will need the information in Administrator's Guide as well as the resource kits for version 4.0 of Windows NT Server and Windows NT Workstation when setting up a system for C2 certification.


Internet Information Server Authentication

Internet Information Server enables you to control access to your information site by using Windows NT user accounts. The following sections describe:

  • The user account created by Internet Information Server.
  • The effect of a server's role on the IUSR_computername account and the effect of domain-based security on user accounts used by Internet Information Server.
  • Typical security scenarios for intranet and Internet sites that use Internet Information Server. The security scenarios include anonymous access, Basic authentication, and Windows NT challenge/response (secure) authentication.


Domain Accounts and Local Accounts

During installation, Internet Information Server creates IUSR_computername, a standard user account, as the user name for all anonymous access. A random password is generated for IUSR_computername. Just like any user account, the account is added to the local or domain directory database and can be modified by using User Manager.

The role of a server—as a primary domain controller (PDC), backup domain controller (BDC), or stand-alone server—influences how IUSR_computername user accounts are created and used by Internet Information Server.

If Internet Information Server is installed on a primary domain controller or backup domain controller, the IIS server user account is automatically added to the domain directory services database. All computers in that domain have access to validated users listed in the domain directory services database. The IUSR_computername account automatically becomes a domainwide account and can access resources across the domain.

If Internet Information Server is installed on a stand-alone member server, the IUSR_computername account is a local account. Computers in its domain cannot validate user accounts created on the stand-alone server. To enable access to resources on other servers in the domain if you have installed Internet Information Server on a stand-alone member server, change the default IUSR_computername account to an account with domainwide permissions.

The server role of the computer on which Internet Information Server is installed affects the authority of the IUSR_computername account created during setup. Table 3.1 summarizes these effects.

Table 3.1 Effect of Server Role on IUSR_computername Account Authority

Server role | Anonymous user account created | Account authority
Member server | Local_computer\IUSR_computername | Local only
BDC | Domain\IUSR_computername | Domain
PDC | Domain\IUSR_domainname | Domain


Log On Locally User Right

You must use User Manager or User Manager for Domains to assign the Log On Locally user right to all accounts used for access by Internet Information Server. The accounts used by Internet Information Server include:

  • The anonymous access account (the IUSR_computername account).
  • The account specified when creating virtual directories.
  • The accounts specified in .idc files for access to databases.
  • The user accounts specified by clients.


Anonymous Access

Internet Information Server permits anonymous access in the WWW, FTP, and Gopher services by default. There are no differences between an anonymous intranet site and an anonymous Internet site.

But even when you use anonymous access, all activity on a system running Internet Information Server determines permissions by user name. Associating a user name with every action is fundamental to Windows NT security.

During installation, Internet Information Server creates IUSR_computername, a standard user account, as the user name for all anonymous access. A random password is generated for IUSR_computername. The account is added to the local directory services database on stand-alone systems or to the domain directory services database on primary or backup domain controllers. You modify this account by using User Manager.

Internet Explorer and most other Web browsers do not provide a user name and password when connecting to a Web server, so Internet Information Server uses the IUSR_computername account, as shown in Figure 3.1.

Figure 3.1 Anonymous access process

Anonymous access is enabled by default. You set anonymous access by using the Service property sheet for each service. The account information for the IUSR_computername or other account specified in the Service property sheet must also agree with the settings in User Manager for the same account, as shown in Figure 3.2. Users are denied access if the user name and password do not match.

Figure 3.2 Matching user names and passwords in Internet Service Manager and User Manager

To provide only anonymous access—which is preferable for most installations—you clear the Basic (clear text) and Windows NT Challenge/Response boxes. If you provide anonymous access only, no one can use a Windows NT account maliciously. For example, anonymous-only settings prevent anyone from gaining access by using the Administrator account or any other account with sufficient permissions to alter your computer.


User Authentication

You can use Windows NT user accounts to control access to your entire server or to control access to certain files or directories. When the Anonymous check box on the Service property sheet is cleared, every initial request from a client causes an authentication dialog box to appear. If Anonymous is selected, and Basic (clear text) or Windows NT Challenge/Response is also selected, the user is prompted for a user name and password only if the user tries to gain access to a resource on a Windows NT File System (NTFS) drive and if that resource's properties do not allow the IUSR_computername account access.

Accounts used by Internet Information Server must be granted the Log On Locally user right—whether you specify that account in Internet Service Manager or the user supplies the user name and password. By default, user accounts on a Windows NT Server domain controller are not granted the Log On Locally user right. Be sure that any account on a domain controller that is used for access by Internet Information Server is granted the right to log on locally.

How you configure and use Windows NT user accounts is determined by the authentication method your clients support and whether you use authentication over your intranet or the Internet.

Intranet User Authentication

User authentication is easiest to use on an intranet with an existing Windows NT user account system. Because Internet Information Server uses Windows NT user accounts, you can use your network's existing accounts and domain structure, and administer the user accounts with the familiar User Manager. Figures 3.3 through 3.5 show Maria Gonzales (mariag) logging on by using her password (KamInop8).

If all of your clients run Internet Explorer version 2.0 or later, you can use Windows NT challenge/response authentication, which provides secure authentication, as illustrated in Figure 3.3. If you select Windows NT Challenge/Response, all requests from Internet Explorer version 2.0 or later use challenge/response authentication. All other browsers can connect only by using Basic authentication, and the Basic authentication check box must be selected.

Figure 3.3 Challenge/response process

Internet Explorer version 1.5 does not support Windows NT challenge/response authentication. If your clients run Internet Explorer version 1.5 or earlier, or any other Web browser (for example, Netscape Navigator), you cannot use challenge/response authentication. You can, however, use Basic (clear-text) authentication, as shown in Figure 3.4.

Figure 3.4 Basic authentication process

Warning

Basic (clear-text) authentication sends your Windows NT user name and password over the network unencrypted. User names and passwords sent by using Basic authentication can be learned and then used maliciously.

Basic authentication encodes the user name and password by using a base-64 algorithm—so it is not completely clear text. To intercept the user name and password, a network monitor must intercept the packet, then decode the packet containing the user name and password. With base-64 encoding, the user name or password can also contain characters that cannot be used inside a Hypertext Transport Protocol (HTTP) header.

If you are concerned about security on your intranet, you can use Basic authentication in conjunction with Secure Sockets Layer (SSL), as described in "Encrypting Private Data with SSL," later in this chapter. SSL encrypts the authentication process, as shown in Figure 3.5. However, in this scenario all transmissions are encrypted, which has a significant impact on server performance.

Figure 3.5 Basic SSL authentication process

Internet User Authentication

The principles just discussed in the intranet section apply to user authentication over the Internet. However, because you cannot assume everyone uses Internet Explorer version 2.0 or later to access your server, you must use Basic authentication in conjunction with SSL for secure authentication.

If you expect to create thousands of user accounts for clients on the Internet, you need to investigate the hardware requirements for maintaining a large number of user accounts. Table 3.2 outlines hardware requirements for domain controllers.

Table 3.2 Domain Controller Hardware Requirements

Approximate number of user accounts | User account database file size1 | Minimum processor needed | Required RAM2
Up to 3,000 | 5 MB | 486DX/33 | 32 MB
3,001-7,500 | 10 MB | 486DX/66 | 32 MB
7,501-10,000 | 15 MB | Pentium, MIPS® Rx4000, Digital Alpha™ | 48 MB
10,001-15,000 | 20 MB | Pentium, MIPS Rx4000, Digital Alpha | 64 MB
15,001-30,000 | 30 MB | Pentium, MIPS Rx4000, Digital Alpha | 128 MB
30,001-40,000 | 40 MB | Pentium, MIPS Rx4000, Digital Alpha | 166 MB

1 User account numbers are approximate. The exact file size of the directory services database depends on the number of user accounts, machine accounts, and group accounts.

2 RAM must be at least 2.5 times the size of the directory services database.

For more information about establishing large numbers of user accounts, see the white paper, Microsoft Windows NT Server Domain Planning for Your Enterprise, available on www.microsoft.com.


Encrypting Private Data with SSL

The Secure Sockets Layer protocol provides communications privacy over networks by using a combination of public key cryptography and bulk data encryption for data privacy. By using this protocol, clients and servers can communicate in a way that prevents eavesdropping, tampering, or message forgery.

Simplified Overview of SSL

Cryptography is a complex topic based on mathematics. To fully explain public key cryptography is outside the scope of this book. However, the following simplified explanation allows some basic understanding of SSL and public key cryptography. For more information about cryptography, consult the Internet or your local library.

Cryptographic keys are created at the same time in pairs: a public key and a private key. The public key is given to anyone (and is often made available though a public agency, such as a certificate authority). The private key is kept and safeguarded by you. Both keys are required for any exchange of information.

Internet Explorer encrypts data—such as a Hypertext Markup Language (HTML) form with private information—by using your server's public key. The encrypted data is sent to the server. The data is decrypted by the server, which uses its private key. The data can be decrypted only with the private key, held by the server.

Key Manager is used to generate the key pair and to activate the generated key. A key is not active until you send the certificate request file generated by Key Manager to your certificate authority.

For more information about using Key Manager, see the Internet Information Server Installation and Administration Guide.

Using SSL

Secure Sockets Layer is most effectively used by encrypting only communication that contains private data, such as credit card numbers, addresses, or company records. Because SSL uses your computer's processor to encrypt data, it takes much longer to retrieve and send data from SSL-enabled directories.

In your SSL-enabled directory, place only those pages that have or will receive sensitive information. Also, keep the content of pages in an SSL-enabled directory free from unnecessary elements because every item on the page will be encrypted, including simple graphics. Every element on the page increases the time it takes to transmit the data.


FTP Security

The File Transfer Protocol (FTP) is a legacy protocol. However, FTP remains a useful service because it can accept files from remote users or users of a different file system.

FTP Anonymous Access

FTP always uses user-level security, meaning the user must log on to gain access to the FTP server. The Internet Information Server FTP service can use the Windows NT user account database to authenticate users logging on. However, all FTP transmissions are in clear text, thus exposing user names and passwords.

The problem of exposed passwords is eliminated when an FTP server is configured to permit anonymous logons. Anonymous logon requires the user to type anonymous as their user name and their Internet e-mail address as their password. Anonymous users get access to files under the IUSR_computername account.

You can also allow anonymous-only logons to the Windows NT Internet Information Server FTP service. Anonymous-only logon is useful because it prevents real passwords from being revealed on a public network. FTP is configured for anonymous access by default.

For more information about configuring FTP for anonymous access, see the Internet Information Server Installation and Administration Guide.

Drop Box

You can create a drop box for your Internet customers to leave files in. The drop box must be on a drive formatted with NTFS. To create a drop box, right-click the folder that will become a drop box. Click Properties, click Security, and then click Permissions. Set the permissions for all users to write-only. After you have set write-only permissions, Internet users can put files in the drop box directory, but cannot see or copy any of the files left there. Only internal users with appropriate permissions can read the files.


Connecting Intranets to the Internet

Although you might want the users on your intranet to use the Internet, and want to give users from the Internet access to certain information, you probably do not want Internet users to have full access to your intranet.

When you connect an intranet to the Internet, you can use physical isolation, protocol isolation, third-party routers, and Windows NT routing in your network to provide security. The topology you choose affects the service you provide to intranet users.

Figure 3.6 illustrates the different network topology scenarios you can implement and how each scenario influences security and service for intranet users. The sections that follow in this chapter give more information about the benefits of each security topology illustrated in Figure 3.6. (Note that third-party Internet security devices and software are available, but are not discussed in detail in this chapter.)

Figure 3.6 How network topology affects security levels


Physical Isolation

A computer physically isolated from your intranet is the safest way to have Internet access, and the easiest to plan and configure. You can install Internet Information Server on it and use Internet Explorer to see and be seen by the Internet. Even the most clever hacker cannot browse your intranet without physical access. Of course, the computer running Internet Information Server is still open to attack and should be securely configured as described in the Internet Information Server Installation and Administration Guide.

Figure 3.7 Physical isolation security model

A limitation to this configuration is that you cannot share files between the intranet and the Internet. You have to use floppy disks or temporary network connections to share information between the two systems.

You can expand this scenario to create a small intranet of user kiosks and IIS servers connected to the Internet server by installing the RIP for Internet Protocol service.

The type of configuration you choose depends on the size of your organization and on how much Internet access you want to give to your users. For example, if you have a single computer connected to the Internet, it runs Internet Information Server. IIS provides information to share with Internet users, and (optionally) serves as an Internet client that uses Internet Explorer or other Internet software. For this computer to serve as an Internet client, however, it must be physically accessible to employees because it is not on the intranet.

To give users in your organization easier access to the Internet, you can set up a physically separate network. This network consists of the Internet server, additional Internet servers (such as additional IIS servers used as mirrors of the primary IIS installation), and individual workstations, or kiosks. The kiosks can be located in conference rooms, hallways, libraries, or in special offices throughout the company. Individuals who are heavy users of the Internet can have kiosks in their offices. The kiosks can be used to retrieve information from your Internet server, to place new information on the server, and to gather information from the Internet at large. This type of scenario, however, requires additional cable installation because all Internet-connected computers are physically separate from your intranet.


Protocol Isolation

If you want both Internet and intranet computers to communicate with the computer running Internet Information Server, you can use protocol isolation security. In this model, the Internet server has two network adapters. The network adapter connected to the Internet is bound to Transmission Control Protocol/Internet Protocol (TCP/IP). The network adapter connected to the intranet runs IPX (the transport protocol used in Novell® NetWare® networks) or any other network protocol except TCP/IP. Intranet users can copy files and maintain the server. However, they cannot access the IIS server because access requires TCP/IP. Internet users can "see" the IIS server, but cannot reach the intranet because reaching it requires IPX.

Figure 3.8 Protocol isolation security model

The protocol isolation security model works best for users who spend most of their time making information available to Internet users and who want to copy files directly from the intranet to the Internet server. Or, some users need to frequently download information that is left in a drop box by Internet users, and then integrate that material with information from corporate electronic mail and other resources on the intranet.

The resources on this server are accessible from either direction, but data cannot be passed through. Because of this, there is a virtual barrier to passing packets through the server. Such barriers are often referred to as firewalls.

The advantage of the protocol isolation security model is that your users can share information with Internet users from their workstations on the intranet without exposing the intranet to unauthorized use.

One disadvantage of using this model is that your users cannot directly access the Internet or Internet Information Server. The users cannot search for or retrieve Internet resources, only those resources on the computer running Windows NT Server. Users also cannot exchange mail with other Internet users unless you have provided the necessary Internet mail server services on the server.

Another disadvantage is that, theoretically, an Internet user can maliciously penetrate this security model. However, it is very challenging since the server does no protocol conversion.

Replicating the Internet Server on Your Network

A variation on the protocol isolation security model is to replicate the data on the Internet server onto another computer on the internal intranet by using the Windows NT Replication service.

Figure 3.9 Using the Windows NT Replication service for security

For example, if you use the Internet server as a drop box for customer questions and suggestions, Internet users leave information on the Internet server, and then the Windows NT Replication service replicates the contents of the Internet server to the intranet computer. Conversely, if your intranet users need to post information to the public, users on your corporate net copy the information to be shared to the intranet intermediary computer, and then that information is replicated to your Internet server. The intermediary computer can also run Internet Information Server to provide an internal version of your Internet site. This is a scenario used in the Microsoft corporate intranet.

A replication scenario also allows more control over what is brought into the intranet and permitted out of the intranet. Files can be checked for viruses or other problems. You can also use TCP/IP on your intranet because the IPX segment between your intranet and the Internet provides protocol isolation.

For more information about replication, see Chapter 4 of the Windows NT Server Concepts and Planning guide.


Third-Party Router Security on TCP/IP-Based Intranets

If you use TCP/IP on a large intranet with high volume or multiple subnets, you probably use a third-party router and a leased-line connection to the Internet. If your third-party routers create a firewall by filtering packets, you can use the router as an Internet gateway.

You can specify exactly which packets are routed from the intranet to the Internet and vice versa. Typically, you do not permit any unrequested packets to enter your intranet and you specify the intranet users who are permitted access to the Internet. Router configuration and topology for this type of application is often provided by the router vendor.

Figure 3.10 Third-party TCP/IP router security

For more information about third-party router capabilities, see your third-party vendor or third-party router documentation. For more information about using routing with Windows NT Server, see Chapter 4 in the Windows NT Server Networking Supplement.


Windows NT Router Security on TCP/IP-Based Intranets

If you use TCP/IP on your intranet, you can create a firewall in the computer running Windows NT Server by disabling internal TCP/IP routing. And you can still provide Internet Information Server services to both intranet and Internet users.

Figure 3.11 Disabled TCP/IP router security

TCP/IP routing controls whether data is passed to and from the intranet through the computer running Windows NT Server; that is, it controls whether the computer acts as a gateway, as shown in Figure 3.11.

The router feature works both ways. Either traffic can pass in both directions or traffic cannot pass through the server at all. This security model has all the advantages and disadvantages of the protocol isolation model.

A major concern with this model is that the separation between the Internet and your intranet depends on a single option in the TCP/IP configuration (or in the associated Registry entry). An intruder who somehow enters through your computer running Windows NT Server needs to change only one Registry value to expose your internal TCP/IP-based intranet.

If you use this security model, you need to be especially careful to control physical and administrative access to the computer that runs Internet Information Server. An individual familiar with Windows NT configuration tools and administrative permissions can find and change the Router check box in a matter of minutes.


Full Internet Access

Some organizations need to provide an unrestricted Internet gateway for their users. For example, researchers need to scan the Internet directly as a major part of their work, and then combine information gleaned from the Internet with information that is on the intranet. Each of these users does not need to connect to the Internet through a modem. Instead, one computer running Windows NT Server can serve as a simple gateway to the Internet, as shown in Figure 3.12.

Figure 3.12 A Windows NT–based computer serving as a gateway to the Internet

The computer that serves as a gateway must have:

  • A connection to the Internet.
  • TCP/IP protocol.
  • The RIP for Internet Protocol service.

Internet Information Server can run on the gateway computer, but it is optional.

For information on configuring TCP/IP routing and the RIP for Internet Protocol service, see the Windows NT Server Networking Supplement and Windows NT Server Resource Kit: Windows NT Server Networking Guide.

Routing works both ways. Either traffic can pass in both directions or traffic cannot pass through the server at all. If you enable the RIP for Internet Protocol service, you need to protect all sensitive data on your intranet by other means, such as access control on NTFS drives.

Make sure that the users who have direct Internet access are aware of the security issues. In fact, you should periodically remind them of these issues.

It is most convenient to run Internet Information Server on the computer that serves as the Internet gateway. It is an ideal place for shared directories where Internet users and users of the intranet can deposit and retrieve files, and for indexes of those files.

Also note that Internet users running Windows NT, Windows for Workgroups, LAN Manager, or MS-DOS networking clients can connect to resources on any computer connected to the Internet by issuing net use commands. An Internet user running Windows NT, Windows for Workgroups, LAN Manager, or an MS-DOS networking client can issue a net view command and then see a list of your corporate servers. Standard Windows NT security controls this method of access.

For more information about Windows NT security, see Windows NT Server Concepts and Planning, the Internet Information Server Installation and Administration Guide, and the Microsoft Windows NT Resource Kit: Windows NT Server Resource Guide.


Additional Security Methods

You can use methods other than network topology to secure and monitor your network. The rest of this chapter explains these methods, which include:

  • Using third-party router packet filtering to prevent unwanted access.
  • Configuring user account security to control access through the IUSR_computername account.
  • Using file system security to prevent access to portions of a disk (or partition) and audit file use.
  • Using the security log in Event Viewer to audit access to the computer running Internet Information Server and to all NTFS files available through Internet Information Server.
  • Using Internet Information Server logs to track use of your IIS services.

For more information about Windows NT security as it relates to Internet Information Server, see the Internet Information Server Installation and Administration Guide.


Using Firewalls and Other Inbound Security

Third-party products can create firewalls between the Internet and your intranet. Most of these products are based on packet filtering. Packet filtering takes place when the computer examines the source and destination IP addresses of a packet and forwards only those packets that have been granted access.

Many third-party routers that connect your intranet to the Internet can be configured to filter packets based on the source or destination IP address. You can specify which IP addresses are allowed or denied access into your intranet.

For more information about the packet filtering products available, consult dedicated router vendors.


Windows NT User Account Security

A primary security measure to observe at all times is to guard the Administrator account and administrative permissions on computers connected to the Internet. Give the passwords for these accounts only to employees with appropriate security clearances.

External Internet users can get access to your intranet through the Guest or IUSR_computername account. To ensure that the permissions for these accounts on your Internet gateway and Internet Information Server are configured to prevent intrusion, restrict the accounts to read-only access on public directories.


Using File System Security

If you create an Internet gateway or run Internet Information Server on one of your networked computers, use NTFS security settings to control access to specific files and directories and to configure the behavior of files and directories. This security method requires the disk or disk partition to be formatted as NTFS. It is a good idea to keep all files that are available through Internet Information Server on a disk or disk partition separate from your operating system, application, or personal files.


Auditing System Activity

You can use auditing to track selected activities of users and the system. Windows NT can record a range of event types—from a systemwide event, such as a user logging on, to an attempt by a particular user to read a specific file on an NTFS drive. Both successful and unsuccessful attempts to perform an action can be recorded.

To open the Audit Policy dialog box, click Audit on the Policies menu in User Manager for Domains. The audit policy determines the amount and type of security logging that Windows NT performs. When an audited event occurs, an entry is added to the Windows NT security log. The security log is viewed by using Event Viewer. Use the settings shown in Table 3.3 to specify what events will be audited.

Table 3.3 Auditing Options

For this event | Select | To audit
Log on and log off | Success | A user successfully logged on or off the workstation, or the user made an over-the-network connection to the local computer.
 | Failure | A user attempted, but was not allowed, to log on or off the workstation, or the user attempted and failed to make an over-the-network connection to the local computer.
File and object access | Success | A user successfully accessed a directory, printer, or file that is set for auditing.
 | Failure | A user attempted, but failed, to access a directory, printer, or file that is set for auditing.
Use of user rights | Success | A user successfully used a user right. (Rights relating to log on and log off are not included.)
 | Failure | A user attempted, but failed, to use a user right.
User and group management | Success | A user or group account was successfully created, modified, or deleted, or a password was successfully set or changed.
 | Failure | There was an unsuccessful attempt to: · Create, modify, or delete a user or group account. · Set or change a password.
Security policy changes | Success | A change was successfully made to the user rights or audit policies.
 | Failure | A change was attempted to the user rights or audit policies, but failed.
Restart, shutdown, and system security | Success | A user successfully restarted or shut down the computer; or an event has occurred that affects system security.
 | Failure | A user attempted, but failed, to restart or shut down the computer.
Process tracking | Success | Detailed tracking information for events such as successful program activation, some forms of handle duplication, indirect object access, and process exit.
 | Failure | Detailed tracking information for events such as failed program activation, some forms of handle duplication, indirect object access, and process exit.

Before auditing can be established on objects, auditing for the events shown in Table 3.3 must be enabled through User Manager for Domains by a user with Administrator permissions. When auditing files, you must also use Windows NT Explorer to specify which files to audit and which type of file access events to audit. To do this, right-click a file or directory to display its properties, then click Security and click Auditing to specify auditing attributes.

You view audited events in Event Viewer. Internet Information Server generates entries in all three Event Viewer logs (System, Security, and Application). You can use Event Viewer entries to identify attempts to break into your intranet through your gateway or to detect attempted tampering with your Internet Information Server system.

For more information about auditing, see Windows NT Server Concepts and Planning.


Auditing Access with Internet Information Server Logs

You can use Internet Information Server logs to track use of your IIS services.

Logging is very flexible. You can configure it to suit your site's needs. For example, two or more IIS servers can log to the same network file or network database. This is useful for large sites or for sites that use duplicate servers for load balancing. Conversely, if you also run the FTP or Gopher service, you can specify separate files or databases to track access by each service.

By logging to a database, you can use database reporting tools or the Internet Database Connector to query and analyze the log files to detect suspicious activity.

Suspicious activity can include:

  • Multiple failed commands, especially to the /Scripts directory or another directory configured for executable files.
  • Attempts to upload files to the /Scripts directory or another directory configured for executable files.
  • Attempts to access .bat or .cmd files and subvert their purpose.
  • .Bat or .cmd commands maliciously sent to the /Scripts directory or another directory configured for executable files.
  • Excessive requests from a single IP address attempting to overload or cause a denial of service to other users.

Logs are generated in CERN (European Laboratory for Particle Physics) format but can be converted to Common Log File (National Center for Supercomputing Applications [NCSA] or European Microsoft Windows NT Academic Center [EMWAC]) formats. Conversion is often necessary to use third-party log analysis tools.

For more information about logging, see the Internet Information Server Installation and Administration Guide.


Chapter 4 - Desktop Scenarios

Internet technology offers new ways to communicate and do business. However, you do not need a connection to the public Internet to benefit from technology developed for the Internet. Peer Web Services (Windows NT Workstation) or Internet Information Server (Windows NT Server) and Internet Explorer (an Internet client) can bring the ease of use and rich content of the Internet to your intranet.

The scenarios in this chapter demonstrate single-computer implementations on a corporate desktop computer or small department server. In the first scenario, a desktop computer running Windows NT Workstation and Peer Web Services provides employees timely information about the corporation's recent network merge. The second scenario demonstrates a departmental production server running Windows NT Server and Internet Information Server (IIS). The departmental IIS server provides employees access to Human Resources information.

The scenarios are based on Terra Flora, a fictitious international floral company described in this chapter's first section, "Terra Flora—A Case History." The scenarios show you how to use Windows NT Server Internet Information Server to solve business needs from team communication to global enterprise networking. In Chapter 5, "Enterprise Scenarios," you will find additional scenarios that use or simulate multiple servers. The chapters use scenarios that are presented as if an administrator were implementing a staged rollout of Internet Information Server in a corporation.

You can find more information about Terra Flora, including how this fictitious company used Windows NT Server to achieve networking interoperability, in the Microsoft Windows NT Server Resource Kit: Windows NT Server Networking Guide.


Terra Flora - A Case History

Terra Flora, a retail floral corporation, began selling flowers in the 1970s. Over the next 25 years, Terra Flora expanded to include a nursery business and a terra cotta manufacturing plant that produces pots and vases for the retail outlets. Now, in the mid-1990s, these three semiautonomous businesses employ more than 40,000 employees in eight locations, as shown in Figure 4.1.

Figure 4.1 Terra Flora organization

Terra Flora recently physically combined the networks of all divisions, resulting in the network shown in the diagram on the inside back cover of this book.

This diagram represents the significant elements that are present in the Terra Flora network. The size and complexity of a multinational corporate network cannot be represented in a single diagram. References in this book use the computer names on this diagram to provide the network context of a particular scenario. In some scenarios, the actual computer shown in the diagram is used, such as domain controllers or DNS servers. Other scenarios include references to computers that are not illustrated in the diagram; however, the computer's relative position in the network is shown.

Within this network, each of Terra Flora's three divisions has its own autonomous network and information sources, as shown in Table 4.1.

Table 4.1 Terra Flora Systems

Information stored | Format | Computer system
Retail Division
Retail order database, Accounting database, Employee database | ORACLE database | Sun® Solaris
Corporate and employee information | Word and other documents | Intel-based servers running Windows NT and NetWare
Manufacturing Division
Parts and price lists | Microsoft Excel worksheets | Intel-based servers running Windows NT and NetWare
Raw materials tracking database | DB2 database | AS/400 running VMS
Wholesale terra cotta gifts catalog | Microsoft Publisher | Intel-based computers running Windows NT Workstation
Nursery Division
Inventory and wholesale order database | RPG/400 | DECpc150 running DEC PATHWORKS
Wholesale flower catalog | ORACLE database | Sun Solaris

The network was made to interoperate by using Windows NT as the integrating platform. Additionally, Terra Flora centralized administration tasks at corporate headquarters in Sacramento, California.

Now that the entire corporation is interconnected, Terra Flora is faced with the challenge of making its information available on the network to everyone in the company—and to customers around the world.

Microsoft Internet Information Server has been selected as the tool to bring Terra Flora's information to its employees and customers. The scenarios in this book explain how Internet Information Server makes information accessible internally and to customers around the world.

You can find more information about the Terra Flora example, including extensive information about how Windows NT Server can be used to achieve networking interoperability, in the Windows NT Server Networking Guide.


Accessing Information at Terra Flora

To create an intranet, you need to evaluate your network architecture, review your information needs, and develop an information deployment plan.


Network Architecture

Terra Flora standardized on Transmission Control Protocol/Internet Protocol (TCP/IP) as its single network protocol. It chose TCP/IP as its primary protocol because all of the network operating systems in use at Terra Flora support TCP/IP. Also, TCP/IP routing minimizes network traffic both on the local network and across wide area network (WAN) links.

With TCP/IP, Terra Flora can use applications that have been developed to comply with the standards put forth in requests for comment documents (RFCs) created by the Internet Engineering Task Force (IETF). These international standards, such as the Hypertext Transport Protocol (HTTP) and the TCP/IP protocol suite, enabled the global Internet to develop.


Reviewing Information Needs

Before its merged network was created, Terra Flora's information was contained in different databases and file formats across three separate networks. The information needed to be accessible to customers on those networks and on networks around the world. It was clear to the information officer that a single technology was required to effectively consolidate and deliver that information. Internet technology, based on HTTP, provides a single system that can deliver information to users around the world.

First, the formats and users of each existing information type were identified. Next, the Internet technology that could serve the information to the largest number of people was identified. Table 4.2 summarizes this information.

Table 4.2 Terra Flora Information Consolidation

Information stored | Format | Users | New access method
Retail Division |  |  |
Retail order database, Accounting database, Employee database | ORACLE database | Internal, external | HTML forms
Corporate and employee information | Word and other documents | Internal | WWW directory listings
Manufacturing Division |  |  |
Parts and price lists | Text files | Internal, external | FTP and Gopher
Raw materials tracking database | DB2 database | Internal | None
Wholesale terra cotta gifts catalog | Microsoft Publisher | External | HTML
Nursery Division |  |  |
Inventory and wholesale order database | RPG/400 | Internal, external | None
Wholesale flower catalog | ORACLE database | External | HTML forms


Planning Content Strategy and Deployment

The information officer, Maria Gonzales, has the task of integrating disparate information sources. Internet technology offers the easiest, most cost-effective method to access the information.

Three groups of content users were identified:

  • Workgroup users
  • Division users
  • Enterprise users

Each group of users has a specific goal and uses a particular kind of content, as identified in Table 4.3.

Table 4.3 Content Strategy

Users | Goal | Content
Workgroup | Team communication and collaboration | Plans development, document sharing
Division | Division communication and collaboration | Internal supply, part number listing, employee directory, employee handbook
Enterprise | Corporatewide communication and collaboration; migrating mission-critical applications to Internet technology | Plant and products catalog, retail ordering system

Maria has chosen to phase in the integration of components, building on the success of each step, as shown in Table 4.4.

Table 4.4 Terra Flora Implementation Phases for Information Servers

Phase | Goal | Method
1 | Team communication | Peer Web Services on an intranet desktop (see this chapter)
2 | Division communication | Internet Information Server as a single intranet server (see this chapter)
3 | Corporate collaboration | Creating virtual servers by using Internet Information Server (see Chapter 5)
4 | Migrate mission-critical applications to Internet Information Server | Internet Information Server as a front end to a database (see Chapter 5)
5 | Support heterogeneous clients on the network | FTP and Gopher servers (see Chapter 5)

You can find related scenarios and more information about the Terra Flora example, including extensive information about how Windows NT Server can be used to achieve networking interoperability, in the Windows NT Server Networking Guide.


Peer Web Services on an Intranet Desktop

Maria Gonzales needs to communicate with her staff and with network users.

The recent interconnection of three networks has given the Terra Flora information services department the ability to reach any computer in the company, but no tool exists on all the platforms to allow easy communication with every client. The lack of communication is hampering the adoption and use of the newly interconnected networks.

To provide a central communication center, Maria Gonzales announces in e-mail the address of a network directory from which network users can install Internet Explorer, and the address for her computer running Peer Web Services, http://mariag.


Peer Web Services Hardware Configuration

Because Peer Web Services is easy to use and is integrated with Windows NT Workstation, Maria installs it on her personal computer running Windows NT Workstation version 4.0. The computer has the following equipment.

  • Intel 486 processor with clock speed of 66 MHz
  • 32 MB of RAM
  • 1 GB of hard disk space


Peer Web Services Network Configuration

The advantage of using Peer Web Services for workgroup communication is that it needs little configuration to start operating in the network. Once Peer Web Services is installed and running, no manual network configuration is necessary.

The computer used to run Peer Web Services (see Figure 4.2) is similar to the computer CANTW40DSK01 in the Terra Flora network diagram.

Figure 4.2 Network overview of Peer Web Services

TCP/IP Properties

The IP address and all TCP/IP properties for this computer are dynamically assigned by the network DHCP server CANTS40ENT03 during computer startup. The WINS server, also on CANTS40ENT03, is also notified of the IP address and of the computer name, MARIAG. (For more information about DHCP and WINS, see the Windows NT Server Networking Supplement and the Windows NT Server Networking Guide.)

Name Resolution

All Internet Explorer users address the Peer Web Services computer by using the NetBIOS name of the information officer's computer. The client's TCP/IP protocol automatically queries the Windows Internet Name Service (WINS) server when a NetBIOS computer name (for example, http://mariag) is used to address a Peer Web Services site. The WINS server provides the IP address currently assigned by Dynamic Host Configuration Protocol (DHCP) to that computer name. The DHCP assignment and WINS registration process is dynamic, so regardless of the IP address currently assigned to MARIAG, Internet Explorer users can always resolve http://mariag to the current IP address by using the WINS server.

Peer Web Services Configuration

The default installation of Peer Web Services does not need to be changed for immediate use of the information server. Default settings work for most installations.


Anonymous Access and Challenge/Response Authentication

Some of the information made available through Terra Flora's World Wide Web (WWW) service pilot project needs to be accessible to all employees, so Maria keeps the default selection—Allow Anonymous. Because anonymous access is configured by default, it requires no additional configuration. Maria uses the default home directory (Wwwroot) for content available by anonymous access.

Maria also makes available content that needs to be accessible only to team members. Because all team members are running Windows NT Workstation version 4.0, they have on their desktops Internet Explorer version 2.0, which uses the Windows NT challenge/response password method. Maria uses this authentication method to limit access to team information. Basic authentication is available, but is used only when authenticated clients do not support challenge/response.

For more information about Basic and challenge/response authentication, see Chapter 3, "Server Security on the Internet."

First, Maria creates a virtual directory (/Team) on a Windows NT File System (NTFS) drive for the team information, as shown in Figure 4.3.

Figure 4.3 Adding a virtual directory in Peer Web Services

Next, Maria sets the properties for that directory to allow access by team members only. She removes the group Everyone. She adds access for the team members by giving the local group ISTeam full control over the directories, as shown in Figure 4.4.

Figure 4.4 Setting directory permissions

Now, only members of ISTeam are granted access to the Project Plan directory (shared in Peer Web Services as /Team). All existing Windows NT security and groups can be integrated and used with Peer Web Services and Internet Information Server.


Providing Static Content

Maria uses Internet Assistant to create the Hypertext Markup Language (HTML) file Wwwroot\Default.htm. This file is the home page or initial page of information for the site. (See Figure 4.5.) The home page is for the network users and contains information about network status.

Figure 4.5 Terra Flora network integration home page

Next, Maria creates D:\Project Plan\Default.htm as the home page for her team. On this page, Maria also includes links to non-HTML files, such as the Microsoft Project file for the network integration plan, and to historical data in text files. (See Figure 4.6.)

Figure 4.6 IS team home page

Finally, to determine who is using the files, Maria configures logging to create weekly log files. (See Figure 4.7.) Later, Maria will use the convlog program to convert the log to National Center for Supercomputing Applications (NCSA) format, and will then import the log files into a Microsoft Access database to analyze the use statistics and to generate reports.

Figure 4.7 Logging to a file


Peer Web Services Internet Considerations

This same configuration works on the Internet without modification. Standard security issues apply, as described in the Peer Web Services Installation and Administration Guide HTML documentation and in Chapter 3 of this book.

Peer Web Services is optimized for use as a personal information server for light duty, such as in a workgroup. It does not support the heavy use that can occur on the Internet.

Internet Explorer version 2.0 or later is the only HTTP browser that supports the Windows NT challenge/response authentication system. To accommodate other browsers, you must use the Basic authentication system, which is not secure. You must either use Basic authentication, which sends user names and passwords by using base-64 encoding (and can be decoded easily), or you must implement SSL (Secure Sockets Layer) on your entire site.


Internet Information Server as a Single Intranet Server

The Terra Flora employee handbook is several years out of date and the Human Resources department has requested that an online version be provided to employees as soon as possible.

To meet the goal of a common information source, easily accessible by a variety of clients, Maria chose to install an IIS server. Internet Information Server does not require dedicated hardware, so Maria installed it on an existing file and print server that runs Windows NT Server.


Internet Information Server Intranet Server Hardware Configuration

The existing file and print server is two years old. The low system demands of Internet Information Server will not significantly impact file and print performance, so running Internet Information Server on older hardware is practical, but the following configuration is optimal.

  • Intel 486 processor with clock speed of 66 MHz
  • 32 MB of RAM
  • 1 GB of hard disk space


Internet Information Server Intranet Server Network Configuration

The computer used for the intranet server is similar to the computer CANTS40DPT01 in the Terra Flora network diagram. (See Figure 4.8.)

Figure 4.8 Internet Information Server intranet server network overview

TCP/IP Properties

The IP address and all TCP/IP properties for this computer are dynamically assigned by the network DHCP server CANTS40ENT03 during computer startup. The WINS server, also on CANTS40ENT03, is also notified of the IP address for the computer and of the computer name, HR.

Name Resolution

The computer name for the Human Resources server is HR. All Internet Explorer users automatically query the WINS server when using the name of the computer, for example, http://hr/. The WINS server provides the IP address currently assigned by DHCP to that computer name. The DHCP assignment and WINS registration process is dynamic, so regardless of the IP address currently assigned to HR, Internet Explorer users can always resolve http://hr to the current IP address.

Internet Information Server Configuration

The default installation of Internet Information Server does not need to be changed for immediate use of the information server. Default settings work for most installations.


Anonymous Access

All the information made available through this WWW service pilot project must be accessible to all employees. Anonymous access is enabled by default in Internet Information Server. By clearing the Windows NT Challenge/Response check box, Maria allows only anonymous access.

Because this is a pilot project, it is important to collect statistics to determine who is using the files. Maria configures logging to a Microsoft Access database. (See Figure 4.9.) Although logging to a database requires processing time, internal use is expected to be light so the overhead will be minimal. In addition, instant access to the Microsoft Access custom reports based on the Internet Information Server logs is a real benefit for the information officer.

Figure 4.9 Logging to a database

Excluding Computers by DNS Name

Retail outlet point-of-sale computers should not be able to access the IIS server. To prevent the retail stores from accessing the IIS server, the IP addresses of the point-of-sale computers are excluded from access to the information server by using the Advanced property sheet, as shown in Figure 4.10.

Figure 4.10 Excluding computers on the Advanced property sheet

It is not necessary to know the IP address of the computers to be denied. Because a DNS server is available (CANTS40ENT01), after you click Add you can click the ellipsis (…) button next to the IP address box and enter the DNS name of the computer. Internet Information Server queries the DNS server to resolve the name for you, as shown in Figure 4.11.

Figure 4.11 Resolving DNS names for exclusion


Directory Listings to Provide Content

It is not necessary to use the HTML format for the content on Internet Information Server or Peer Web Services. You can use directory listings to automatically display the contents of directories, similar to the Windows NT Explorer display.

New information about Terra Flora's Human Resources department will be written in HTML by using Internet Assistant for Microsoft Word. The files will be placed in the default directory, Wwwroot. The home page for the Human Resources department will be Wwwroot/Default.htm. Because the home page is named Default.htm, users need only specify http://hr/ to view the Human Resources home page, as shown in Figure 4.12.

Figure 4.12 Human Resources home page

From the HTML home page, users can view existing Human Resources information that exists in multiple formats, including Microsoft Word documents. Rather than convert all the documents to HTML format, the existing documents are presented by using WWW directory listings. On the Directories tab of the WWW Service Properties dialog box, directory browsing is enabled, as shown in Figure 4.13.

Figure 4.13 Enabling directory browsing

The employee handbook files were created and are maintained by using Microsoft Word. The handbook resides on another Windows NT–based file and print server. A virtual directory called "handbook" is created that points to the network directory on the Terra Flora computer CANTS40DIV01, as shown in Figure 4.14.

Figure 4.14 Creating a virtual directory

Because the default document, Default.htm, does not exist on the network directory, but directory browsing is enabled, when users connect to http://hr/handbook (or click the link on the HTML home page), they see a listing of the handbook files.

Twenty files are combined to make up the handbook and are named according to the contents of the file. For example, the information about medical benefits is in the file Medical Benefits.doc, as shown in Figure 4.15.

Figure 4.15 WWW directory listings

When Internet Explorer users double-click a filename in the listing, such as Medical Benefits.doc, Word automatically starts and displays the selected file. All employees in the company have access to the files by using directory browsing.

To prevent anyone from tampering with the handbook, the files are accessed by using the user account handbook_user, an account local to the CANTS40DIV01 server, as shown in Figure 4.14. This account was created specifically to provide read-only access to the handbook files. When an account is specified in the Directory Properties dialog box, this account overrides any account information provided by the user.


Internet Considerations

This same configuration works on the Internet without modification. Standard security issues apply, as described in the Internet Information Server Installation and Administration Guide and in Chapter 3 of this book.


Chapter 5 - Enterprise Scenarios

An enterprise network is a network for an organization that has several thousand employees and that operates at multiple sites. Typically, large networks have several different standards in use across the network. Interoperability and communication are constant challenges for the information staffs of enterprise networks.

The diagram inside the back cover of this book illustrates the enterprise network for Terra Flora, a fictitious international floral company.

The Terra Flora enterprise network was created in Microsoft laboratories to demonstrate Windows NT interoperability features for an enterprise network. The Windows NT Server Resource Kit: Windows NT Server Networking Guide contains chapters that show you how Windows NT Server solved the interoperability challenges posed by the Terra Flora enterprise network.

Chapters 4 and 5 in this book show you how to use Windows NT Server Internet Information Server (IIS) to meet business communication needs—from team communication to mission-critical applications. The chapters use scenarios that are presented as if an administrator were implementing a staged rollout of Internet Information Server to the company. See Chapter 4, "Desktop Scenarios," for a complete description of the Terra Flora company and its network.

The scenarios in this chapter use or simulate multiple servers. The scenarios covered are:

  • A single production server using virtual servers to host "multiple" web sites on a single computer.
  • Database access for a mission-critical application.
  • File Transfer Protocol (FTP) and Gopher servers for access to the same set of Human Resources information.
  • Multiple computers running Windows NT Server and Internet Information Server demonstrates a large-scale Internet implementation of IIS.


Creating Virtual Servers by Using Internet Information Server

In this scenario, Terra Flora has successfully deployed Internet Information Server on a department-level server (see Chapter 4) and is setting up an IIS server for each division.

This scenario assumes that dedicated hardware is not available for each division's IIS server. Therefore, Terra Flora installs Internet Information Server on an existing computer running Windows NT Server, then creates a virtual server for each division, as shown in Table 5.1.

Table 5.1 Computer Names for Terra Flora Divisions

Division | Computer name URL
Retail | http://retail
Supply and Manufacturing | http://supply
Nursery | http://nursery

These servers will provide information—such as project plans and employee services—to new members or to other division employees. For examples of how Terra Flora will distribute information, see the section "Information Distribution," later in this chapter.

Ideally, each division operates a separate server. Automatic IP address administration by Dynamic Host Configuration Protocol (DHCP) and Windows Internet Name Service (WINS) name resolution works on separate servers that are each addressed with a single Internet Protocol (IP) address. After you install Internet Information Server, name resolution on the network automatically "finds" the IIS server; no additional network configuration is required for name resolution. DHCP and WINS are designed to work together for automatic name resolution on a network, as explained in Chapter 2.

For example scenarios that use automatic DHCP configuration and WINS resolution, see "Peer Web Services on an Intranet Desktop" and "Internet Information Server as a Single Intranet Server" in Chapter 4, "Desktop Scenarios."


Virtual Server Hardware Configuration

The virtual servers are installed on a new file and print server. The new server provides adequate resources for the three IIS servers, in addition to its primary role as a file and print server and a messaging server.

Here is the hardware configuration for the IIS server that will host the virtual servers:

  • Pentium dual processor with clock speed of 100 MHz
  • 64 MB of RAM
  • 10 GB disk


Virtual Server Network Configuration

Terra Flora uses virtual servers for its division-level IIS servers because it does not want the expense of dedicated IIS servers for the initial rollout. The network configuration of a virtual server on an intranet requires multiple IP addresses and name resolution for each IP address assigned. Figure 5.1 highlights the components in the Terra Flora network that are involved in creating enterprise virtual servers by using Internet Information Server.

Figure 5.1 Virtual server network overview

The virtual servers are hosted on the computer CANTS40DIV01, which also is a file and print server and a messaging server. Name resolution is provided by CANTS40ENT03. All clients in the network except MS-DOS-based clients can access the virtual servers.

If you use DHCP servers and WINS servers on your network, as Terra Flora does, it is best to avoid using IIS virtual servers.

Virtual servers require you to manually configure Transmission Control Protocol/Internet Protocol (TCP/IP) properties on the computer running Internet Information Server and also to manually configure the name resolution system in use on your network.

DHCP and WINS are designed to work together for automatic name resolution on a network, as explained in Chapter 2. Automatic administration means that name resolution on the network is completely automated. Every time the IIS server starts, it is automatically given an IP address and its name is registered on the WINS servers used throughout the network. This method is demonstrated in "Peer Web Services on an Intranet Desktop" and "Internet Information Server as a Single Intranet Server" in Chapter 4, "Desktop Scenarios."

If you do not use DHCP or WINS servers on your network, installation of Internet Information Server requires manual configuration. Because virtual servers require little additional manual configuration, they are ideal for a network that does not use DHCP or WINS.

Virtual Server TCP/IP Properties

One IP address must be added to the network interface card (NIC) of CANTS40DIV01 for each virtual server. When you assign more than one IP address to a single network interface card , you must disable automatic DCHP configuration. The DHCP server cannot assign multiple IP addresses to the same network interface card.

You enter the IP addresses and all TCP/IP properties for this computer by using the configuration options available when you double-click Network in Control Panel. On the Protocol tab, select TCP/IP protocol and click Properties. Type the first IP address, subnet mask, and the computer's default gateway under Specify an IP Address on the IP Address tab. (See Figure 5.2.)

Figure 5.2 Setting TCP/IP properties for virtual servers

After you type the first IP address, subnet mask, and default gateway, click Advanced to display the Advanced IP Addressing dialog box, as shown in Figure 5.3. To add IP addresses to your network interface card, click the Add button under IP Addresses.

Figure 5.3 Adding more than one IP address

Virtual Server Name Resolution

The computer name of the computer hosting the IIS virtual servers is CANTS40DIV01 (see diagram inside the back cover of this book). When you use multiple computer names with multiple IP addresses on the same network interface card, you must configure the WINS server with the computer name/IP address pairs that you will use. Thus, when clients consult a WINS server, the server provides the computer name and IP address for your virtual server. (You can also configure the WINS server to override the default computer name/IP address pair used if only a single IP address is assigned to the network interface card of a computer running Internet Information Server.)

You use the WINS server (CANTS40ENT03 in the Terra Flora diagram) to assign three computer names (NetBIOS computer names) to the three static IP addresses configured on the computer running Internet Information Server. The names in the WINS database will be used by Windows-based clients for name resolution.

Use WINS Manager in the Administrative Tools folder to assign the NetBIOS names to the IP addresses you added to the network interface card of your computer running Internet Information Server. On the WINS Manager Mappings menu, click Static Mappings. In the Static Mappings dialog box, click Add Mappings and add each virtual server's IP address/NetBIOS name pair. After you have added the IP address/NetBIOS name pairs, the mappings appear as shown in Figure 5.4.

Figure 5.4 Virtual server WINS mapping

When an Internet Explorer client (or other browser) requests a Uniform Resource Locator (URL) that uses a NetBIOS name—such as http://retail—TCP/IP networking on the client automatically consults the WINS server to discover IP addresses. This is illustrated as step 1 in Figure 5.5. The WINS server notifies the client of the IP address assigned to that NetBIOS name (step 2). The client then uses the IP address to make the request to the computer running Internet Information Server (step 3).

Figure 5.5 WINS resolution for URL that uses NetBIOS computer name

Networks that do not use WINS can use an alternative name resolution system, usually Domain Name System (DNS) servers. DNS servers resolve a domain name—such as retail.terraflora.com—to an IP address.

If you use third-party DNS servers, you manually add a DNS A-type resource record to the zone data file for each virtual server IP address/DNS domain name pair. For more information about DNS resource records and their formats see RFC 883 and RFC 973 or the documentation for your DNS server.

Terra Flora uses both Windows NT WINS servers and Windows NT DNS servers. For example, both a WINS server and a DNS server are on CANTS40ENT03 on the Terra Flora network diagram. Because Terra Flora uses both WINS and DNS, there is no need to create actual DNS database entries for the new servers. Instead, you can provide a form of dynamic DNS by directing the Windows NT Server DNS server to query WINS for name resolution of the terraflora.com domain.

In DNS Manager, right-click the zone that will consult the WINS database for name resolution, and then click Properties. Click the WINS Lookup tab and enter the IP address of the WINS server, as shown in Figure 5.6.

Figure 5.6 Using WINS with DNS for name resolution

The DNS server automatically consults the WINS server to discover the IP address. For example, a UNIX computer requests the DNS server to resolve retail.terraflora.com to an IP address. Because the DNS server does not have an explicit record for retail.terraflora.com, it queries the WINS server for the name "retail." The WINS server has a static mapping for the NetBIOS name "retail" to the IP address 172.16.32.100 and returns that IP address to the DNS server. The DNS server then resolves the DNS name retail.terraflora.com based on the NetBIOS name mapping in WINS. This NetBIOS-name-to-DNS-name mapping is automatic for all names in the WINS server, including WINS mappings based on automatic IP address assignment by DHCP.

After you finish these configurations, users can then access the Internet Information Server virtual server by using either the NetBIOS name (if WINS is supported on the client) or the domain name (if DNS is supported on the client), as shown in Table 5.2.

Table 5.2 Virtual Server Computer Names Used in URLs

NetBIOS name | Computer name used in URL with WINS name resolution | Domain name URL used by DNS name resolution
RETAIL | http://retail | http://retail.terraflora.com
SUPPLY | http://supply | http://supply.terraflora.com
NURSERY | http://nursery | http://nursery.terraflora.com

For more information on WINS and DNS interoperability, see the Windows NT Server Networking Guide.

If your network contains non-Microsoft DNS servers, you must add a record in the DNS database for each IP address/domain name pair you add. The name resolution process is similar to WINS name resolution. For information about adding a computer to a domain, see your DNS server documentation.

You can also use HOSTS or LMHOSTS files on client computers for name resolution. On frequently accessed servers, this is slightly faster that consulting a WINS or DNS server, and also reduces network traffic. For more information on name resolution by using HOSTS and LMHOSTS files, see the Windows NT Server Networking Supplement.

To complete the creation of the virtual servers, you must now create a home directory for each virtual server, as described in the next section.


Internet Information Server Configuration to Create Virtual Servers

You use Internet Service Manager to create virtual servers. You will not see virtual server names in the main Internet Service Manager window. Virtual servers are created on the Directories tab of the WWW Service Properties dialog box, as shown in Figure 5.7.

Figure 5.7 Virtual server directories listed

To create a virtual server, click Add and, in the Directory Properties dialog box, specify a directory for each IP address configured on your server. (See Figure 5.8.) A virtual server is not "created" until a directory is created that uses the IP address of that virtual server.

Figure 5.8 Specifying the IP address for a virtual server directory

If a single IP address is used on a computer running Internet Information Server, all directories created apply to that IP address. If two or more IP addresses are added to a computer running Internet Information Server, you must then select the Virtual Server check box and type an IP address in the Virtual Server IP Address box for each IIS directory you create. If you fail to select the Virtual Server check box and to specify an IP address, that directory will be available through all IP addresses assigned to the computer.

The default home directory (wwwroot) and the /Scripts directory created during installation are not assigned to a specific IP address. Because no IP address is assigned to the directories, the default home directory becomes the default home directory for all TCP/IP addresses assigned to that server.

The /Scripts directory is a good example of a case that calls for using a common directory between virtual servers by not specifying an IP address. You can locate the scripts for all virtual servers on the computer in the same common directory. For example, http://retail/scripts/order.dll and http://supply/scripts/update.exe both use files in the same physical directory.


Using Groups for Selective Access

This section discusses how Internet Information Server authentication and Windows NT user accounts and global groups are used at Terra Flora to provide selective access to files served through Internet Information Server.

An overview of Terra Flora's use of Windows NT groups to provide selective access is shown in Figure 5.9.

Figure 5.9 Controlling access to files by using Windows NT groups

Although Figure 5.9 depicts a single directory structure for simplicity, directories can reside on other disks or even on other network shares.

Domainwide Anonymous Access

The Anonymous access layer of Figure 5.9 demonstrates anonymous access to the root directories provided by using the anonymous account specified on the Service tab in the WWW Service Properties dialog box.

In this Terra Flora scenario, Internet Information Server is installed on a stand-alone member server, CANTS40DIV01. The default anonymous account, IUSR_CANTS40DIV01, is a local user account. Because the server will access directories on network computers in the California domain, the account is added to the California domain by using User Manager for Domains, as shown in Figure 5.10. Adding the local account IUSR_CANTS40DIV01 to the California domain enables computers in that domain to authenticate access by Internet Information Server.

Figure 5.10 Accounts and global groups used at Terra Flora in User Manager

Alternatively, you can create a new account in the California domain for anonymous access and specify that account in Internet Service Manager on the Service tab in the WWW Service Properties dialog box.

Basic Authentication and Global Groups

The Basic authentication layer of Figure 5.9 demonstrates using Basic authentication and Windows NT groups to control access to subdirectories.

In Terra Flora, each department provides some information to the entire company, such as current project plans or an employee directory. However, each division or department also uses material that only its members should have access to.

To provide selective access, global groups are created for each division (Nursery, Retail, and Supply) by using User Manager on the primary domain controller, CANTS40ENT03. The Log On Locally user right is added to every user or group that will use the IIS server, as shown in Figure 5.11.

Figure 5.11 Assigning rights to groups in User Manager

You must also give the division groups read access to the directories. To do this, right-click the folder in Windows NT Explorer, then click Properties to specify group permissions in the Directory Permissions dialog box shown in Figure 5.12.

Figure 5.12 Designating the security properties for a directory

To complete the security configuration, Terra Flora appoints a webmaster in each division to control content on the servers. The Webmasters group is created and populated with the three division webmasters. Only the Webmaster group is given full control to the entire directory structure.

For more information about adding global groups to a domain and adding user rights to user accounts and groups, see Windows NT Server Concepts and Planning.

Challenge/Response Authentication and Global Groups

The Challenge/response authentication layer in Figure 5.9 demonstrates access that is granted to managers only by using Windows NT challenge/response authentication. A global group named Managers is created and populated with the user accounts of individual managers.

Read permission on all the budget information files is granted to the group named Managers. Full Control permission on individual files is granted to the individual manager responsible for the file.

The use of Windows NT groups demonstrated in this section is scalable and can be expanded to suit your business.

For more information about domain user accounts, local accounts, and the IUSR_computername account, see Chapter 3, "Server Security on the Internet."


Information Distribution

This section shows how to handle typical content on a division server and presents useful strategies for your business.

The division servers provide all employees access to process documents (how-to documents), current project plans, employee home pages, and links to related pages on other division servers, as shown in Figure 5.13.

Figure 5.13 Retail Division home page for entire company

Only employees in the division have access to that division's project templates, plans in development, and budgets. The Retail Division home page (Figure 5.14) shows what the employees in that division have access to.

Figure 5.14 Retail Division home page for Retail Division employees only

Retail employees collaborate on files in the \Division\Plans directory to create final project plans. When the plans are complete and approved, the webmaster copies the plan files to the root directory and creates links on the appropriate Hypertext Markup Language (HTML) pages so that all Terra Flora employees can read the plans.

Parallel directory structures enable you to copy entire directory structures to other servers without changing hard-coded relative links within the files. Parallel directory structures also simplify navigation, as shown in Figure 5.15.

Figure 5.15 Directory structure for Retail Division


Creating Virtual Servers on the Internet

Virtual servers on the Internet are the same as virtual servers on an intranet. You must register your domain names in the worldwide Domain Name System through the InterNIC. The InterNIC is a cooperative activity between the National Science Foundation, Network Solutions, Inc., and AT&T to provide DNS registration services to the worldwide Internet community. You can reach the InterNIC at http://internic.net. Some Internet service providers register domain names with the InterNIC for you.

If your Internet clients use Internet Explorer version 2.0 or later, you can use Windows NT groups for secure authentication by using challenge/response authentication. Netscape Navigator and other browsers do not support secure authentication by using challenge/response. They use Basic authentication, which transmits user names and passwords by using base-64 encoding. Base-64 encoding can be decoded easily. Because anyone monitoring the network can decode these user names and passwords, using Basic authentication on public networks is not recommended.

Once authenticated, either by challenge/response or Basic authentication, all data is transmitted in clear text. You can use Secure Sockets Layer (SSL) to encrypt all data, but SSL uses a lot of processor time to encode and decode every shred of data passed through Internet Information Server. Therefore, SSL is usually reserved for small amounts of private information, such as credit card numbers or addresses.

For more information about SSL, see Chapter 3, "Server Security on the Internet."


Database Application Using Internet Information Server

This scenario explains how the Internet Database Connector is used to create a core-business application that streamlines Terra Flora's internal processes and eventually will accommodate an expanded customer base.

The flower arrangement order desk is the heart of Terra Flora's business. By using Internet Information Server to post to and query the retail order Oracle database, anyone in the company can use the data. This scenario establishes an internal ordering system that uses Hypertext Transport Protocol (HTTP). The internal system will serve as a pilot for an Internet ordering system, which will expand Terra Flora's market to the entire world.

This section assumes that an Oracle database already exists.

For more details on using the Internet Database Connector and related control files (.idc and .htx), see the Windows NT Server Microsoft Internet Information Server Installation and Administration Guide.


Database Connector Hardware Configuration

Two computers—the computer running Internet Information Server and the computer running the Oracle database—must be configured for the network.

The computer running Internet Information Server has the following hardware configuration:

  • Intel 486 processor with clock speed of 50 MHz
  • 24 MB of RAM
  • 2 GB of free disk space


Database Connector Network Configuration

As the previous section mentioned, you must configure two computers for the network. Figure 5.16 highlights the components in the Terra Flora network that are involved in using the IIS Internet Database Connector.

Figure 5.16 Database connector network overview

TCP/IP Properties of the Computer Running the Database Connector

The IP address and all TCP/IP properties for the computer named ORDERDESK are dynamically assigned by the network DHCP server CANTS40ENT03 during computer startup. The WINS server, also on CANTS40ENT03, is also notified of the IP address and the computer name of ORDERDESK.

Name Resolution of the Computer Running the Database Connector

The NetBIOS computer name of the computer hosting the IIS server is ORDERDESK. All Internet Information Server clients will use this NetBIOS computer name.

Internet Explorer clients automatically query the WINS server when a request uses the name of a computer, for example, http://orderdesk. The WINS server provides the IP address currently assigned by DHCP to that computer name. The DHCP assignment and WINS registration process is dynamic. Therefore, regardless of the IP address currently assigned to ORDERDESK, Internet Explorer users can always resolve http://orderdesk to the current IP address by using the WINS server.

Networks that do not use WINS can use an alternative name resolution system, usually DNS servers. DNS servers resolve a domain name—such as orderdesk.terraflora.com—to an IP address.

Typically, you add the IP address and domain name to your local DNS server. On Terra Flora's network, the DNS server is CANTS40ENT03. For information about configuring the DNS server, see the section "Virtual Server Name Resolution" earlier in this chapter.

After the DNS server is configured, users can then access the IIS server by using either the NetBIOS computer name (if WINS is supported on the client) or the domain name (if DNS is supported on the client), as shown in Table 5.3.

Table 5.3 ORDERDESK Computer Name Used in URLs

NetBIOS name | Computer name used in URL with WINS name resolution | Domain name URL used by DNS name resolution
ORDERDESK | http://orderdesk | http://orderdesk.terraflora.com

For more information on WINS and DNS interoperability, see the Windows NT Server Networking Guide.


Creating a System Data Source

You need no special configuration in Internet Service Manager to implement database connectivity by using Internet Database Connector. The Httpodbc.dll module supplies database connectivity. Httpodbc.dll is automatically loaded when Internet Information Server starts. To install Httpodbc.dll, you select the ODBC option during Internet Information Server setup.

Prior to using the database, you must create a system Data Source Name(DSN). The Data Source Name is a logical name used by Windows NT Open Database Connectivity (ODBC) to refer to the driver and any other information required to access the data, such as the actual server name or location of the database. You specify the Data Source Name in Internet Database Connector files to tell Internet Information Server where to access the data. For more information about using the DSN in .idc files, see "Accessing the Database," later in this section.

The simplest method to create a DSN is to use the sample pages provided with Internet Information Server. To access the sample pages, first make sure your World Wide Web (WWW) service is running. Then use Internet Explorer to access your own IIS server. For example, type http://orderdesk in the location box. The Database page contains a hyperlink to create the system data source. The manual method for creating a data source follows.

To create a system data source

1. Double-click ODBC in Control Panel.

The Data Sources dialog box appears. Other data sources appear in the list if you previously installed other ODBC drivers.

2. Click System DSN. In the System Data Sources dialog box, click Add.

Important: Be sure to click System DSN. The Internet Database Connector works only with system DSNs.

3. In the Add Data Source dialog box, select an ODBC driver in the list box, then click OK.

A dialog box specific to your driver appears. To install third-party ODBC drivers, see your third-party database documentation.

4. In the dialog box specific to your driver, enter the name of the data source and any other required information, then click OK.

The System Data Sources dialog box appears again, but now it has the name of the data source displayed.

If you do not know what to enter in the dialog box specific to your driver, accept the defaults. To find out the details, click Help and find the section that describes your network.

5. To close the System Data Sources dialog box, click Close. To close the Data Sources dialog box, click Close again.

6. To complete the ODBC and DSN setup, click OK.


Placing the .idc and .htx Files

After the Data Source Name is created, you can begin to create the Internet Database Connector (.idc) files that will be used to post and query data from the database, and the .htx files that will be used to format the results returned from it.

Place the .idc and .htx files in the /Scripts directory or another Internet Information Server directory configured with the Execute property. You mark a directory with the Execute property when you add or edit the directory on the Directory property sheet.

For details on creating the .idc and .htx files, see the section "Accessing the Database" later in this chapter, or the Windows NT Server Microsoft Internet Information Server Installation and Administration Guide.


Database Connectivity Security

Security for database connectivity consists of configuring access to:

  • Internet Information Server files.
  • The database.

You use Windows NT and Internet Information Server security when accessing the .idc and .htx files. Users must have permission to access these files in the same way as any other file made available through Internet Information Server. The Terra Flora intranet uses anonymous access. Therefore, the properties of the .idc and .htx files must permit access by the IUSR_computername account or by the account specified for anonymous access.

Also, the .idc file lists a user name and (optionally) a password, which must be valid on the ODBC data source. If the .idc file does not list a user name and password, the user name and password used by Internet Information Server are presented to the ODBC data source.

If you use anonymous access or Basic authentication, the password used by Internet Information Server works on any remote data source if the user name and password are valid for logon to that data source. Windows NT challenge/response authentication works only when a computer is running both Windows NT Internet Information Server and Microsoft SQL Server. For more information, see the next section, "Using Windows NT Challenge/Response for Microsoft SQL Server Access."

Using Windows NT Challenge/Response for Microsoft SQL Server Access

If you are running Microsoft SQL Server and Internet Information Server on the same computer, you can use integrated SQL Server security to pass encrypted user names and passwords for database access. SQL Server must be configured for integrated security. Integrated SQL Server security enables you to use the encrypted user name and password given by an Internet Information Server user for access to SQL Server.

If you use integrated SQL Server security, you do not provide a user name and password in the .idc file. For more information about configuring integrated security, see your SQL Server documentation.

Before you can set up Internet Information Server and SQL Server with integrated Windows NT security, you must install both on the same computer.

To set up integrated Windows NT security, select the Windows NT Challenge/Response check box on the Service property sheet. Clients must use Internet Explorer version 2.0 or later. Specify Local Server as the System Data Source in your .idc file.

Windows NT user names must adhere to SQL Server integrated security name rules. Underscores, dollar signs, and pound signs are not allowed. The default account IUSR_computername cannot be used.


Accessing the Database

Terra Flora has an existing table in its order database. This table is used to process retail orders. The ability to access existing stores of information is the primary benefit of using Internet Information Server at Terra Flora.

Users enter data into the database by using an HTML form, as shown in the .htm file in Figure 5.17.

<HTML> <HEAD> <TITLE>Terra Flora</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <H1 Align = "Center"><CENTER><FONT SIZE=6 COLOR=#000000 FACE="Arial">Terra Flora Order Desk</FONT><FONT SIZE=6> </FONT></CENTER></H1> <FORM ACTION="/secure/Order.idc" METHOD = "POST"> <P> <TABLE BORDER=2 BORDER BGCOLOR="#FFFFFF"> <TR><TD>FirstName</TD><TD><INPUT NAME="FirstName" VALUE="" &lt;/TD> </TD><TD><BR> Address1</TD><TD><A NAME="UQHTML0"></A><INPUT NAME="Address1" VALUE="" &lt;/TD> </TD></TR> <TR><TD>LastName</TD><TD> <INPUT NAME="LastName" VALUE="" &lt;/TD> </TD><TD><BR> Address2</TD><TD><INPUT NAME="Address2" VALUE="" &lt;/TD> </TD></TR> <TR><TD>ProductId1</TD><TD><INPUT NAME="ProductId1" VALUE="" &lt;/TD> </TD><TD> <BR> City</TD><TD><INPUT NAME="City" VALUE="" &lt;/TD> </TD></TR> <TR><TD>ProductId2</TD><TD><INPUT NAME="ProductId2" VALUE="" &lt;/TD> </TD><TD> <BR> State</TD><TD><INPUT NAME="State" VALUE="" &lt;/TD> </TD></TR> <TR><TD>ProductId3</TD><TD><INPUT NAME="ProductId3" VALUE="" &lt;/TD> </TD><TD> <BR> Country</TD><TD><INPUT NAME="Country" VALUE="" &lt;/TD> </TD></TR> <TR><TD>Comment</TD><TD><INPUT NAME="Comment" VALUE="" &lt;/TD> </TD><TD>PhoneNumber</TD><TD> <INPUT NAME="PhoneNumber" VALUE="" &lt;/TD> </TD></TR> <TR><TD>DeliveryDate</TD><TD><INPUT NAME="DeliveryDate" VALUE="" &lt;/TD> </TD><TD>Email</TD><TD> <INPUT NAME="Email" VALUE="" &lt;/TD> </TD></TR> <TR><TD>CreditCardNumber</TD><TD><INPUT NAME="CreditCardNumber" VALUE="" &lt;/TD> </TD><TD> <INPUT TYPE="SUBMIT" VALUE="Place Order" ALIGN="MIDDLE"></P> </TD><TD><INPUT TYPE="RESET" NAME="reset" VALUE="Clear" ALIGN="MIDDLE"> </TD></TR> </TABLE> <P> </FORM> <P> <HR=2> </BODY> </HTML>

Figure 5.17 Sample .htm file for Terra Flora order desk

Figure 5.18 shows the results of this .htm file in Internet Explorer.

Figure 5.18 Terra Flora order desk file displayed by Internet Explorer

When a user clicks the Place Order button, the data is processed by using the .idc file shown in Figure 5.19.

Datasource: OrderDB Template: Order.htx SQLStatement: +INSERT INTO "OrderDB" ("FirstName", "LastName", "Email", "PhoneNumber", "CreditCardNumber",
+"Address1", "Address2", "City", "State", "Country", "ProductId1", "ProductId2",
+"ProductId3", "Comment", "DeliveryDate") +VALUES ('%FirstName%', '%LastName%', '%Email%', '%PhoneNumber%', '%CreditCardNumber%',
+'%Address1%', '%Address2%', '%City%', '%State%', '%Country%', '%ProductId1%', '%ProductId2%',
+'%ProductId3%', '%Comment%', '%DeliveryDate%'); #IDC-Insert FrontHTM-default.htm ReportHTX-Order.htx

Figure 5.19 Sample .idc file for Terra Flora order desk

The .idc file then posts the information to the database and results are formatted by using the .htx file specified in the .idc file, Order.idc, as shown in Figure 5.20.

<HTML> <HEAD> <TITLE>Submitted Order</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <P> <B>Verify this posted information with the customer.<BR> </B> <P> <TABLE BORDER=2 BORDER BGCOLOR="#FFFFFF"> <TR><TD ALIGN="RIGHT"><B>FirstName</B></TD><TD><%IDC.FIRSTNAME%> </TD><TD ALIGN="RIGHT"><B>Address1</B></TD><TD><%IDC.ADDRESS1%> </TD></TR> <TR><TD ALIGN="RIGHT"><B>LastName</B></TD><TD><%IDC.LASTNAME%> </TD><TD ALIGN="RIGHT"><B>Address2</B></TD><TD><%IDC.ADDRESS2%> </TD></TR> <TR><TD ALIGN="RIGHT"><B>ProductId1</B></TD><TD><%IDC.PRODUCTID1%> </TD><TD ALIGN="RIGHT"><B>City</B></TD><TD><%IDC.CITY%></TD></TR> <TR><TD ALIGN="RIGHT"><B>ProductId2</B></TD><TD><%IDC.PRODUCTID2%> </TD><TD ALIGN="RIGHT"><B>State</B></TD><TD><%IDC.STATE%></TD> </TR> <TR><TD ALIGN="RIGHT"><B>ProductId3</B></TD><TD><%IDC.PRODUCTID3%> </TD><TD ALIGN="RIGHT"><B>Country</B></TD><TD><%IDC.COUNTRY%> </TD></TR> <TR><TD ALIGN="RIGHT"><B>Comment</B></TD><TD><%IDC.COMMENT%></TD><TD
ALIGN="RIGHT"><B>PhoneNumber</B> </TD><TD><%IDC.PHONENUMBER%></TD></TR> <TR><TD ALIGN="RIGHT"><B>DeliveryDate</B></TD><TD><%IDC.DELIVERYDATE%> </TD><TD ALIGN="RIGHT"><B>Email</B></TD><TD><%IDC.EMAIL%></TD> </TR> <TR><TD ALIGN="RIGHT"><B>CreditCardNumber</B></TD><TD><%IDC.CREDITCARDNUMBER%> </TD><TD></TD><TD></TD></TR> </TABLE> <P> <P> <A HREF="/default.htm">Return To Data Entry Page</A> <P> </BODY> </HTML>

Figure 5.20 Sample .htx file for Terra Flora order desk

The process is complete when the database returns confirmation through the .htx file, as shown in Figure 5.21.

Figure 5.21 Terra Flora order desk confirmation .htx file in Internet Explorer


Internet Considerations for Database Connectivity

When you use database connectivity over the Internet, you must use the Secure Sockets Layer protocol to confidentially obtain credit card numbers, addresses, or any other information that should not be divulged to others.

The SSL protocol provides communication privacy over networks by using a combination of public key cryptography and bulk data encryption for data privacy. By using this protocol, clients and servers can communicate in a way that prevents eavesdropping, tampering, or message forgery.

For optimum efficiency, store the form requesting confidential information in a directory not enabled for SSL, but set the confidential information to return to an SSL-enabled directory. This directory is specified in the button used to submit the form, as illustrated in Figure 5.22.

Figure 5.22 SSL process and directory configuration

Step 1 shows the order form sent to the client from a directory that is not enabled for SSL. Step 2 demonstrates that the completed form, with address and credit card information, is sent back to an SSL-enabled directory by clicking Submit order, which runs the request https://orderdesk/secure/order.idc?parameters. Step 3 shows that the response is returned to the client through Order.htx.

For more information about SSL, see Chapter 3, "Server Security on the Internet."


Internet Information Server FTP and Gopher Services

In this scenario, the Terra Flora Human Resources department is setting up methods to ensure that all employees have access to Human Resources information currently provided through the WWW service. Some employees still use computers that run the MS-DOS or UNIX operating system; they cannot use Internet Explorer. And in addition to reading files, some Human Resources employees need to add and delete files by using the File Transfer Protocol (FTP) service.

Terra Flora adds the FTP and Gopher services to the same computer running the WWW service that was installed in the scenario described in "Internet Information Server as a Single Intranet Server" in Chapter 4. Human Resources employees will use the FTP service to maintain the files. All other employees can use the FTP or Gopher service to view the files.


Internet Information Server FTP and Gopher Services Hardware Configuration

The existing file and print server is two years old. The low system demands of Internet Information Server, including FTP and Gopher, will not significantly impact file and print server performance. Therefore, it is practical to run all three Internet Information Server services on this older hardware:

  • Intel 486 processor with clock speed of 66 MHz
  • 32 MB of RAM
  • 1 GB disk space


Internet Information Server FTP and Gopher Services Network Configuration

The computer used for the intranet server is the same computer running the WWW service that was installed in the scenario described in "Internet Information Server as a Single Intranet Server" in Chapter 4. For a complete description of the network configuration for the FTP and Gopher services, see that section of Chapter 4.

The computer used is similar to the computer CANTS40DPT01 in the Terra Flora network diagram. See Figure 5.23 for a diagram of the network configuration.

Figure 5.23 FTP and Gopher services network overview

Name Resolution for FTP and Gopher Services

After name resolution is configured as described in Chapter 4, users can then access the Internet Information Server FTP and Gopher services by using either the NetBIOS name if WINS is supported on the client) or the domain name (if DNS is supported on the client), as shown in Table 5.4.

Table 5.4 Computer Names in URLs for FTP and Gopher Services

NetBIOS name | Computer name used in URL with WINS name resolution | Domain name URL used by DNS name resolution
HR | ftp://hr gopher://hr | ftp://hr.terraflora.com gopher://hr.terraflora.com


Control Files and Related Configuration

The FTP and Gopher services are configured to have the same home directory as the WWW service (wwwroot). Therefore, the same set of information is available through all services. Although no additional configuration is necessary, some additional configuration enhancements are described in the following two sections. They describe files and settings used to enhance the FTP and Gopher services that are not part of the default installation of Internet Information Server.

FTP Service Configuration

The FTP service allows you to use directory annotations, that is, comments about each directory. Because virtual directories do not appear in FTP listings, you use directory annotations to display additional virtual directories that can be traversed by the employees.

To annotate files, first use Registry Editor (run Regedt32.exe or Regedit.exe) to enable annotated directories by adding the AnnotateDirectories value to the HKEY_LOCAL_MACHINE/System key, as shown in Figure 5.24.

Figure 5.24 Adding the FTP service's AnnotateDirectories value to the Registry

AnnotateDirectories is added to:

HKEY_LOCAL_MACHINE
\System
\CurrentControlSet
\Services
\MSFTPSVC
\Parameters

Entry syntax is:

AnnotateDirectories REG_DWORD 0x0 | 0x1

The default value for AnnotateDirectories is 0x0 (false—that is, directory annotation is off).

This Registry value defines the default behavior of directory annotation for newly connected users. When this value is 0x1 (true), directory annotation is enabled. This Registry entry does not appear by default, so you must add this entry to the Registry if you want to change its default value.

The directory annotations are stored in each directory in a text file named ~ftpsvc~.ckm. This is usually a hidden file, so directory listings do not display this file. Because some browsers display only the first line, you should keep the annonotation text to one line. For example,

See ftp://eunts40dpt05/seville for Seville's HR records.

Gopher Service Configuration

All information about a Gopher item that is sent to a client comes from tag files. This information includes the name of a file displayed for the client. Typical tag files contain:

  • A display filename.
  • A host name (that is, where the item is located).
  • A port number.

The Gdsset program is a simple command-line tool that is used to create and set tags. In the following example, you see how to use it to add a link to Terra Flora's Gopher server in Seville.

First, create a tag file to make a link to the home directory on a Gopher server at the Seville site. Add an empty text file called link1 to the Gopher home directory. Issue the following command at the command prompt:

gdsset -l -g1 -f "Link to Seville HR Gopher Server" -s "" -h eunts40div05.terraflora.com link1

For more examples of using Gdsset, see the Internet Information Server Installation and Administration Guide.

Tag files are stored as hidden .gtg or .lnk files on File Allocation Table (FAT) partitions. On Window NT File System (NTFS) partitions, they are stored in a data fork of the tag file. When you move data files, you must remember to manually move the corresponding tag files if they exist on FAT partitions. When you move data files on NTFS partitions, use Windows NT Explorer and not the command-prompt copy command because copy does not copy the data forks.

If disk space is critical, do not forget to include the hidden tag files when you calculate the space the files will require. The size of the file depends on the size of the friendly name, host name, selector, and other information.

If you use Gopher+ clients, you can add more information to each tag file, such as the server administrator's name and e-mail address, and the file's date of creation and date of last modification.

Note

The Internet Information Server Gopher service supports some Gopher+ additions: Info, Admin, and URL attribute blocks. But it does not support the Abstract or Ask Form attributes. For more information about Internet Information Server and Gopher, see the Internet Information Server Installation and Administration Guide.


Using Security with the FTP and Gopher Services

FTP and Gopher use anonymous access. In addition, FTP uses Basic authentication in conjunction with Windows NT groups for restricted administration of the files.

Anonymous FTP Access

MS-DOS clients and some UNIX clients do not have or cannot use an HTTP or Gopher browser such as Internet Explorer. These clients can use any FTP client to browse the files on HR. To accomplish this, the IUSR_CANTS40DIV01 user account was granted read-only access to the files.

Anonymous Gopher Access

The Human Resources department must provide information to the entire company, such as benefits summaries and company policies. All Gopher access is anonymous through the IUSR_HR user account. This local user account was added to the California domain database on CANTS40ENT03 and was granted the Log On Locally user right.

If Internet Information Server were installed on a primary domain controller (PDC) or a backup domain controller (BDC), the IUSR_computername account would automatically be added to the domain database it supports and the steps above would be unnecessary.

For more information about server roles and accounts used with Internet Information Server, see Chapter 3, "Server Security on the Internet."

FTP Site Administrative Access

You use Windows NT groups to provide selective access for remote division employees who must maintain (create and delete) files on the HR server.

The Gopher and FTP site primarily uses a single directory structure for simplicity, although some directories reside on network drives.

Only clear-text authentication is supported with the FTP server. Because it has been determined that there is low risk of an employee sniffing Terra Flora's private intranet for user names and passwords, FTP administrators can log on to the FTP server by using their network user name and password. After they are authenticated, the FTP administrators can use FTP commands to create, move, and delete files or directories.

Using groups for selective access in FTP is similar to the process described earlier in this chapter in the section, "Using Groups for Selective Access." See that section for more discussion about using groups with Internet Information Server.


Content Provided

The Human Resources server provides information to the entire company, such as the employee handbook, training documents, personnel review documents, and company forms. Since directory names and filenames help provide the structure, the HR department kept this in mind when creating filenames, directory names, and directory structure, as shown in Figure 5.25.

Figure 5.25 FTP and Gopher directory structure and filenames

In addition, Gopher tag files are used with the Gopher service to provide additional information about files and directories and to provide links to other computers. For more information about using Gopher tag files and an example of the tag files used on the Terra Flora Gopher server, see the section in this chapter, "Gopher Service Configuration."


FTP and Gopher on the Internet

The FTP logon is in clear text. Because of this, having an FTP site on the Internet that uses valid network user names and passwords could compromise your intranet's security. FTP sites on the Internet usually allow anonymous access only.

Gopher logon is anonymous only. Secure Gopher access is not possible.

Some client browsers do not display FTP directory listings that use the FTP service's default MS-DOS style. You can change the default listing style by using options on the Service property sheet for the FTP service.


Using and Upgrading the Windows NT 3.x FTP Server

If the FTP Server service from Windows NT version 3.51 or earlier is installed and running on your system, it will continue to run without modification under Windows NT 4.0.

However, if you install the Internet Information Server FTP service, the FTP Server service from Windows NT version 3.51 or earlier will be disabled. Both FTP services cannot run simultaneously.

You can upgrade your Windows NT 3.51 or earlier FTP service to Internet Information Server version 2.0. You must change the Internet Information Server FTP service home directory to the previous location. The FTP service continues to operate in the same way as the Windows NT 3.51 or earlier version of the FTP service.

Note

The Windows NT 3.51 or earlier FTP service permitted users to traverse the directory structure above the specified FTP root. Internet Information Server removes this capability.


Chapter 6 - Internet Connectivity Scenarios Using the Remote Access Service

This chapter gives an overview of Internet support that uses Dial-Up Networking and the Remote Access Service. It then details how Windows NT Server 4.0 can be deployed as an Internet gateway server.

For information about the Point-to-Point Tunneling Protocol (PPTP), see the Windows NT Server Networking Supplement and the Microsoft Windows NT Server Resource Kit: Windows NT Server Networking Guide.


Connecting to the Internet with Windows NT

Traditionally, connecting to the Internet has been a difficult process that is daunting for a beginner. Early tools, such as FTP (File Transfer Protocol) and Telnet, featured character-based commands suited for those who knew how to connect and maneuver through the intertwined network with 32-bit IP addresses. Today's tools, such as Internet Explorer, provide front-end viewers that enable users to scan and search for information without much knowledge of how information is stored and without having to log on to the source computer.

Windows NT provides and works with tools that make it easier to connect to the Internet.

  • Dial-Up Networking is the software that enables clients to connect to remote computers, such as an Internet service provider.
  • Remote Access Service (RAS) is the software that enables a computer running Windows NT to accept calls from remote computers. The remote computer can use Windows Dial-Up Networking or any other Point-to-Point Protocol (PPP) dial-up client.

Both Dial-Up Networking and RAS are included in Windows NT Workstation and Windows NT Server.

This section presents four scenarios for connecting to the Internet by using Windows NT Dial-Up Networking and Remote Access Service.

For more information about Remote Access Service and Dial-Up Networking, see the Windows NT Server Networking Supplement and Windows NT Server Resource Kit Networking Guide.


Dial-Up Client Connections

By using Windows NT and Dial-Up Networking, a user can make an Internet Protocol (IP) connection to a dial-up Internet host by using the Point-to-Point Protocol (PPP). Speeds from 2400 bits per second (bps) up to 128,000 bps are supported. After the Dial-Up Networking connection is established, the user can choose from a variety of tools—from the traditional and nongraphical to those that fully exploit the Windows interface.

For information about | See
Connecting to the Internet by using Dial-Up Networking | Microsoft Windows NT Workstation Resource Kit: Windows NT Workstation Resource Guide, Chapter 35, "Using Windows NT Workstation on the Internet"
Installing and using Dial-Up Networking | Windows NT Workstation Start Here


Simple Internet Router Using PPP

On small intranets (an intranet with less than 20 computers), a computer running Windows NT Server can use Dial-Up Networking, simple TCP/IP (Transmission Control Protocol/Internet Protocol) routing, and a PPP connection to an Internet service provider to create an Internet gateway for the computers on the small intranet. This configuration enables you to connect intranet clients to the Internet, as shown in Figure 6.1.

Figure 6.1 Windows NT Server as a static Internet router with PPP

In this scenario, the computer running Windows NT Server has a Dial-Up Networking connection to an Internet service provider (ISP). Static TCP/IP routing is enabled, and a static routing table is created for the computers on the private network. Routing information must also be provided to the Internet service provider because simple TCP/IP routing does not use the routing information protocol (RIP) to communicate with the ISP's router. The routing information enables the routers to route traffic to and from the Internet to computers on the private network.

This configuration can also support a very light-duty server running Internet Information Server.

For this scenario, you need to install and configure the following hardware or services:

  • A computer running static TCP/IP routing with a static routing table
  • TCP/IP networking protocol on all computers that will use the Internet
  • Dial-Up Networking on the server that will dial in to the Internet service provider
  • A modem
  • Network interface cards on all computers
  • Internet browsers, such as Internet Explorer, on all computers that will access the Internet
  • Internetwide domain name resolution, as described in the section, "Establishing an Internet Connection," in Chapter 2, "Connecting Windows NT Server to the Internet."

For more information about simple TCP/IP routing and Dial-Up Networking, see the Windows NT Server Networking Supplement and the Windows NT Server Resource Kit Networking Guide.


Internet Service Provider

In this scenario, an Internet service provider uses Windows NT Server to set up an information service network. The network provides an Internet connection and other network services, including a mail server, fax server, database hosting, software distribution, and other custom applications.

Figure 6.2 Internet service provider with Internet access and network services

The computer running Windows NT Server is on the Internet service provider's network, which also has a leased line to the Internet. The Remote Access Service accepts calls from customers who want Internet access or network services. RAS routes traffic to and from remote customers to servers on the private network and to and from the Internet.

For this scenario, you need to install and configure the following hardware or services:

  • A computer running the Remote Access Service
  • TCP/IP networking protocol on all computers that will use the Internet
  • A multiport adapter, which allows multiple remote clients to dial in to the computer running RAS
  • Network interface cards on all servers
  • Internet browsers, such as Internet Explorer, on all remote clients that will access the Internet
  • Dial-Up Networking on remote clients that will dial in to the RAS server
  • Internetwide domain name resolution, as described in the section, "Establishing an Internet Connection," in Chapter 2, "Connecting Windows NT Server to the Internet."

For more information about multiprotocol routing and the Remote Access Service, see the Windows NT Server Networking Supplement and Windows NT Server Resource Kit Networking Guide.


Internet Gateway

An organization with a network can establish a RAS server with direct connections (through a router) to the Internet. To provide for security, the server can be isolated from the rest of the corporate network. (For more information about security, see Chapter 3, "Server Security on the Internet.")

Users can dial one number that gives them access to the Internet, and dial another number that gives them access to the corporate intranet. See the following section for more information about this scenario.

Figure 6.3 Microsoft RAS server as an Internet gateway server


Installing an Internet Gateway Server

Before you learn how to install Remote Access Service as an Internet gateway server, it is useful to understand a few TCP/IP networking terms, and how they relate to RAS. (For more information about TCP/IP and Remote Access Service, see the Windows NT Server Networking Supplement, the Windows NT Server Resource Kit Networking Guide, or online Help.)


IP Address

An IP address is used to identify a node (such as a workstation, a server, or a printer) on any network (such as your intranet or the Internet) and to specify routing information from one network or subnet to another network or subnet. Each node on a network or subnet must be assigned a unique IP address.

For Dial-Up Networking clients, the RAS server can automatically assign IP addresses to remote workstations when they connect. The IP address is obtained from a static pool that has been reserved for use by the RAS server, or through dynamic allocation from a Dynamic Host Configuration Protocol (DHCP) server. (For more information about DHCP, see the next section.)

Where needed, the RAS server can be configured to allow remote clients to specify their own IP addresses. This is useful for remote workstations that each need to be guaranteed a specific IP address when they are connected to the network.

Subnet masks are used in conjunction with the IP address to create subnets within an IP address space. Subnet masks are usually provided by the TCP/IP network administrator, such as an Internet service provider. If you need more information about subnet masks, see the Windows NT Server Networking Supplement.


Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) is an industry-standard protocol for automatic assignment of IP configuration to workstations. DHCP uses a client/server model for address allocation. The network administrator establishes one or more DHCP servers that maintain the network's TCP/IP configuration, including client configuration. Intranet workstations request leases on TCP/IP configuration from the DHCP server, thus eliminating the need for administrators to manually configure each workstation. For more information about configuring DHCP servers, see the Windows NT Server Networking Supplement and Windows NT Server Resource Kit Networking Guide.

A RAS server can act as a DHCP client, thereby obtaining TCP/IP configuration information on behalf of remote workstations. The RAS server leases a pool of IP configuration information from the DHCP server or servers. When remote workstations dial in to the network, the RAS server allocates IP configuration information to each workstation out of this pool.


Domain Name System

The Domain Name System (DNS) resolves friendly computer names to IP addresses. DNS is sometimes referred to as the BIND service in BSD UNIX.

To specify the DNS server that a workstation uses, you double-click Network in Control Panel to reach the configuration options for TCP/IP properties. A workstation's TCP/IP configuration typically includes one or two DNS servers that are on the local network. If a DNS server is unable to identify the IP address of a name requested by the workstation, it sends back information about other DNS servers that might be able to resolve the address. The workstation then queries the new set of DNS servers.

The Domain Name System makes it easy for users to access information from servers on the Internet. For example, it is easier to remember the name www.microsoft.com than to remember the IP address for that server.

To use the Domain Name System, workstations must be configured to recognize at least one DNS server's IP address. DNS server addresses can be assigned to a computer in one of two ways:

  • Static TCP/IP configuration on the workstation
  • Dynamic assignment by a DHCP server

In the Remote Access Service, DNS server addresses are assigned to remote workstations in one of three ways:

  • Static assignment on the workstation
  • Static assignment on the RAS server, which in turn assigns that address to remote workstations
  • Dynamic assignment to the RAS server by using DHCP; the RAS server in turn assigns that DNS server's address to remote workstations

The RAS server always assigns the DNS address to workstations dialing in that run Windows NT Workstation or Windows 95. The address is either statically assigned by the RAS server or dynamically assigned for the RAS server by DHCP. For remote access solutions from vendors other than Microsoft, remote users might need to statically assign their DNS server.

For more information about setting up a RAS server to use DNS, see the Windows NT Server Networking Supplement.


Default Gateway

The default gateway is the intermediate network node on the network or subnet that has addresses for the network IDs of other subnets in the network. When a workstation sends data, the default gateway can forward the packets to other gateways until the data is eventually delivered to its final destination. Gateways are usually computers that are called routers because they are dedicated to directing network traffic.

TCP/IP workstations can each be configured for one default gateway only. This poses an interesting situation for remote workstations that are also connected to an intranet. For example, a computer at a branch office dials in to the corporate network while it is still connected to the branch office network. This type of a workstation is referred to as a multihomed workstation.

When a multihomed computer running Windows NT Workstation or Windows NT Server attempts to access a particular IP address, the destination server is located by using the following process:

  • If the destination IP address indicates that it is on the same IP subnet as the workstation's network interface card, then data is sent through the network interface card.
  • If the destination IP address indicates that it is not on the same subnet as the workstation's network interface card, then data is sent to the default gateway assigned by the RAS server. The default gateway then locates the destination route on behalf of the remote workstation.

If a default gateway IP address was previously configured for the network interface card, it is ignored by default. If required, the remote workstation can be configured so that the default gateway on the network interface card is used instead of the default gateway on the remote link.


Configuration Overview

Complete the following tasks to make a computer running Windows NT Server an Internet gateway.

To configure an Internet gateway

1. Select an Internet service provider.

For a complete list of Internet service providers, refer to the book, Connecting to the Internet by Susan Estrada (published by O'Reilly and Associates). Or refer to your phone book or, if possible, the Internet.

2. Assign a dedicated pool of IP addresses for remote clients.

– or–

Use DHCP servers on your network.

For details, see the Windows NT Server Networking Supplement and Windows NT Server Resource Kit Networking Guide.

3. Configure a DNS server locally on your intranet.

– or–

Contact your Internet service provider for the IP address of a DNS computer on the ISP's network.

4. Install any optional communication hardware you will need to provide Internet service.

For example, your server can be configured with a multiport adapter, Integrated Services Digital Network (ISDN) interface cards, and X.25 interface cards.

5. Install Windows NT Server 4.0 on your computer.

For details, see the Windows NT Server Start Here manual.


Internet Gateway Configuration

The scenario described in this section was an actual pilot test of Windows NT as an Internet gateway server at Microsoft Corporation. For security reasons, the Internet gateway server was installed on an isolated network, which was in turn connected to the Internet by third-party routers. The RAS server and the third-party routers were not connected to the corporate network.

Figure 6.4 Windows NT as an Internet gateway server

In this scenario, the computer running Windows NT Server has a leased line to an Internet service provider through third-party routers. The Remote Access Service is installed. This enables traffic from the Internet to be routed to and from computers on the private network. The Remote Access Service enables Windows Dial-Up Networking clients or other dial-up clients to connect to the RAS server by using ISDN or a POTS line (plain old telephone service, also known as PSTN or public switched telephone network), giving them Internet access.

The Internet gateway server for the pilot test had the following configuration:

  • A MIPS Rx4000 RISC-based computer (with 32 MB of RAM) running the Remote Access Service
  • TCP/IP networking protocol on all computers that will use the Internet
  • Network interface cards on all computers
  • Third-party (Cisco) routers
  • A Digi International PC/2e serial adapter, which enables multiple remote clients to dial in on telephone lines to the computer running the Remote Access Service
  • A Digi International PCIMAC4 ISDN adapter, which enables multiple remote clients to dial in on ISDN lines to the computer running the Remote Access Service
  • Dial-Up Networking on remote clients that will dial in to the RAS server
  • Modems or ISDN cards on remote clients that will dial in to the RAS server
  • ISDN lines and standard analog telephone lines
  • A DNS server
  • Internet browsers, such as Internet Explorer, on all computers that will access the Internet

For more information about the Remote Access Service, see the Windows NT Server Networking Supplement and Windows NT Server Resource Kit Networking Guide.


Chapter 7 - Internet Tools

The Microsoft Windows NT Server Resource Kit version 4.0 compact disc includes several tools for Internet users, including the following:

  • Mail Server, a mail server for Windows NT Server that uses Simple Mail Transfer Protocol (SMTP) and Post Office Protocol version 3 (POP3).
  • Telnet Server, a tool that enables remote clients to use Telnet to log on to the Windows NT Server as if the remote client is using a local terminal.
  • Microsoft dbWeb, a gateway between Microsoft Open Database Connectivity (ODBC) data sources and the Microsoft Internet Information Server (IIS).

This chapter provides information about these tools and how to use them. For specific information about installation or command syntax, see Resource Kit Tools Help. At the end of this chapter is a list of other Microsoft products and development tools for Internet users.


Mail Server (MailSrv)

Mail Server (MailSrv) is a tool you use to configure a computer running Windows NT Server to provide electronic mail service for intranet or Internet users. With MailSrv installed, you can send and receive mail by using a TCP/IP-based intranet or the Internet. TCP/IP (Transmission Control Protocol/Internet Protocol is the networking protocol supported by most computers on the Internet.)

MailSrv is based on the TCP/IP protocols described in Table 7.1.

Table 7.1 TCP/IP Mail Protocols in MailSrv

Protocol | RFC |  | Description
Simple Mail Transfer Protocol (SMTP) | RFC 821 and RFC 822 |  | TCP/IP-based networks use SMTP to transfer mail reliably and efficiently. SMTP transports a mail message across TCP/IP-based networks to a destination SMTP server.
Post Office Protocol version 2 and version 3 (POP2, POP3) | RFC 1460 |  | POP defines the standard for user mailboxes and the protocol for downloading mail messages to a user's local computer. This protocol is generally referred to with its version number (POP3, POP2) to avoid confusion with the telephony POP (Point of Presence) terminology.
MIME and UUENCODE |  | RFC 1521 and RFC 1154 |  | MailSrv does not contain support for Multipurpose Internet Mail Extension (MIME) and UNIX-to-UNIX Encode (UUENCODE). However, MailSrv can send and receive messages containing MIME and UUENCODE attachments.

MailSrv is based on a combination of the SMTP and POP3 protocols. It provides only the SMTP send-and-receive services and the POP3 user post office services that are required by the RFC specifications.

MailSrv is completely separate from the electronic messaging and groupware services of Microsoft Exchange and Microsoft Mail. Because MailSrv provides only the basic required SMTP and POP3 services, it can be used in small TCP/IP-based networks that cannot provide the resources required for advanced messaging and groupware services. A computer that runs the MailSrv tool under Windows NT Server can also be used with Microsoft Exchange and Microsoft Mail systems as a dedicated SMTP/POP3 server.


Using MailSrv with the Windows NT Inbox

New to Windows NT Server version 4.0 and Windows NT Workstation version 4.0 is a universal inbox client (also referred to as Windows Messaging client) that can send and receive electronic mail. The inbox client organizes, accesses, and stores all types of information. For example, you can open the Inbox on the Windows NT desktop to read, compose, forward, and delete messages, or to create automatic replies and other notification policies based on individual preferences.

The Windows NT Inbox is optimized for use with Microsoft Exchange Server and Microsoft Exchange clients. However, because it is a universal inbox client, you can use it with different mail systems and mail client software, including MailSrv.

Mail client software — for example, the Windows Messaging client — must be installed on each computer supported by the computer running the MailSrv tool under Windows NT Server. After the mail client software is installed, you must enable Internet mail service. For example, to enable Internet mail service by using the Windows Messaging client, follow the procedure in the Help topic "Installing an Information Service."


Using MailSrv with Microsoft Exchange

Microsoft Exchange Server integrates mail, group scheduling, electronic forms, and groupware applications on a single platform. It can also extend those capabilities to encompass Internet and X.400 systems, to provide access to the most widely used messaging standards.

Microsoft Exchange Server version 4.0 supports messaging between intranet and Internet locations and between different electronic mail systems, including SMTP/POP3 services such as MailSrv. MailSrv running with Windows NT Server can function as a dedicated SMTP host for Microsoft Exchange Server by using the Microsoft Exchange–based Internet Mail Connector (IMC). The IMC service converts messages from Microsoft Exchange format to the format required by the SMTP messaging system and vice versa.

Microsoft Exchange Server is not included with the Windows NT product. For information about installing and configuring Microsoft Exchange Server and client software with the Internet Mail Connector option, see the Microsoft Exchange Server product documentation.


Using MailSrv with Microsoft Mail

Microsoft Mail for PC Networks, version 3.5 or later, is an electronic messaging system for large and small organizations. Microsoft Mail supports networks that include computers using Windows NT Server, Windows NT Workstation, Windows for Workgroups, Windows 95, 16-bit Windows, MS-DOS, Macintosh, and OS/2® operating systems.

Microsoft Mail for PC Networks, version 3.5, provides an SMTP gateway that enables Microsoft Mail users to exchange Internet mail with SMTP host computers — for example, MailSrv running with Windows NT Server. The Microsoft Mail Gateway to SMTP can also be used to transparently link multiple Microsoft Mail networks by using MailSrv running with Windows NT Server as an SMTP backbone.

For information about installing and configuring Microsoft Mail for PC Networks, see the Microsoft Mail for PC Networks product documentation.


Security Considerations When Using SMTP/POP3

Windows NT provides built-in security that controls:

  • User account access based on user names and passwords.
  • File and directory access, permissions, and operations.
  • User operations based on user and group policies.

Windows NT security provides a high level of security both for stand-alone computers and for Windows NT–based networks. However, the MailSrv tool uses only the clear-text password authentication of POP3. Passwords are sent over the network in readable (clear) format and are not encrypted. Administrators must plan for security on networks that use the MailSrv tool. They must consider the potential for unauthorized users acquiring passwords and subsequent malicious tampering with Internet communications.

You can use the classification of Internet communications in Table 7.2 to identify your enterprise security requirements when using SMTP/POP3. For additional information on security, see Chapter 3, "Server Security on the Internet."

Table 7.2 Enterprise Security Guidelines

Type of communication | Description
General communications | Include private mail or limited access to public-domain data published on a Web server. Communication authentication and integrity are based on password systems.
Business communications | Include intra-organization business mail, correspondence, data, and public correspondence (such as product advertising) and information (such as customer support service). Authentication and message integrity, as well as privacy, can be critically important and require more sophisticated control than for general communications.
Financial transactions | Are not suitable for mail communication because of the need for high security control. Additionally, financial data is often partitioned. Each party to the communication needs some of the data, but not all of the parties need (or should have) all the data.


Installing and Running MailSrv

To install MailSrv, you need the following components installed on your computer:

  • Windows NT Server version 4.0
  • TCP/IP

Before you install MailSrv ,configure TCP/IP to use the Domain Name System (DNS). To do this, on the WINS Address tab of the Microsoft TCP/IP Properties dialog box, select the Enable DNS for Windows Resolution check box. You must do this on the computer running MailSrv under Windows NT Server and on any other Windows NT– based computer in the network that uses MailSrv services. SMTP uses DNS for name–to–IP address mapping.

Note

The MailSrv server must be added to the DNS name server for the domain. If the DNS name server is a computer running DNS Server under Windows NT Server, you can do this by using DNS Manager to create the following DNS resource records:

  • A record. The A (address) resource record maps a host (computer or other network device) name to an IP address in a DNS zone.
  • MX record. The MX (mail exchanger) resource record specifies a mail exchange server for the specified DNS domain name.

MailSrv can be installed only on a drive formatted by using the Windows NT File System (NTFS) because MailSrv checks the local user account database when storing messages in a local user mail spool directory. Installation fails if you attempt to use a network or non-NTFS drive for the mail spool directories.

The installation program installs and automatically starts the services described in Table 7.3.

Table 7.3 Services Installed with MailSrv

Service | Description
SMTP Server | Receives and sends SMTP mail.
POP3 Server | Provides the POP3/POP2 mailboxes and processes user requests to retrieve mail from their mailboxes.
Local Mail Delivery Agent | Delivers (downloads) mail to the user's local computer.
Eudora Password Change Server | Processes Eudora user requests to change their Eudora passwords. (Eudora is a popular mailbox client program.) The Eudora Password Change Server does not start automatically. To manually start the service, click Start, point to Settings, and click Control Panel. In Control Panel, double-click the Services icon. You can also configure this service to start automatically by using the Services icon.
Mail Server Admin | Will be a graphical manager tool. The tool is installed but is not implemented as of this writing. For now, you must manually configure MailSrv by using the Registry.

See Resource Kit Tools Help for detailed information about installing and configuring MailSrv.


Administering Microsoft MailSrv

The administrative tasks of running MailSrv on Windows NT Server include:

  • Creating user mail accounts.
  • Deleting user mail accounts.
  • Deleting user spool directories.
  • Adding address rules (transforms).
  • Using the Event Viewer to monitor MailSrv.

The following sections discuss each of these tasks.

Creating User Mail Accounts

MailSrv creates a mail account for each user account on the computer. You do not need to create separate mail accounts for users. The mail accounts are created by using the Windows NT Server local user account database on the computer running MailSrv. Because the local user account database is used, domain (or alias) mail accounts are not supported by MailSrv.

For information about creating local user accounts, see the Windows NT Server product documentation and the Windows NT Server Resource Guide.

No additional administrator action is required to create a user mailbox. The user mailbox is established the first time a user opens the Inbox on the desktop and then opens Mailbox - user name.

Important

The local computer name must be the same as the DNS host name, which is the default configuration of TCP/IP. If you need to return to the default configuration, display the DNS host name and change it by using the options on the DNS tab in the Microsoft TCP/IP Properties dialog box. For more information, see Help.

Deleting User Mail Accounts

A user's mail account is deleted when you delete the local user account by using either User Manager from Windows NT Workstation or Server User Manager from Windows NT Server. You do not need to perform any additional operation. Note that you must have administrator permissions to delete a local user account.

Deleting User Spool Directories

When a user's local account (and concurrently the user's mail account) is deleted, the user's mail directory remains. You can delete the spooled user directory on the local computer if you have administrator permissions on that computer.

Adding Address Rules (Transforms)

Transforms are rules that the administrator creates to add, remove, and modify domain names appended to inbound and outbound messages. Transforms also enable the administrator to mask host names and domain names.

When an administrator modifies the names and addresses that are attached to inbound and outbound mail messages, mail addressing becomes easier for users and secures the use of domain names. The transform is transparent to the user, who does not need to worry about the information that is appended to, or deleted from, the mail address.

For example, if MailSrv is used for a small intranet, the administrator can create a transform to automatically add the domain name to the address. Using this transform, a message addressed only as "Lydia" in the terraflora.com domain is actually transmitted with the address of Lydia@terraflora.com.

For detailed information about creating transforms, see Resource Kit Tools Help.

Using Event Viewer to Monitor MailSrv

MailSrv is designed to post any MailSrv event messages to the Windows NT Server Event Viewer. Service stops, starts, and other events are written to the system and application logs. To manually start and stop MailSrv services, double-click Services in Control Panel.

Note

To ask questions about the MailSrv tool, contact rkinput@microsoft.com.


Microsoft Telnet Server (Beta)

The Telnet Server tool in the Microsoft Windows NT Server Resource Kit version 4.0 provides basic TCP/IP Telnet Server functionality. A computer running the Telnet Server tool under Windows NT Server can support connections from various TCP/IP Telnet clients, including UNIX-based and Windows NT–based computers.

The Telnet Server tool supports command-line execution of commands that normally can be run in the command window—for example, TCP/IP tool or MS-DOS commands. A command you enter at the remote Telnet client console (computer) runs on the Windows NT– based Telnet Server computer. The Telnet Server then sends the results of the command back to the remote Telnet client computer.

When you install Windows NT Server or Windows NT Workstation, a Telnet client is automatically installed in the Accessories folder. You use the Telnet client to connect to another computer running a TCP/IP– based Telnet server—for example, the Windows NT– based Telnet server, or a UNIX-based Telnet server.

Each Telnet client session started on the Windows NT–based Telnet server is allocated a console session that runs in the remote user's desktop context and that does not interfere with any local user sessions on the computer running Telnet Server under Windows NT. At the start of a Telnet session, the remote Telnet client must provide a user name and password to log on to the Windows NT– based Telnet Server. This information is used to create a console session with the security attributes of the user. For example, an administrator can log on to a computer running Windows NT Workstation, start the Windows NT– based Telnet client, connect to the computer running Windows NT Server with the Telnet Server tool, and run command-line scripts to add users, services, and so on.

Note

The Telnet Server tool provided with the Microsoft Windows NT Server Resource Kit version 4.0 is beta software. It does not support terminal types and provides only basic TTY functionality. To ask questions about the Telnet Server tool, contact rkinput@microsoft.com.


Microsoft dbWeb

Microsoft dbWeb is a gateway between Microsoft Open Database Connectivity (ODBC) data sources and the Internet Information Server. You can use Microsoft dbWeb to selectively publish data from an ODBC data source by using Hypertext Markup Language (HTML) pages. A user of a Web browser can easily create data queries and navigate by using hyperlinks through the data. But you control which data is accessible to users by creating parameters under Microsoft dbWeb that limit the data that can be retrieved by the user data queries. In other words, you can use Microsoft dbWeb to control access to the data you publish on the Internet and to provide easy-to-use tools such as query-by-example (QBE) and HTML.

Microsoft dbWeb supports 32-bit ODBC databases including:

  • Microsoft SQL Server
  • Microsoft Access
  • Microsoft Visual FoxPro™

The architecture of Microsoft dbWeb includes these services, which are discussed in the sections that follow:

  • The dbWeb Administrator, a graphical user interface
  • The dbWeb Internet Server Application Program Interface (ISAPI) client (dbWebc.dll)
  • The schema repository, a Microsoft Access database (dbWeb.mdb)
  • The dbWeb Service, a Windows NT Server service


dbWeb Administrator

The dbWeb Administrator is the component that an administrator uses to create schemas. Schemas control how the information in a database is published on the Internet and define the query and the resulting HTML pages that display to Internet clients.

The dbWeb Administrator provides an interactive Schema Wizard that leads you through the schema creation process by asking a series of questions. You can use the wizard to:

  • Specify search fields for a query-by-example (QBE) HTML page.
  • Choose the data fields that will appear on a displayed HTML page.
  • Specify the links within a displayed HTML page for interactive data navigation.

For information about using the dbWeb Wizard, see Resource Kit Tools Help.


dbWeb ISAPI Client

The dbWeb ISAPI client (dbWebc.dll) is the component that acts as the interface between the Internet client and the dbWeb service.


dbWeb Schema Repository

The dbWeb schema repository is a Microsoft Access database that stores query and formatting information. This information is entered by a site administrator by using the dbWeb Administrator service. After the query and formatting information is entered in the dbWeb schema, it is used by the dbWeb service, in turn, to retrieve user data selections or queries from the Microsoft SQL Server, Microsoft Access, or other 32-bit ODBC data source.


dbWeb Service

The dbWeb service component communicates with a user of Internet Explorer or another Web browser. The dbWeb service is a gateway that sends the user data queries to the ODBC data source.

When a user selects a schema, the dbWeb service retrieves the schema from the schema repository and uses it to dynamically build HTML pages in the form of query-by-example (QBE) forms, query results, or other method requests.

For instructions on how to configure and start the dbWeb service, see Resource Kit Tools Help.

The interaction between the dbWeb service and Internet clients is illustrated in Figure 7.1.

Figure 7.1 Microsoft dbWeb architecture


Installing and Running Microsoft dbWeb

To start Microsoft dbWeb, you need the following components installed on your computer:

  • Windows NT Server version 4.0, or version 3.51 with Service Pack 4
  • Internet Information Server
  • Microsoft Open Database Connectivity (ODBC) driver
  • Microsoft dbWeb
  • Internet Explorer or another Web browser

Before installing Microsoft dbWeb, you must install Microsoft Internet Information Server and the ODBC driver. For detailed information about installing Microsoft dbWeb and about using the dbWeb Administrator and the dbWeb service, see Resource Kit Tools Help.

Note

To ask questions about Microsoft dbWeb, contact rkinput@microsoft.com.


Additional Internet Products from Microsoft

Microsoft has developed browser, server, viewer, authoring, and development products specifically for the Internet. These products help you publish and view information on the Internet, and can be used to develop new Internet-based applications. You can get information about Microsoft products for the Internet at the Microsoft Internet Resource Center at http://www.microsoft.com/internet.


Chapter 8 - Troubleshooting an Internet Information Server Installation

This chapter presents approaches to solving common problems encountered when installing or configuring a computer running Internet Information Server (IIS) or Peer Web Services. This chapter provides information about:

  • Troubleshooting Internet Information Server—specific troubleshooting techniques or problems.
  • Sources of troubleshooting information—places to go for more troubleshooting information or general information about Windows NT.
  • Using troubleshooting tools—Windows NT Server tools that can be useful when determining a problem with Internet Information Server.


Troubleshooting Internet Information Server

This section provides four types of troubleshooting information:

  • A procedure to test Internet Information Server operation.
  • Where to go for more information when you receive Windows NT error messages.
  • The meaning of Hypertext Markup Language (HTML) 1.0 status codes and messages presented to users.
  • Tips for troubleshooting specific problems, listed by category of problem.


Testing an Installation

The default installation of Internet Information Server contains sample files that you can use to test the functionality of your Internet Information Server World Wide Web (WWW) service.

To test the WWW service on your server

1. Ensure your computer has an active connection to your intranet and that name resolution is working properly.

2. Start Microsoft Internet Service Manager and use it to verify that the WWW service is running.

3. In Internet Explorer, click Open on the File menu and type the Uniform Resource Locator (URL) for the home directory of your new server.

The URL is http:// followed by the NetBIOS name of your server. For example, if your server is called Myserver you type

http://myserver

A sample HTML page appears. If it does not, try the full path to access the samples page, for example

http://myserver/samples


Windows NT Messages

The Messages database, included in this Resource Kit, is another source of general troubleshooting information. Thousands of Windows NT messages are documented, along with the probable cause of errors that generate them and recommended solution to each. This database includes documentation of the STOP messages that appear with a blue screen when the system fails. For more general information on blue-screen messages, see Chapter 38, "Windows NT Executive STOP Messages," in the Windows NT Workstation Resource Guide.


HTTP 1.0 Status Codes and Reason Phrases

Clients can receive an HTTP status code and matching reason phrase after making a request to the IIS server.

The Hypertext Transport Protocol (HTTP) defines status codes and reason phrases that HTTP servers such as Internet Information Server can return to clients.

Status codes are returned by the server in response to a request. The three-digit code acknowledges an attempt to understand and satisfy the request. The reason phrase gives a short description of the status code.

Note

This section describes the status codes and reason phrases from the HTTP 1.0 Internet-draft. Note that Internet-drafts are valid for a maximum of six months. You should check the full text of the latest draft for the most current information. To learn the current status of any Internet draft, use FTP to check the 1id-abstracts.txt file in the Internet-Drafts directory on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

The first digit of the status code defines the class of response. There are five possible values for the first digit of the status code. Table 8.1 lists the five classes of codes and the reasons they are returned by the server.

Table 8.1 HTTP 1.0 Status Code Classification

Code | Class | Use
1xx | Informational | Not used, but reserved for future use.
2xx | Success | The action was successfully received, understood, and accepted.
3xx | Redirection | Further action must be taken in order to complete the request.
4xx | Client Error | The request contains incorrect syntax or cannot be fulfilled.
5xx | Server Error | The server failed to fulfill an apparently valid request.

Table 8.2 presents the individual values of the numeric status codes defined for HTTP 1.0. The reason phrases listed here are those that are recommended by the HTTP 1.0 protocol and are used by Internet Information Server.

Table 8.2 HTTP 1.0 Status Codes, Reason Phrases, and Meanings

Status code | Reason phrase | Meaning
200 | OK | The request has succeeded. The information returned with the response is dependent on the method used in the request, as follows: GET An entity1 corresponding to the requested resource is being sent in the response. HEAD The response must contain only the header information and no Entity-Body. POST An entity describing or containing the result of the action is being sent in the response.
301 | Moved permanently | The requested resource has been assigned a new permanent URL and any future references to this resource should use that URL.
302 | Moved temporarily | The requested resource resides temporarily under a different URL. Because the redirection is sometimes altered, the client should continue to use the Request-URI2 for future requests.
304 | Not modified | If the client has performed a conditional GET request and access is allowed, but the document has not been modified since the date and time specified in the If-Modified-Since field, the server responds with this status code and does not send an Entity-Body to the client. Header fields contained in the response should include only information that is relevant to cache managers and that may have changed independently of the date specified in the entity's Last-Modified field. Examples of relevant header fields include Date, Server, and Expires.
400 | Bad request | The request could not be understood by the server because of incorrect syntax.
401 | Unauthorized | The request requires user authentication.
403 | Forbidden | The server understood the request, but refuses to perform the request for an unspecified reason. Authentication will not help and the request should not be repeated.
404 | Not found | The server has not found anything matching the Request-URI. The server does not indicate whether the condition is temporary or permanent.
500 | Internal server error | The server encountered an unexpected condition that prevented it from fulfilling the request.
501 | Not implemented | The server does not support the functionality required to fulfill the request.
502 | Bad gateway | The server received an invalid response from the gateway or upstream server it accessed in attempting to fulfill the request.

1 An entity is a particular representation or rendition of a resource that may be enclosed within a request or response message. An entity consists of metainformation in the form of entity headers, and content in the form of an entity body.

2 Uniform Resource Identifier; see the HTTP 1.0 specification for an explanation of URI.

HTTP status codes are extensible, but the codes in Table 8.2 are the only codes that are recognized in current practice and are used by Internet Information Server.


Installation Problems

Cannot Install File During Setup

During Internet Information Server Setup, you can install Open Database Connectivity (ODBC) drivers. If you select ODBC drivers to be installed, the following message can appear when Setup tries to copy ODBC files:

Cannot install file c:\winnt\system32\odbc32.dll. It might be in use.
Close all applications and click Retry.

Click Ignore if you want to skip this file.

This problem occurs when applications that use ODBC drivers are running. However, it also happens when services, such as SQL Executive, are running.

To correct this problem

1. Close all open applications except the Internet Information Server Setup program. (The Error dialog box is displayed.)

2. In Control Panel, double-click Services.

3. Click SQL Executive and then click Stop.

4. Switch back to Internet Information Server Setup (Error dialog box) and click Retry.


Server Configuration Problems

Access Is Denied for Virtual Directories

The Directories property sheet for an Internet Information Server service displays the message "Access is Denied" in the Error column of a virtual directory listing. This message appears after you create a virtual directory in Internet Service Manager by specifying a network share in universal naming convention (UNC) format.

This problem occurs if the user account information is missing or incorrect when the virtual directory is created.

To correct this problem, you must enter the correct user account information by using Internet Service Manager.

To specify a user name for a virtual directory on a network drive

1. In Internet Service Manager, double-click the computer name of the service that uses the virtual directory.

2. Click the Directories property sheet and then select the virtual directory reporting the error.

3. Click Edit Properties. Enter the account information in the following format and then click OK:

User name: domainname\username
Password: password

FTP Server Users Experience Delayed Responses

Microsoft Internet Information Server File Transfer Protocol (FTP) clients experience delayed responses to commands when a large number of users are logged on through FTP. This problem occurs sporadically. File transfer speeds are not affected.

The default number of threads per processor (MaxPoolThreads value in Registry) installed on your system is 10. This might be insufficient for a heavily used FTP server because some of the FTP commands use synchronous I/O, causing threads to block while they complete.

To correct this problem

1. Click the Start button, then point to Run. In the Open box, type regedt32.exe and then click OK.

2. Click the HKEY_LOCAL_MACHINE window and locate the following key:

\System
\CurrentControlSet
\Services
\InetInfo
\Parameters.

3. From the Edit menu, click Add Value.

4. In the Add Value dialog box, enter the value MaxPoolThreads with the data type REG_DWORD.

5. In the DWORD Editor dialog box, enter a value in the range 0 to 0xFFFFFFFF.

For example, a twin processor with 500 to 1,000 concurrent users might require 50 or more threads per processor to provide quick response for all FTP client users.

6. Click OK and quit the Registry Editor.

7. Shut down and restart Windows NT.

Warning

If you use Registry Editor incorrectly it can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

Anonymous Users Have Same Access as Domain Users

You allow anonymous users access to specific public Web pages and allow domain users access to additional Web pages. Your server is a primary domain controller that uses the Windows NT File System (NTFS) security permissions. However, after configuration, anonymous users have the same access as domain users.

The problem is that any user account that you create on a primary domain controller automatically becomes a member of the Domain Users group.

In Internet Information Server, you can allow both anonymous and domain users access to the selected Web pages. To do this, select Allow Anonymous and Windows NT Challenge/Response boxes on the WWW property sheet, then use NTFS security permissions to specify access. However, the Internet Information Server anonymous access account, IUSR_computername, becomes a member of Domain Users when Internet Information Server is installed on a primary domain controller. As a result, anonymous users have the same access as the domain users.

To correct this problem, remove IUSR_computername from the global group Domain Users. You must then add the Log On Locally user right to the IUSR_computername account. As an alternative, you can replace the IUSR_computername account on the domain controller with an account that has appropriate permissions.

Cannot Start Internet Information Server Services

When the WWW service cannot automatically start during Windows NT startup, the Event Viewer records the message, "HTTP could not initialize socket library." The options to change properties of Internet Information Server services are unavailable in Internet Service Manager. When you attempt to start the WWW service and FTP service manually, a message states "Data area passed to system call is too small."

To solve this problem, you change the order of protocols listed in the Registry key and move Tcpip to the first entry in the list of values.

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Winsock
\Parameters
\Transports

Clients Cannot See Virtual Directories in Directory Listings

FTP, Gopher, and WWW directory browsing clients (such as Internet Explorer) are not able to see virtual directories.

Internet Information Server does not display virtual directories in directory listings returned to clients.

If you know the name (alias) of the virtual directory, you can work around this limitation by explicitly specifying the name of the virtual directory in the client. In a WWW browser, you include the virtual directory name in the URL, for example:

ftp://myftpserver/virtual_directory/

In a dedicated FTP client, you explicitly change directories by using the virtual directory name, for example:

cd /virtual_directory

You must type the forward slash (/). Otherwise, cd tries to change the directory from within the client's current directory.

HTTP/1.0 Error 500

The following HTTP server message can be returned for an anonymous user logon request:

HTTP/1.0 500 Server Error (Logon failure: the user has not been granted
the requested logon type at this computer.)

Frequently, this message means that your anonymous user does not have local logon rights.

To make sure an anonymous user can log on locally

1. In the Microsoft Internet Service Manager, open the WWW Service properties sheet. Verify that the anonymous logon user name and password specified here are identical to the user name and password in User Manager.

2. Run User Manager to verify that the Log On Locally user right includes your designated anonymous user name.

– or –

Change the anonymous user account to an account that has the Log On Locally user right specified in User Manager.


Client Problems

Netscape Navigator 2.0 Does Not Support Authentication

If you use Netscape Navigator 2.0 to access an IIS server that uses Windows NT challenge/response password authentication, a dialog box appears that requests your user name and password. After you enter the correct user name and password, you see the message "Error: Access is Denied."

Even though Netscape Navigator 2.0 prompts you for a user name and password, it does not support Windows NT challenge/response password authentication.

To correct this problem, use Anonymous access or Basic user authentication in Internet Information Server, or upgrade clients to Internet Explorer version 2.0 or later.

Internet Explorer 2.0 Ignores Size Attribute

Internet Explorer 2.0 does not use the Size attribute of the Select tag on HTML pages properly.

RFC 1866 specifies that the Size attribute indicates the number of selections that are displayed when a user clicks a list box. A user should be able to see the selections by scrolling through the selection list box.

Internet Explorer 2.0 displays more than one list item even when Size is set to 1. If you increase the value of the Size attribute, the list box size grows. However, the size of the list box might not correspond to the setting. For example, with Size set to 1, the list box shows three selections, but with Size set to 5, the selection list box shows only four selections.

To overcome this problem, upgrade to Internet Explorer version 3.0.

Internet Explorer 1.5 Does Not Use Default Selection

Internet Explorer version 1.5 for Windows NT does not automatically select (highlight) the preselected item of an option list in an HTML form. The user must click the Reset button or manually select the item.

Internet Explorer 1.5 Is Unable to Save Files

If you run Internet Explorer version 1.5, you might see the message:

Unable to save C:\Temp\filename. Disk may be full.
The attempt to load ftp:filename failed.

This might be caused by a full disk, as stated in the message. The problem can also be caused by a client browser that does not have a \Temp directory.

To solve this problem, create a directory named "Temp" off the root of the boot drive, for example, C:\Temp.

Browsers Fail to Connect When Using SSL

Netscape Atlas and other browsers that support version 3 of the Secure Sockets Layer (SSL) might fail to connect to Microsoft Internet Information Server when the IIS server is using SSL.

Internet Information Server version 2.0 supports SSL version 2. Newer Web browsers, such as Netscape Atlas, support SSL version 3. When the Web browser connects to Internet Information Server, the browser tries to connect by using SSL version 3. Internet Information Server does not recognize SSL version 3 clients, so the connection is immediately dropped. Clients do not attempt to use version 2 after version 3 is rejected by the server.

To solve this problem, use a browser that supports SSL version 2.

Internet Explorer 2.0 Fails to Connect to SSL-Enabled Internet Information Server

When connecting to SSL-enabled IIS servers, you might get one or more of the following messages:

HTTP/1.0 403 Access Forbidden (Secure Channel Required - This Virtual
Directory requires a browser that supports the configured encryption
options.)

–or–

Unable to connect to servername

To fix this problem, upgrade to Internet Explorer version 2.01 or later.


Logging Problems

Logging to SQL Server on the Network Fails

Although a valid SQL Server user name and password are entered on the Logging property sheet in Internet Service Manager, they might seem to disappear when you start Internet Service Manager.

This is a problem with SQL Server Login Security Mode set to Integrated. In Integrated mode, the user name and password specified in Internet Service Manager are ignored because SQL Server attempts to use the logon account specified when the computer running the IIS server was started. Because this account probably does not have permission to use SQL Server, Internet Information Server logging to SQL Server fails and the SQL Server log records this message:

failure condition - logon failed because there is no valid user account.

And the IIS server reports the following:

Error: odbc reported an error. The Datasource name "DSN_name" may be
incorrect. Check the server's event log for details.

To resolve this issue, set the SQL Server Login Security Mode to Mixed. This setting enables the IIS server to access SQL Server for logging. Access to SQL Server by using other access methods is unaffected.

For more information about SQL Server Login Security Mode, see Part 4, "Security," of the Administrator's Companion in the Microsoft SQL Server Books Online.

Time Field Appears Wrong in Log

The Microsoft Internet Information Server log file contains a Time field. This field displays the elapsed time from the start of a request (connect) until the request is finished and the item is about to be logged. The value represents only a checkpoint in terms of millisecond difference.


Application and Script Problems

Testing CGI Scripts

You can use a Perl script to test for the proper installation and execution of Common Gateway Interface (CGI) scripts with Internet Information Server.

Use a text editor to create a file with the following lines of code. Save the file in the /Scripts directory as Hello.pl.

print "Content-Type: text/html\n\n";
print "<HTML>\n";
print "<HEAD>\n";
print "<TITLE>Hello World</TITLE>\n";
print "</HEAD>\n";
print "<BODY>\n";
print "<H4>Hello World</H4>\n";
print "<P>\n";
print "Your IP Address is $ENV{REMOTE_ADDR}.\n";
print "<P>";
print "<H5>Have a nice day</H5>\n";
print "</BODY>\n";
print "</HTML>\n";

After you create the file, configure Perl to run securely with Internet Information Server. Do not locate Perl.exe in any directory accessible by a user. Create a script mapping in the Registry for Perl.exe to enable the script to run by using Perl.

To configure script mapping for Perl

1. Click the Start button, then point to Run. In the Open box, type regedt32.exe and then click OK.

2. Click the HKEY_LOCAL_MACHINE window and locate the following key:

\System
\CurrentControlSet
\Services
\W3SVC
\Parameters
\ScriptMap

3. From the Edit menu, click Add Value.

4. In the Add Value dialog box, enter the value name .pl with the data type REG_SZ.

5. In the String Editor dialog box type the string value

full path\perl.exe %s

and click OK.
This instructs Internet Information Server to interpret all files with the extension .pl by using Perl.exe.

6. To implement these changes, quit the Registry Editor, then stop and restart the WWW service.

7. Test the Perl script with your browser. For example, in Internet Explorer, type

http://Servername/scripts/helloworld.pl?

Programs Attempt to Download to Client Computers

When you attempt to run a script on a client Web browser, an Unhandled File Type dialog box might appear. It requests that you save the file as a different filename or in a different location (Save As).

The problem is that the /Scripts directory has both Read and Execute access permissions set in Internet Service Manager. To work around this problem, do one of the following:

  • Change the access permissions in Internet Service Manager to Execute only.
  • Add a question mark (?) to the end of the URL. For example,

http://myserver/scripts/test.exe?

Programs from 16-bit Compilers Fail to Run

A CGI script compiled with a 16-bit C compiler might fail to run on Internet Information Server.

For example, say you use a 16-bit compiler to compile and build an executable file out of this C language source code:

#include <stdio.h>
void main()|
{
printf( "Content-type: text/html\n\n" );
printf( "<BODY BGCOLOR=\"#FFFFF0\" TEXT=\"#0000FF\">" );
printf( "<TITLE>This is a Test page</TITLE>" );
printf( "<h2>Hello World.</h2><br>" );
printf( "<h1><center>End of the test page.</center></h1>" );
printf( "</BODY>\n" );
}

If you then run the .exe file from the command prompt of Windows NT, the correct HTML output is generated. However, the results will be different if you place the same executable file in the /Scripts directory of the computer running Internet Information Server. If you try to run it from a Web browser by using the syntax.

http://Server/Path/File.exe?

it fails to generate the correct page.

To correct this problem, use a 32-bit C compiler to compile and build the C language source code. Microsoft C/C++ 4.0 and C/C++ 2.0 are 32-bit C compilers.

REMOTE_USER Variable Is Blank

Microsoft Internet Information Server does not return a user name for the variable REMOTE_USER unless both of the following are true:

  • Basic (clear-text) password authentication is used.
  • Anonymous access is not allowed. (That is, you clear the Allow Anonymous box on the WWW Service property sheet.)

If you use anonymous authentication, all users are authenticated with the IUSR_computername account, and the variable is not assigned a value by default.

One method of obtaining the REMOTE_USER variable is to create a batch file with the following lines and save it in the /Scripts directory, or a directory enabled in Internet Information Server for execute permissions:

@echo off
echo Content-Type: text/plain
echo.
Set

This batch file lists the environment variables used by Internet Information Server, including the REMOTE_USER variable. The list is returned as an HTML page to the Web browser that started the batch file.

Make sure you have configured script mapping for .bat or .cmd files, as described in the Internet Information Server Installation and Administration Guide.

You run the script from a browser by typing a URL with the syntax

http://Server_Name /Script

For example, you might type

http://www.company.com/scripts/environment.cmd?

The question mark at the end of the URL is required. The question mark signals the server that this is a GET request, which makes the server return script results rather than downloading the file to the user.

CGI Scripts Return Error

When submitting an HTML form or clicking a link to a script from a Web browser, the following message might be returned:

CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
Can't open perl script "c:\inetsrv\wwwroot\scripts\test.pl":
No such file or directory

This error is caused by missing or incorrect CGI header information. In this case, the headers are missing because the script file cannot be run. Therefore, the message was displayed instead of the output from the script.

The CGI specification calls for the script file to return at least one header. This header indicates how to fill out the remainder of the HTTP headers as required by that protocol. HTTP also requires a blank line between the end of the headers and the start of the document. Some servers return an error if the blank line is not present. The only headers currently supported by the CGI specification are:

  • Content-type
  • Location
  • Status

For more information about these headers, see the HTTP and CGI protocol draft specifications at http://www.w3.org.


IDC Problems

Troubleshooting Microsoft SQL Server

If an Internet Information Server application cannot connect to SQL Server, it might indicate a problem with the network or SQL Server. You can test Microsoft Internet Information Server connectivity with SQL Server by using tools provided with Microsoft SQL Server. Table 8.3 describes tools included with the Microsoft SQL Server product that can help isolate network problems.

Table 8.3 SQL Server Troubleshooting Tools

SQL Server tool |  | Purpose |  | Location
Makepipe.exe |  | Tests the integrity of the network named pipe services. |  | SQL Server
Readpipe.exe |  | Tests the integrity of the network named pipe services. |  | SQL Server clients
Odbcping.exe |  | Troubleshoots connectivity to SQL Server through Microsoft ODBC SQL Server drivers. |  | SQL Server
Isqlw.exe | Queries SQL Server, analyzes the execution plan of a query, and views statistics about the executed query. |  | SQL Server and clients

For more information about Microsoft SQL Server and these tools, see the Microsoft SQL Server Books Online.

SYBASE SQL Server Does Not Work with Internet Information Server

If you try to connect to a SYBASE® database through an .idc file by using the ODBC drivers included in Internet Information Server, you might see this message:

Error performing query state=01000, error 1225 Microsoft ODBC SQL Server
Driver DBNMPNTW Connection open Create file
State = 08001 error = 1225 Microsoft ODBC SQL Server Driver unable to
connect to data source.

The current Microsoft SQL Server ODBC driver is not certified for use with SYBASE SQL Server.

To correct this problem, use SYBASE SQL Server ODBC drivers. Contact SYBASE Corporation for ODBC drivers certified for use with SYBASE SQL Server. Many third-party ODBC vendors also provide ODBC drivers certified for use with SYBASE SQL Server.

SQL Server Returns 'Not Defined as a Valid User'

You might see the following message when accessing an Internet Database Connector (IDC) script:

Error Performing Query
*[State=3700][Error=18450][Microsoft][ODBC SQL Driver][SQL Server]
Login failed- User: _ Reason: Not defined as a valid user of a trusted
SQL Server Connection.

This message can appear under the following conditions:

  • You are not running SQL Server and Internet Information Server on the same computer.
  • You are using Windows NT challenge/response authentication on Internet Information Server.
  • You are using integrated or mixed security with Microsoft SQL Server.
  • You are not providing the user name or password values in your .idc file.

When the client runs the IDC script, Internet Information Server must determine whether the data source is local or remote. If the data source is defined as Local System, the query is passed to SQL Server on the same computer. If the data source is remote, the computer running Internet Information Server must make a network connection to SQL Server. When Internet Information Server makes the network connection, it does not pass the credentials of the remote user. It passes a blank user name and password instead.

SQL Server does not validate a user without a user name, and returns the message to Internet Information Server. Internet Information Server then passes the results of the query to the client Web browser.

There are two possible workarounds:

  • Install SQL Server and Internet Information Server on the same computer. Then set up your ODBC system Data Source Name (DSN) to be Local Server instead of a remote computer name.
  • Use Basic authentication instead of Windows NT challenge/response authentication.

Pipe/Connection Busy or Time-out Expired Errors Appear when Using SQL Server

If Internet Information Server connects to Microsoft SQL Server through the Internet Database Connector, multiple error messages can appear as databases are added to SQL Server.

The following messages might be displayed when using the Internet Database Connector to make SQL requests to Microsoft SQL Server, if it has a growing number of databases:

*[State=01000][Error=231][Microsoft][ODBC SQL Server Driver]Pipe busy.
*[State=08001][Error=3][Microsoft][ODBC SQL Server Driver]Connection is busy.
*[State=S1T00][Error=0][Microsoft][ODBC SQL Server Driver]Time-out expired.

These problems can result if the SQL Server configuration parameter Open Databases is set too low. SQL Server 6.0 sets this value to 20 by default. If you add databases to SQL Server until you exceed the configured value, it does not generate an "out of open databases" message in the SQL Server log. Instead, the messages listed above appear when you query the database from Internet Information Server.

To solve this problem, increase the value of the SQL Server configuration parameter Open Databases. For more information on setting this parameter, consult the Microsoft SQL Server Administrator's Companion.


Sources of Troubleshooting Information

In addition to the troubleshooting tools that are described later in this chapter, there are several other sources of troubleshooting information in the Windows NT Server Resource Kit and elsewhere. Table 8.4 describes resources that can help you in troubleshooting your Internet Information Server installation.

Table 8.4 Sources of Troubleshooting Information

Resource | Information
Windows NT Workstation Resource Guide, Chapter 23, "Overview of the Windows NT Registry" | Describes how to use information in the Registry for troubleshooting and configuration maintenance.
Windows NT Workstation Resource Guide, Chapter 25, "Configuration Management and the Registry" | Provides problem-solving techniques that use the Registry.
Windows NT Workstation Resource Guide, Chapter 36, "General Troubleshooting" | Provides troubleshooting information for Windows NT.
Windows NT Workstation Resource Guide, Chapter 21, "Troubleshooting Startup and Disk Problems" | Discusses what you can do to find the cause of problems when your computer fails to complete startup.
Windows NT Workstation Resource Guide, Chapter 38, "Windows NT Executive STOP Messages" | Describes the different kinds of STOP, STATUS, and hardware malfunction messages.
Windows NT Workstation Resource Guide, Chapter 39, "Windows NT Debugger" | Describes how to set up for debugging and use Windows NT debugging tools.
Windows NT Server Resource Kit Messages database | Documents thousands of messages with the probable cause of errors and recommended solution. This includes the STOP messages that appear when the system fails with a blue screen.
Windows NT Help | Contains troubleshooting information for the Windows NT operating system.
Microsoft Knowledge Base | Contains support information developed by the Microsoft Support Network. The Windows NT Knowledge Base is included on the Windows NT Workstation Resource Kit CD and Windows NT Server Resource Kit CD. It is also included on the Microsoft Developer Network (MSDN) CD and the TechNet CD, and is accessible through the Microsoft home page, www.microsoft.com. You can search for all Windows NT Internet Information Server articles by specifying Internet Information Server in the query.
Windows NT Workstation Start Here, Appendix A, "Windows NT Setup Troubleshooting" | Describes how to overcome problems installing Windows NT 4.0 on Intel-based computers.


Using Troubleshooting Tools

This section provides a brief overview of the troubleshooting tools that are available on the Windows NT Workstation and Windows NT Server product CDs and the Windows NT Workstation Resource Kit CD and Windows NT Server Resource Kit CD.


Windows NT Tools

The tools described in Table 8.5 are installed when you install Windows NT Workstation or Windows NT Server.

Table 8.5 Windows NT Troubleshooting Tools

Tool | Purpose | For more information
Event Viewer | Displays the system, security, and application logs. | Chapter 37, "Monitoring Events," in the Windows NT Workstation Resource Guide
Performance Monitor | Measures your computer's efficiency, identifies and troubleshoots possible problems, and plans for additional hardware needs. | Part III, "Optimizing Windows NT Workstation," in the Windows NT Workstation Resource Guide, and Chapter 8, "Monitoring Performance," in Windows NT Server Concepts and Planning
Task Manager | Monitors active applications and processes on your computer, and starts and stops them. | Chapter 11, "Performance Monitoring Tools," in the Windows NT Workstation Resource Guide
Windows NT Diagnostics | Enables you to view hardware information in the Registry, such as currently loaded device driver and IRQ values. | Chapter 36, "General Troubleshooting," in the Windows NT Workstation Resource Guide
Network Monitor | Determines problems during session initialization and problems related to broadcast storms, and troubleshoots packets for transmission problems between computers. | Chapter 10, "Monitoring Your Network," in Windows NT Server Concepts and Planning
TCP/IP Utilities | Verifies and debugs TCP/IP networking problems. | Appendix A, "TCP/IP Utilities," in the Windows NT Server Networking Guide


Windows NT Resource Kit Tools

The Windows NT Workstation Resource Kit and Windows NT Server Resource Kit CDs contain many tools that can be used for troubleshooting. This list shows the tools available:

  • Crystal Reports Event Log Viewer
  • Device Driver Information
  • Dump Event Log
  • Find Group
  • Obtain Ethernet layer address and binding order
  • Task Killing Utility
  • Event Logging Utility
  • Performance Data Logging Service and Configuration Tool
  • Performance Meter
  • Performance Tools
  • Page Fault Monitor
  • Process Resource Monitor
  • Process and Thread Status
  • Process Viewer
  • CPU Usage by Processes
  • TimeThis
  • Task List Viewer

For information about these tools, refer to the Resource Kit Tools Help and double-click the Computer Diagnostic Tools topic on the Contents page.


Glossary


A

A-type resource record

A line (record) in a computer's Domain Name System database that maps a computer's domain name (host name) to an IP address in a DNS zone.

ActiveX™

An umbrella term for Microsoft technologies that enable developers to create interactive content for the World Wide Web.

application programming interface (API)

A set of routines that an application program uses to request and carry out lower-level services performed by another component, such as the computer's operating system or a service running on a network computer.

auditing

Tracking activities of users by recording selected types of events in the security log of a server or a workstation.

authentication

Validation of a user's logon information. Authentication is used to enforce selective permission to access resources or to perform an operation.


B

backup domain controller (BDC)

In a Windows NT Server domain, a computer running Windows NT Server that receives a copy of the domain's directory database, which contains all account and security policy information for the domain. The copy is synchronized periodically and automatically with the master copy on the primary domain controller (PDC). BDCs also authenticate user logons and can be promoted to function as PDCs as needed. Multiple BDCs can exist on a domain. See also domain controller; primary domain controller.

bandwidth

In communications, the difference between the highest and lowest frequencies in a given range. For example, a telephone line accommodates a bandwidth of 3000 Hertz (Hz), the difference between the lowest (300 Hz) and highest (3300 Hz) frequencies it can carry. In computer networks, greater bandwidth indicates faster data-transfer capability and is expressed in bits per second (bps).

Basic (clear-text) authentication

A method of authentication that encodes user name and password data transmissions. Basic authentication is called "clear text" because the base-64 encoding can be decoded by anyone with a freely available decoding utility. Note that encoding is not the same as encryption. See also challenge/response authentication; encryption.

BDC

See backup domain controller.

bits per second (bps)

The measure of speed at which data is transferred over a network.

blue screen

The screen displayed when Windows NT encounters a serious error.

bootstrap protocol (BOOTP)

A TCP/IP network protocol used to configure network computers. Defined by RFC 951 and RFC 1542. DHCP provides a superset of the functions provided by BOOTP. DHCP and BOOTP interoperation is defined by RFC 1534. See also Dynamic Host Configuration Protocol.

bps

See bits per second.

browser

See Web browser.

BSD UNIX

A version of UNIX developed by Berkeley Software Design Incorporated.

bulk data encryption

The encryption of all data sent over a network.


C

CGI

See Common Gateway Interface.

challenge/response authentication

A method of authentication in which a server uses challenge/response algorithms and Windows NT security to control access to resources. See also Basic (clear-text) authentication; encryption.

clear-text authentication

See Basic (clear-text) authentication.

Common Gateway Interface (CGI)

A standard interface for HTTP server application development. The standard was developed by the National Center for Supercomputing Applications.

connection-oriented protocol

A network protocol with four important characteristics: the path for data packets is established in advance; the resources required for a connection are reserved in advance; a connection's resource reservation is enforced throughout the life of that connection; and when a connection's data transfer is completed, the connection is terminated and the allocated resources are freed.


D

Data Source Name (DSN)

The logical name used by ODBC to refer to the drive and other information required to access data. The name is use by Internet Information Server for a connection to an ODBC data source, such as a SQL Server database. To set this name, you double-click ODBC in the Control Panel.

dbWeb Administrator

The graphical user tool for Microsoft dbWeb that allows an administrator to create definition templates referred to as schemas. Schemas control how and what information from a private database is available to visitors who use the Internet to access the public Microsoft dbWeb gateway to the private database. See also schemas.

default gateway

In TCP/IP, the intermediate network device on the local network that has knowledge of the network IDs of the other networks in the Internet, so it can forward the packets to other gateways until the packet is eventually delivered to a gateway connected to the specified destination.

DHCP

See Dynamic Host Configuration Protocol.

DHCP Relay Agent

The component responsible for relaying DHCP and BOOTP (bootstrap protocol) broadcast messages between a DHCP server and a client across an IP router. See also bootstrap protocol; Dynamic Host Configuration Protocol.

DHCP server

Dynamic Host Configuration Protocol server. A server that automatically administers client TCP/IP addresses and related settings for a network.

Dial-Up Networking

A component of Windows NT and Windows 95. Enables users to connect to remote networks, such as the Internet or a private network.

directory replication

The copying of a master set of directories from a server (called an export server) to specified servers or workstations (called import computers) in the same or other domains. Replication simplifies the task of maintaining identical sets of directories and files on multiple computers, because only a single master copy of the data must be maintained. Files are replicated when they are added to an exported directory, and every time a change is saved to the file. See also Directory Replicator service.

Directory Replicator service

Replicates directories, and the files in those directories, between computers. See also directory replication.

Directory Service Manager for NetWare (DSMN)

A component of Windows NT Server. Enables network administrators to add NetWare servers to Windows NT Server domains and to manage a single set of user and group accounts that are valid at multiple servers running either Windows NT Server or NetWare.

DLL

See dynamic-link library.

DNS name

See domain name.

DNS name servers

In the DNS client/server model, the servers containing information about a portion of the DNS database, which makes computer names available to clients querying for name resolution across the Internet. See also Domain Name System.

DNS server

See DNS name servers.

DNS service

The service that provides domain name resolution. See also DNS name servers.

domain controller

In a Windows NT Server domain, refers to the computer running Windows NT Server that manages all aspects of user-domain interactions, and uses information in the directory database to authenticate users logging on to domain accounts. One shared directory database is used to store security and user account information for the entire domain. A domain has one primary domain controller (PDC) and one or more backup domain controllers (BDCs). See also backup domain controller; primary domain controller.

domain name

Part of the Domain Name System (DNS) naming structure, a domain name is the name by which a domain is known to the network. Domain names consist of a sequence of labels separated by periods. DNS domains are not Windows NT networking domains. See also Domain Name System.

Domain Name System (DNS)

Sometimes referred to as the BIND service in BSD UNIX, DNS offers a static, hierarchical name service for TCP/IP hosts. The network administrator configures the DNS with a list of host names and IP addresses, allowing users of workstations configured to query the DNS to specify remote systems by host names rather than by IP addresses. For example, a workstation configured to use DNS name resolution can use the command ping remotehost rather than ping 172.16.16.235 if the mapping for the system named "remotehost" was contained in the DNS database. DNS domains are not the same as Windows NT networking domains.

DSMN

See Directory Service Manager for NetWare.

dynamic assignment

The automatic assignment of TCP/IP properties in a changing network.

Dynamic Host Configuration Protocol (DHCP)

A protocol that offers dynamic configuration of IP addresses and related information. DHCP provides safe, reliable, and simple TCP/IP network configuration, prevents address conflicts, and helps conserve the use of IP addresses through centralized management of address allocation. Defined in RFC 1541.

dynamic-link library (DLL)

An operating system feature that enables executable routines (generally serving a specific function or set of functions) to be stored separately as files with .dll extensions and to be loaded only when needed by the program that calls them.


E

encryption

The process of making information indecipherable to protect it from unauthorized viewing or use, especially during network transmission or when it is stored on a transportable magnetic medium.

enterprise network

A network for a large organization that has several thousand employees (for example, more than 40,000 users) and sometimes has multiple sites.


F

file allocation table (FAT)

A table or list maintained by some operating systems to keep track of the status of various segments of disk space used for file storage. Also referred to as the FAT file system. See also Windows NT File System.

File and Print Services for NetWare (FPNW)

A Windows NT Server component that enables a computer running Windows NT Server to provide file and print services directly to NetWare-compatible client computers.

File Transfer Protocol (FTP)

An older TCP/IP protocol used for transferring files between different computers. FTP is characterized by a required logon to the remote computer and the ability to browse directories and two-way file transfer. Most of the functions of this protocol have been subsumed by Hypertext Transport Protocol (HTTP).

firewall

A system or combination of systems that enforces a boundary between two or more networks and keeps intruders out of private networks. Firewalls serve as virtual barriers to passing packets from one network to another.

FPNW

See File and Print Services for NetWare.

Frame Relay

A synchronous High-level Data Link Control (HDLC) protocol–based network that sends data in HDLC packets.

FTP

See File Transfer Protocol.


G

Gateway Service for NetWare (GSNW)

A Windows NT Server component that enables a computer running Windows NT Server to connect to NetWare servers. Creating a gateway enables computers running only Microsoft client software to access NetWare resources through the gateway.

Gopher

A hierarchical system for finding and retrieving information from the Internet or an intranet. Similar to FTP, Gopher uses a menuing system and enables links to other servers.

GSNW

See Gateway Service for NetWare.


H

home directory

The root directory for an Internet Information Server service. The directory is accessible to the user and contains files and programs. Typically the home directory for a site contains the home page. See also home page.

home page

The initial page of information for a collection of pages. The starting point for a Web site or section of a Web site is often referred to as the home page. Individuals also post pages that are called home pages.

HOSTS file

A local text file in the same format as the 4.3 Berkeley Software Distribution (BSD) UNIX \etc\hosts file. This file maps host names to IP addresses. In Windows NT, this file is stored in the \Systemroot\System32\Drivers\Etc directory.

HTML

See Hypertext Markup Language.

hyperlink

A way of jumping to another place on the Internet. Hyperlinks usually appear in a different format from regular text. You initiate the jump by clicking the link.

Hypertext Markup Language (HTML)

A simple markup language used to create hypertext documents that are portable from one platform to another. HTML files are simple ASCII text files with codes embedded (indicated by markup tags) to indicate formatting and hypertext links. The formatting language used for documents on the World Wide Web.

Hypertext Transport Protocol (HTTP)

The underlying protocol by which WWW clients and servers communicate. HTTP is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.


I

IANA

See Internet Assigned Numbers Authority.

IDC

See Internet Database Connector.

IETF

See Internet Engineering Task Force.

IIS

See Internet Information Server.

IMIII

See Intelligent Messaging III.

IMC

See Internet Mail Connector.

Inetinfo

A process containing the FTP, Gopher, and HTTP services. This process is about 400K in size. In addition to the FTP, Gopher, and HTTP services, this process contains the shared thread pool, cache, logging, and SNMP services of Internet Information Server.

Integrated Services Digital Network (ISDN)

A type of phone line used to enhance WAN speeds, an ISDN line can transmit at speeds of 64 or 128 kilobits per second, as opposed to standard phone lines, which typically transmit at only 9600 bits per second (bps). An ISDN line must be installed by the phone company at both the server site and the remote site. See also bits per second.

Intelligent Messaging III (IMIII)

Electronic mail server software for Banyan® VINES® networks.

internet

A collection of two or more private networks.

Internet

The global network of networks.

Internet Assigned Numbers Authority (IANA)

The central coordinator for the assignment of unique parameter values for Internet protocols. IANA is chartered by the Internet Society (ISOC) and the Federal Network Council (FNC) to act as the clearinghouse to assign and coordinate the use of numerous Internet protocol parameters. Contact IANA at http://www.iana.org/iana/.

Internet Assistant

Several Internet Assistant add-on software components are available for Microsoft Office products. Each Internet Assistant adds functionality that is relevant to creating content for the Internet. For example, Internet Assistant for Microsoft Word enables Word to create HTML documents from within Microsoft Word.

Internet Database Connector (IDC)

Provides access to databases for Internet Information Server by using ODBC. The Internet Database Connector is contained in Httpodbc.dll, which is an Internet Server API DLL.

Internet Engineering Task Force (IETF)

A consortium that introduces procedures for new technology on the Internet. IETF specifications are released in documents called requests for comments (RFCs). See also request for comments.

Internet Information Server (IIS)

A network file and application server that supports multiple protocols. Primarily, Internet Information Server transmits information in Hypertext Markup Language (HTML) pages by using the Hypertext Transport Protocol (HTTP).

Internet Mail Connector (IMC)

The Internet Mail Connector is a component of Microsoft Exchange Server that runs as a Windows NT Server service. You can use the Internet Mail Connector to exchange information with other systems that use the Simple Mail Transfer Protocol (SMTP).

Internet Network Information Center (InterNIC)

The coordinator for DNS registration. To register domain names and obtain IP addresses, contact InterNIC at http://internic.net.

Internet Protocol (IP)

The part of TCP/IP that routes messages from one Internet location to another. IP is responsible for addressing and sending TCP packets over the network. IP provides a best-effort, connectionless delivery system that does not guarantee that packets arrive at their destination or that they are received in the sequence in which they were sent. See also packet.

Internet Relay Chat (IRC)

A protocol that enables two or more people, each in remote locations, who are connected to an IRC server to hold real-time conversations. IRC is defined in RFC 1459.

Internet Server Application Programming Interface (ISAPI)

An API for developing extensions to the Microsoft Internet Information Server and other HTTP servers that support the ISAPI interface. See also application programming interface.

Internet service provider (ISP)

A company or educational institution that enables remote users to access the Internet by providing dial-up connections or installing leased lines.

InterNIC

See Internet Network Information Center.

intranet

A TCP/IP network that uses Internet technology. May be connected to the Internet; if connected to the Internet, intranets are usually protected by a firewall or other security device.

IP

See Internet Protocol.

IP address

Used to identify a node on a network and to specify routing information. Each node on the network must be assigned a unique IP address, which is made up of the network ID, plus a unique host ID assigned by the network administrator. This address is typically represented in dotted-decimal notation, of four period-delimited octets (eight bits, or one byte) consisting of up to 12 numerals (for example, 138.57.7.27). See also Dynamic Host Configuration Protocol; node.

IPX

Transport protocol used in Novell NetWare networks. Also referred to as IPX/SPX. Windows NT implements IPX through NWLink.

ISDN interface card

Similar in function to a modem, an ISDN card is hardware that enables a computer to connect to other computers and networks on an Integrated Services Digital Network.

ISP

See Internet service provider.


K

kiosk

A computer, connected to the Internet, made available to users in a commonly accessible location.


L

LAN

See local area network.

leased line

A high-capacity line (most often a telephone line) dedicated to network connections.

line printer daemon (LPD)

A line printer daemon service on the print server receives documents (print jobs) from line printer remote (LPR) utilities running on client systems.

LMHOSTS file

A local text file that maps IP addresses to the computer names of Windows NT networking computers outside the local subnet. In Windows NT, this file is stored in the \Systemroot \System32\Drivers\Etc directory.

local area network (LAN)

A group of computers and other devices dispersed over a relatively limited area and connected by a communications link that enables any device to interact with any other on the network.

Local Mail Delivery Agent

The component of the SMTP server that processes messages that have been received by the SMTP server and downloads the messages to the user's local computer.

loopback address

The IP address 127.0.0.1, which has been specified by the Internet Engineering Task Force as the IP address to use in conjunction with a loopback driver to route outgoing packets back to the source computer. See also loopback driver.

loopback driver

A network driver that allow the packets to bypass the network adapter card completely and be returned directly to the computer that is performing the test. See also loopback address.

LPD

See line printer daemon.


M

Mail Server (MailSrv)

A Windows NT service that sends and receives electronic mail on a TCP/IP network by using the SMTP and POP3 protocols. Also simply referred to as an SMTP server, this tool is provided in the Windows NT Server Resource Kit.

Management Information Databases (MIBs)

Software that describes manageable aspects of your network that use the Simple Network Management Protocol (SNMP). The MIB files included with Windows NT can be used by third-party SNMP monitors to enable SNMP monitoring.

Microsoft dbWeb

A database publishing gateway provided in the Windows NT Server Resource Kit. dbWeb can run under Internet Information Server to provide public access to private enterprise ODBC sources as specified by an administrator of the private enterprise.

The Microsoft Network (MSN)

Online service that offers a free Internet site to all Internet users. Subscribers can also use proprietary information and obtain Internet access.

MIME

See Multipurpose Internet Mail Extensions.

modem

Modulator/demodulator. A communications device that enables a computer to transmit information over a standard telephone line.

MPR

See multiprotocol routing.

multihomed system

A system with multiple network adapters attached to separate physical networks.

multiport serial adapter

A communications device that enables a computer to simultaneously transmit information over standard telephone lines to multiple computers. Similar to multiple modems contained in one device. See also modem.

multiprotocol routing (MPR)

Enables routing over IP and IPX networks by connecting LANs or by connecting LANs to WANs. MPR refers to both the RIP for Internet Protocol service and the RIP for NWLink IPX/SPX Compatible Transport service.

Multipurpose Internet Mail Extensions (MIME)

A standard mechanism for specifying and describing the format of Internet message bodies. MIME enables the exchanging of objects, different character sets, and multimedia in e-mail on different computer systems. Defined in RFC 1521.

MX record

The MX (mail exchanger) resource record specifies a mail exchange server for a DNS domain name. A mail exchange server is a host (computer or other network device) that will either process or forward mail for the DNS domain name.


N

NCSA

National Center for Supercomputing Applications is a scientific research center that is developing and implementing a national strategy to create, use, and transfer advanced computing and communication tools and information technologies. Developed one of the first Web browsers.

NDS

See NetWare Directory Services.

NetBEUI

A network protocol usually used in small, department-size local area networks of 1 to 200 clients. It can use Token Ring source routing as its only method of routing. See also router.

NetBIOS

See network basic input/output system.

NetWare Directory Services (NDS)

A NetWare service that runs on NetWare servers. The service enables the location of resources on the network.

network basic input/output system (NetBIOS)

An application programming interface (API) that can be used by applications on a local area network. NetBIOS provides applications with a uniform set of commands for requesting the lower-level services required to conduct sessions between nodes on a network and to transmit information back and forth. See also application programming interface.

network card

An expansion card or other device used to connect a computer to a local area network (LAN). Also called a network adapter; network adapter card; adapter card; network interface card (NIC).

network drive

See shared directory.

Network File System (NFS)

A service for distributed computing systems that provides a distributed file system, eliminating the need to keep multiple copies of files on separate computers.

network interface card (NIC)

See network card.

Network News Transfer Protocol (NNTP)

The protocol used to distribute network news messages to NNTP servers and to NNTP clients (news readers) on the Internet. NNTP provides for the distribution, inquiry, retrieval, and posting of news articles by using a reliable stream-based transmission of news on the Internet. NNTP is designed so that news articles are stored on a server in a central database, thus enabling a user to select specific items to read. Indexing, cross-referencing, and expiration of aged messages are also provided. Defined in RFC 977.

network protocols

Software that enables computers to communicate over a network. The Internet protocol is TCP/IP.

NFS

See Network File System.

NIC

See network card.

node

Any workstation, server, printer, or other device on a network that uses TCP/IP. Also called host.

NTFS

See Windows NT File System.

NWLink IPX/SPX Compatible Transport

A standard network protocol that supports routing, and can support NetWare client/server applications, where NetWare-aware sockets-based applications communicate with IPX\SPX sockets-based applications.


O

Open Database Connectivity (ODBC)

ODBC is an application programming interface that enables applications to access data from a variety of existing data sources.


P

packet

A transmission unit of fixed maximum size that consists of binary information representing both data and a header containing an ID number, source and destination addresses, and error-control data.

PDC

See primary domain controller.

Peer Web Services

A collection of services that enable the user of a computer running Windows NT Workstation to publish a personal Web site from the desktop. The services include the WWW service, the FTP service, and the Gopher service.

Perl

Practical Extraction and Report Language. A scripting (programming) language that is frequently used for CGI scripts.

Point-to-Point Protocol (PPP)

A set of industry-standard framing and authentication protocols included with Windows NT Remote Access Service to ensure interoperability with third-party remote access software. PPP negotiates configuration parameters for multiple layers of the OSI (Open Systems Interconnection) model.

Point-to-Point Tunneling Protocol (PPTP)

A new networking technology that supports multiprotocol virtual private networks (VPNs). PPTP enables secure access to private networks across the Internet. With PPTP enabled, remote users can dial into an Internet service provider (ISP), or connect directly to the Internet, and all communication between the user and private network is secure.

Post Office Protocol (POP)

The Post Office Protocol version 3 (POP3) is a protocol that permits a workstation to dynamically access a mail drop on a server in a useful fashion. Usually, this means that a POP3 server is used to allow a workstation to retrieve mail that an SMTP server is holding for it. POP3 is specified in RFC 1725.

POTS

Acronym for Plain-Old Telephone Service. Same as public switched telephone network (PSTN). POTS is also an acronym for point of termination station, which refers to where a telephone call terminates.

primary domain controller (PDC)

In a Windows NT Server domain, the computer running Windows NT Server that authenticates domain logons and maintains the directory database for a domain. The PDC tracks changes made to accounts of all computers on a domain. It is the only computer to receive these changes directly. A domain has only one PDC. See also backup domain controller; domain controller.

PTR record

The pointer (PTR) resource record maps an IP address to a host name in a DNS reverse zone (those in the In-addr.arpa DNS domain).

public key cryptography

A method of encrypting data transmissions to and from a server.


Q

query-by-example (QBE)

A simple-to-use query language implemented on relational database management systems.


R

Remote Access Service (RAS)

A service that can be used by remote clients running Microsoft Dial-Up Networking, all Microsoft RAS clients, or any third-party PPP client to dial in to a network. Remote users with RAS on a Windows NT–based computer can dial in to their networks for services such as Internet access, file and printer sharing, electronic mail, scheduling, and SQL database access.

remote procedure call (RPC)

A message-passing facility that allows a distributed application to call services available on various machines in a network. Used during remote administration of computers.

replicate

See directory replication.

request for comments (RFC)

An official document of the IETF (Internet Engineering Task Force) that specifies the details for protocols included in the TCP/IP family. See also Internet Engineering Task Force.

RIP

See Routing Information Protocol.

router

A network device that manages traffic between networks or subnets. Routers match packet headers to a location on a LAN and choose the best path for the packet, optimizing network performance.

Routing Information Protocol (RIP)

Enables a router to exchange routing information with a neighboring router. See also router.

RPC

See remote procedure call.


S

Schema Wizard

Interactive tool in dbWeb Administrator that leads a user through creation of HTML pages or through implementing an ISAPI application.

schemas

Schemas control how and what information from a private database is available to visitors who use the Internet to access the public Microsoft dbWeb gateway to the private database. See also dbWeb administrator.

Secure Sockets Layer (SSL)

A protocol that supplies secure data communication through data encryption and decryption. SSL enables communications privacy over networks by using a combination of public key cryptography and bulk data encryption.

Serial Line Internet Protocol (SLIP)

An older industry standard that is part of Windows NT Remote Access Service to ensure interoperability with third-party remote access software.

service pack

An update to the Windows NT operating system.

shared directory

A directory that network users can connect to.

Simple Mail Transfer Protocol (SMTP)

A protocol used on TCP/IP networks to exchange mail on the Internet between SMTP servers.

Simple Network Management Protocol (SNMP)

A protocol for monitoring your network. The protocol is used by SNMP consoles and agents to communicate. In Windows NT, the SNMP service is used to get and set status information about a host on a TCP/IP network. See also Management Information Databases.

SLIP

See Serial Line Internet Protocol.

SMTP

See Simple Mail Transfer Protocol.

sniffer

A network device that monitors packets sent over a network.

SNMP

See Simple Network Management Protocol.

socket

A bidirectional pipe for incoming and outgoing data between networked computers. Defined in the University of California at Berkeley Sockets API. See also Windows Sockets.

SQL

See structured query language.

SQL Server

A server typically running on a personal computer that uses the structured query language to query, update, and manage a relational database.

SSL

See Secure Sockets Layer.

static mapping

A method provided on a WINS server to assign a static (unchanging) IP address to a client.

static routing

Static routing limits you to fixed routing tables, as opposed to dynamically updating the routing tables.

structured query language (SQL)

A database query and programming language originally developed by IBM for mainframe computers. It is widely used for accessing data in, querying, updating, and managing relational database systems. See also SQL Server.

subnet mask

A TCP/IP configuration parameter that extracts network and host configuration from an IP address. This 32-bit value enables the recipient of IP packets to distinguish the network ID portion of the IP address from the host ID.

Systems Management Server

A Windows NT Server network server application that remotely manages the personal computers on a network. Systems Management Server detects computers on the network, inventories software and hardware configurations, and installs desktop applications from a central location.


T

T1 or T3 connection

Standard measurements of network bandwidth.

tag file

A configuration file that contains information about a corresponding file on a Gopher server or links to other servers. This information is sent to clients in response to a Gopher request.

TCP/IP

See Transmission Control Protocol/Internet Protocol.

Telnet (VTP)

A terminal emulation protocol for logging on to remote computers. Once referred to as Virtual Terminal Protocol (VTP). Defined in RFC 854, among others. See also Telnet Server.

Telnet Server

A server that runs a Telnet service, enabling remote users to log on and run programs. See also Telnet.

TFTP

See Trivial File Transfer Protocol.

token ring network

A local area network formed in a ring (closed loop) topology that uses token passing as a means of regulating traffic on the line.

transforms

Rules the administrator creates to add, remove, and modify domain names appended to inbound and outbound messages.

Transmission Control Protocol/Internet Protocol (TCP/IP)

A set of networking protocols that provide communications across interconnected networks made up of computers with diverse hardware architectures and various operating systems. TCP/IP includes standards for how computers communicate and conventions for connecting networks and routing traffic.

Trivial File Transfer Protocol (TFTP)

A file transfer protocol that transfers files to and from a remote computer running the TFTP service. TFTP was designed with less functions than FTP. Defined in RFC 1350, among others. See also File Transfer Protocol.


U

UDP

See User Datagram Protocol.

Uniform Resource Locator (URL)

A naming convention that uniquely identifies the location of a computer, directory, or file on the Internet. The URL also specifies the appropriate Internet protocol, such as HTTP, FTP, IRC, or Gopher.

Uninterruptible Power Supply (UPS)

A battery-operated power supply connected to a computer to keep the system running during a power failure.

URL

See Uniform Resource Locator.

User Datagram Protocol (UDP)

A TCP complement that offers a connectionless datagram service that guarantees neither delivery nor correct sequencing of delivered packets (much like IP). See also packet.

UUENCODE (UNIX-to-UNIX Encode)

A utility that converts a binary file (such as a word-processing file or a program) to text so that it can be transmitted over a network. UUDECODE (UNIX-to-UNIX Decode) is the utility used to convert the file back to its original state.


V

virtual directory

An Internet Information Server directory outside the home directory. A virtual directory appears to browsers as a subdirectory of the home directory.

virtual server

A computer with several IP addresses assigned to the network adapter card. This configuration makes the computer look like several servers to a browser.

Virtual Terminal Protocol (VTP)

See Telnet.


W

WAIS

See wide area information server.

WAN

See wide area network.

Web browser

A software program, such as Internet Explorer, that retrieves a document from a Web server, interprets the HTML codes, and displays the document to the user with as much graphical content as the software can supply.

Web page

A World Wide Web document. Pages can contain almost anything, such as news, images, movies, and sounds.

Web server

A computer equipped with the server software to respond to HTTP requests, such as requests from a Web browser. A Web server uses the HTTP protocol to communicate with clients on a TCP/IP network.

Well Known Port Number

The standard port numbers used by the Internet community for well known (commonly used) services. Ports are used in TCP to name the ends of logical connections that carry long-term conversations. Well known services are defined by RFC 1060. The relationship between the well known services and the well known ports is described in RFC 1340.

wide area information server (WAIS)

A network publishing system designed to help users find information over a computer network. WAIS software has four main components: the client, the server, the database, and the protocol. Discussed in RFC 1625.

wide area network (WAN)

A communications network that connects geographically separated areas.

Windows Internet Name Service (WINS)

A name resolution service that runs on Windows NT Server. WINS resolves NetBIOS computer names to IP addresses for WINS clients on a routed network. A WINS server handles name registrations, queries, and releases. See also Domain Name System; IP address; WINS server.

Windows NT File System (NTFS)

A file system used on computers running Windows NT that enables users to set access control permissions on files and directories. NTFS supports file system recovery, extremely large storage media, long filenames, and various features for the POSIX subsystem. It also supports object-oriented applications by treating all files as objects with user-defined and system-defined attributes. See also file allocation table.

Windows NT Server Event Viewer

A program provided with Windows NT that enables users to monitor system, security, and application events by viewing logs generated by Event Viewer.

Windows Sockets

Windows Sockets is a Windows implementation of the widely used UC Berkeley Sockets API. The Windows Sockets API is a networking API used by programmers to create TCP/IP–based sockets applications. Microsoft TCP/IP, NWLink, and AppleTalk® protocols use this interface. Windows Sockets provides interfaces between programs and the transport protocol and works as a bidirectional pipe for incoming and outgoing data. Also called WinSock API. See also application programming interface.

WINS

See Windows Internet Name Service.

WINS server

A computer running Windows NT Server and the WINS service.

World Wide Web (WWW)

The World Wide Web has become synonymous with the Internet. However, the World Wide Web began as a networked information project developed by Tim Berners-Lee at the European Laboratory for Particle Physics (CERN). The World Wide Web is, specifically, the software, protocols, conventions, and information that enable hypertext and multimedia publishing of resources on different computers around the world.


X

X.25 (interface card)

A recommendation published by the Comite Consultatif International de Telegraphique et Telephonique (CCITT) international communications standards organization, X.25 defines the connection between a terminal and a packet-switching network. An X.25 network is a type of packet-switching network that routes units of information (packets) as specified by X.25 and is used in public data communications networks. See also packet.

X.400 system

A messaging system that is compliant with the X.400 standards developed under the Comite Consultatif International de Telegraphique et Telephonique (CCITT) and the International Standards Organization (ISO).

X Windows

A graphical windowing system for UNIX computers.


Z

zone data file

A Domain Name System database for a zone in the DNS name space.


How To Obtain the BackOffice and NT Server 4.0 Resource Kit Utilities CDs

While TechNet includes the full document set for the BackOffice and NT Server 4.0 Resource Kit, the utilities CDs are available separately from your local ordering center or subsidiary. This is due to the size of these utilities. We apologize in advance for any inconvenience this may bring and hope to have these utilities included in our regular editions in the future. In the meantime, TechNet subscribers in North America may order the BackOffice and NT Server Resource Kit Utilities CDs by calling 1-800-344-2121 and asking for the part number(s) shown below. There is a $10.00 (US) shipping and handling charge for each order.

Solution Providers: If you receive TechNet as a benefit of the Microsoft Solution Provider program, please calling 1-800- SOLPROV in the United States or your local subsidiary to order these parts.

If you want this Utilities CD… | Ask for this part number
BackOffice Resource Kit Utilities | 098-67156
MS Windows NT 4.0 Resource Kit Utilities CD | 098-67157

Outside of North America, you may obtain these CDs by calling your local subsidiary or (510) 275-0826 (United States). Local shipping and handling and other charges may apply.


MS Windows NT Server 4.0 Networking Guide

This book is dedicated to creating self-sufficient network administrators!

Contributors to this book include the following:

Technical Editors
Patricia Solon, Sharon Tighe

Copy Editor
J. Elise Ellinghausen

Proofreader
Kimberly O'Neal

Managing Editor
Sonia Marie Moore

Technical Writers
Janet Anderson, Marc Genty, Jeff Howard, Jan Jolan James, Chris Kagen, Richard Lerz, Peter Lovejoy, Laura Sheppard, Maureen Sullivan

Writing Manager
Peggy Etchevers

Production Lead
Nikole Faith

Production Team
Cathy Pfarr, Keri Segna, Jeff Weaver, Todd White

Indexers
Jane Dow, Ronnie Maier, Barbara Sherman

Production Manager
Karye Cattrell

Lead Graphic Designer
Chris Blanton

Design Support Team
Johnni Cutler, Amy Iffland, Casey McGahan, Wendy Salvatori, Gabriel Varela, Sue Wyble, Jan Yeager

Software Program Managers
Louis Kahn, Ryan Marshall

Software Developer
Martin Holladay

Software Tester
Cliff Hudson

Technical Marketing Liaison
Ty Carlson

Technical Consultants
Pradeep Bahl, John Ballard, Denise Y. Deng, Michele Freed, James Gilroy, Cory Hendrix, John Jacobs, Ian Jose, Bin Li, David S. Loudon, Dave Macdonald, Mike Massa, Dan Perry, Rodger Seabourne, Munil Shah, and numerous other hardworking Windows NT Developers, Program Managers, and Product Support Specialists

Product Support Liaisons
Roger Bruist, Todd Hafer

And special thanks to the following people and companies for contributing to the success of the Windows NT Server Resource Kit interoperability lab:

John Allen, Hal Antonson, Howard Bishansky, Bruce Burns, Gregory DeJarnette, Sudheer Dhulipalla, Paul Donnely, Ken Evans, Alex Foskett, Paul Goode, Elise Hammond, Bob Hyman, Doreen Kindred, Richard Lerz, Georgia Marra, Giuseppe Mascarella, Mark Roy, Serge Sozonoff, Prashanth Viswanath, Sam White, Vaughn Winslow, American Power Conversion Corporation (APC); Bay Networks, Inc.; Crystal Computer Services, Inc.; Digital Equipment Corporation; Eicon Technology; Hummingbird Communications, LTD; Intergraph Corporation; Lantronix Corporation; Octopus Technologies, Inc.; Walker Richer & Quinn, Inc.; Wall Data, Inc.

Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation.

© 1995 Microsoft Corporation. All rights reserved.

Microsoft, Microsoft logo, Microsoft Press, Microsoft Press logo, MS, MS-DOS, PowerPoint, Visual Basic, Visual C++, Win32, Windows, Windows logo, and Windows NT are registered trademarks and ActiveX is a trademark of Microsoft Corporation.

Microsoft may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft.

Document No. | xxxx
 | 12345-6

Printed in the United States of America.


Introduction

Welcome to the Microsoft® Windows NT® Server Resource Kit: Windows NT Server Networking Guide.

The Microsoft Windows NT Server Resource Kit for version 4.0 consists of three new volumes and a single compact disc (CD) containing programs for both Windows NT Workstation and Windows NT Server. An online version of the new, comprehensive Windows NT Workstation Resource Guide is also available on the CD. Update books for the Windows NT Server Resource Kit will be released on a semi-annual basis. They will contain new information and major revisions of existing topics.

The Windows NT Server Networking Guide presents detailed information that is specific mainly to using Windows NT Server on or with a network, plus topics that are either new for version 4.0 or reflect issues that our Product Support people consider timely and important. This information is intended to be an in-depth, technical supplement to the printed and online documentation included as part of the Windows NT Server version 4.0 product. It does not replace that information as the source for learning how to use the product features and programs.

This introduction includes the following types of information you can use to get started.

  • The first section outlines the contents of this book, so that you can quickly find pertinent technical details.
  • The second section introduces the Windows NT Server Resource Kit CD.
  • The third section describes the support policy for the Windows NT Server Resource Kit.


About the Windows NT Server Networking Guide

This book includes the following chapters.

Part I, About Windows NT Server Networking

Chapter 1, "Windows NT Networking Architecture," describes the layered networking architecture built into Windows NT, and how it fits into the Open Systems Interconnect (OSI) model. It also describes the Windows NT transfer protocols, distributed processing, the distributed component object model (DCOM), network resource access, workstation and server services, services for Macintosh, and the Remote Access Service (RAS).

Chapter 2, "Network Security and Domain Planning," describes the security model built into Windows NT. It also introduces the security architecture and how the features work over the network domain structure to provide a secure network. The chapter concludes with extensive and detailed advice for planning a domain structure (including a description of the Microsoft corporate domain model), and a section on troubleshooting security problems.

Chapter 3, "Windows NT Browser Service," describes the browser service built into Windows NT. It presents the different types of browser computers, and tells how Windows NT ensures that the browse list (the visual display of all available network devices) is always accessible. The chapter also describes how to select computers to be browsers and how browsing across a wide area network (WAN) is handled.

Part II, Network Interoperability

Chapter 4, "Terra Flora: A Fictitious Case Study," introduces Terra Flora corporation, a fictitious international floral company, and gives background information about the corporation. This corporation will be used to illustrate the ability of heterogeneous networks to operate together using Windows NT Server. The networking model that Terra Flora Corporation will implement, as shown in the network diagram on the inside back cover of this book, contains four levels of server services and provides a brief introduction to the levels and services offered at each level.

Chapter 5, "Network Services: Enterprise Level," presents various decisions Terra Flora had to make about its network and explains the procedures for implementing and configuring those choices. These issues include their network protocol standard, addressing, logons, centralized services, backups, and connecting to the Internet and remote access.

Part III, TCP/IP

Chapter 6, "TCP/IP Implementation Details," provides additional detail about the architecture of Transmission Control Protocol/Internet Protocol (TCP/IP), including information about TCP/IP advanced configuration options and descriptions of the client/server services that make it easier to administer TCP/IP networks.

Chapter 7, "Managing Microsoft DHCP Servers," describes the client/server architecture of the Dynamic Host Configuration Protocol (DHCP) and planning for DHCP server installation, managing the DHCP database, and troubleshooting DHCP service problems.

Chapter 8, "Managing Microsoft WINS Servers," describes the architecture of the Windows Internet Name Service (WINS)¾an RFC-compliant NetBIOS name server for TCP/IP networks, and discusses planning for WINS server implementation.

Chapter 9, "Managing Microsoft DNS Servers," describes the Domain Name System and Microsoft DNS Server, and includes information on the implementation of domain, zone, and Microsoft DNS server and client concepts; planning issues for DNS, WINS, and Internet security; and using DNS Manager to configure and manage Microsoft DNS Server.

Chapter 10, "Using LMHOSTS Files," provides information about the LMHOSTS file that contains static mappings of "friendly" NetBIOS computer names to IP addresses to enable computers to locate resources on the Internet or on routed TCP/IP intranets.

Chapter 11, "Using SNMP for Network Management," describes the Simple Network Management Protocol (SNMP) of the TCP/IP protocol suite and its implementation under Windows NT.

Chapter 12, "Troubleshooting Tools and Strategies," presents information about the TCP/IP programs that are used specifically for connectivity troubleshooting on TCP/IP-based intranets.

Part IV, Using Windows NT Server Networking

Chapter 13, "Using NetBEUI with Windows NT," describes the implementation of the NetBEUI transport under Windows NT for administrators and support personnel who support legacy networks (LANS) using the NetBEUI protocol.

Chapter 14, "Using DLC with Windows NT," provides information about the Data Link Control (DLC) protocol under Windows NT, which provides connectivity to IBM mainframes and to LAN printers attached directly to the network.

Chapter 15, "Remoteboot," explains how a computer running Windows NT Server can start client computers (MS-DOS®, Microsoft Windows® 3.1, and Microsoft Windows 95) over the network.

Chapter 16, "Microsoft Network Client Version 3.0 for MS-DOS," describes how to install, use, and troubleshoot Microsoft Network Client version 3.0 for MS-DOS. Network Client is software that you install on a computer running the MS-DOS operating system so that the computer can use resources on a network.

Part V, Appendixes

Appendix A, "TCP/IP Utilities Reference," provides a listing and description of the TCP/IP programs and commands that are supported by Windows NT for intranet and Internet troubleshooting and connectivity.

Appendix B, "Port Reference for Microsoft TCP/IP," describes the well-known and registered port assignments that are supported by Microsoft TCP/IP for Windows NT.

Appendix C, "MIB Object Types for Windows NT," provides listings of the SNMP managed-objects implemented in Windows NT.

Appendix D, "Windows Sockets," is primarily for the developer. This appendix provides information about using Windows Sockets and developing Windows Sockets programs for Windows NT.

Appendix E, "RAS Reference," provides an overview of the most important modem compatibility standards and how they work within the Remote Access Service (RAS). This appendix also presents a series of quick-reference charts to give you a high-level perspective on how RAS works during a call to a Windows NT RAS server, and reference tables for RAS server and client computers that detail the different versions of RAS and the features they support.

Appendix F, "Routers and Switches," provides an overview of routing and switching technologies, descriptions of the routing and switching equipment selected and installed at Terra Flora, and the technical and business reasons for those choices.

Appendix G, "NetBIOS Names," lists the 16th character of a NetBIOS computer name that uniquely identifies the networking client service, such as workstation or browser. The 16th character is recognized and used in WINS and LMHOSTS name resolution services.

Index to this Windows NT Server Networking Guide.


Resource Kit Compact Disc

The Windows NT Server Resource Kit CD includes a wide variety of tools and programs to help you work more efficiently with both Windows NT Workstation and Windows NT Server. You can read about some of the enhancements made to the existing tools and programs as well as new ones that have been added for this version 4.0 release in the Introduction to the Windows NT Server Resource Guide.

The CD that accompanies the Windows NT Server Resource Kit contains programs that apply to information in the Windows NT Workstation Resource Guide, the Windows NT Server Resource Guide, the Windows NT Server Networking Guide, and the Windows NT Server Internet Guide. This new CD replaces all previous ones. It includes a collection of information resources, tools, and programs that can make networking and working with the Windows NT platform even easier.

Note

The programs on this CD are designed and tested for the U.S. version of Windows NT version 4.0. Use of these programs on any other version of Windows NT can cause unpredictable results.

A large Help file with explanations of and user actions for the majority of the messages included in Windows NT version 4.0, and a large Help file of Performance Counter Definitions are just two of the major items included on the Windows NT Server Resource Kit CD. Updates to these files and others will be provided, when available, on the Microsoft Internet web site for the Windows NT Resource Kits. See the Rktools.hlp file for the exact site address, as well as the addresses of other Microsoft information sites.

After installing the Windows NT Server Resource Kit, please refer first to the following three files:

  • The Readme.wri file, which contains a complete list of all the tools and programs on the Windows NT Server Resource Kit CD and additional setup instructions for some of them.
  • Either the Rkdocw.hlp file (for Windows NT Workstation) or the Rkdocs.hlp file (for Windows NT Server), which provides a single entry point for all of the major components of the Resource Kit's online documentation.
  • The Rktools.hlp file, which provides an overview of the Resource Kit tools and programs and basic instructions on how to use many of them, along with links to additional documentation and, in some cases, to the actual program files.

The most current corrections to those tools and programs and their documentation, as well as the POSIX and Perl source code files, are available on the Internet at the following Microsoft FTP site:

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt40/


Resource Kit Support Policy

The SOFTWARE supplied in the Windows NT Server Resource Kit is not officially supported. Microsoft does not guarantee the performance of the Windows NT Server Resource Kit tools, response times for answering questions, or bug fixes to the tools. However, we do provide a way for customers who purchase the Windows NT Server Resource Kit to report bugs and receive possible fixes for their issues. You can do this either by sending Internet mail to RKINPUT@MICROSOFT.COM or by referring to one of the options listed in the Start Here book, which is included with your Windows NT Server product. This mail address is only for issues related to Windows NT Server Resource Kit.

The SOFTWARE (including instructions for its use and all printed and online documentation) is provided "AS IS" without warranty of any kind. Microsoft further disclaims all implied warranties, including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the SOFTWARE and documentation remains with you.

In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the SOFTWARE be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the SOFTWARE or documentation, even if Microsoft has been advised of the possibility of such damages.


Chapter 1 - Windows NT Networking Architecture

The Microsoft Windows NT operating system was designed and built with fully integrated networking capabilities. These networking capabilities differentiate Windows NT from other operating systems, such as MS-DOS, OS/2, and UNIX, in which network capabilities are installed separately from the core operating system.

This chapter introduces the Windows NT networking architecture. It provides you with descriptions of the following topics.

  • The design goals and rationale for the Windows NT operating system.
  • The basic components of the Windows NT operating system architecture.
  • The basics of networking architecture in general. This includes a detailed description of the model on which Windows NT was designed, as well as the industry standards and specifications.
  • The Windows NT vertical layers and the interfaces for communication between layers.
  • The Windows NT network protocols, which enable layers on two different computers to communicate with each other.
  • Distributed processing of applications across the network and the mechanisms Windows NT uses to create connections between servers and workstations.
  • The mechanisms for sharing resources across the network, including Multiple Universal Naming Convention Provider (MUP) and Multi-Provider Router (MPR).
  • The workstation and server services.
  • How binding options work, enabling communications between network layers.
  • How Remote Access Service (RAS) works to connect remote or mobile clients to corporate networks.
  • How Services for Macintosh are built into Windows NT, allowing Apple Macintosh clients to connect to a Windows NT Server as if it were any other AppleShare server.


Windows NT Operating System Design and Basics

Two primary forces shaped the design of the Windows NT operating system: market requirements and prudent, vigorous design.

Microsoft customers around the world provided the market requirements. Customers wanted the following features.

  • Portability across families of processors, such as the Intel x86 line
  • Portability across different processor architectures, such as complex instruction set computing (CISC), such as the Intel x86 processors, and reduced instruction set computing (RISC), such as MIPS, DEC, and PowerPC
  • Transparent support for single-processor and multiprocessor computers
  • Support for distributed computing
  • Built-in networking
  • Industry standards compliance, such as POSIX
  • Certifiable security, such as C2, Functional C2, and E3

Leading-edge thinkers in operating system theory and design developed the design goals, complementing the market requirements. The following features have been built into the Windows NT design.

  • Extensibility, or modularity of Windows NT. The modular design allows Microsoft to add new modules to all levels of the operating system without compromising its existing stability.
  • Portability, or the ability of Windows NT to run on both CISC and RISC processors.
  • Scalability, or the ability to take full advantage of symmetric multiprocessing hardware.
  • Reliability and robustness, which means that the architecture protects the operating system and its applications from damage. Applications run in their own processes and cannot read or write outside of their own address space. The operating system, in the kernel, is isolated from applications, which interact with the kernel using only well-defined user-mode application programming interfaces (APIs).
  • Performance, or speed of activity. By running its high-performance subsystems in kernel mode where they interact with the hardware and with each other without thread and process transitions, Windows NT 4.0 improves performance, particularly for graphics-intensive applications, such as Microsoft PowerPoint®, by as much as 20 percent.
  • Compatibility, which means that Windows NT 4.0 continues to support MS-DOS, OS/2, Windows 3.x, and POSIX applications, as well as the FAT file system and a wide variety of devices and networks.

Windows NT continues to blend together real-world experience in operating systems with some of the best ideas from the computing industry and academia on operating system theory.


Open Systems and Industry Standards

Open Systems are systems designed to incorporate all devices regardless of manufacturer and accept third party add-on hardware or software products. Industry standards fall into two categories: de jure and de facto.

De jure standards have been created by standards bodies, such as the American National Standards Institute (ANSI), the Institute of Electrical and Electronic Engineers (IEEE), and the International Standards Organization (ISO). For example, the ANSI American Standard Code for Information Interchange (ASCII) character encoding standard, the IEEE Portable Operating System Interface for UNIX (POSIX) standard, and the ISO Open System Interconnection (OSI) reference model for computer networks are all de jure standards.

De facto standards have been widely adopted by industry but are not endorsed by any of the standards bodies. An example of a de facto standard is the Transmission Control Protocol/Internet Protocol (TCP/IP) network communications protocol. De facto standards exist either to fill gaps left by the implementation specifications of the de jure standards or because no standard currently exists for the particular area.

Open systems based solely on de jure industry standards do not yet exist and probably never will because of the very different natures of the computer industry and the academic-standards process. The speed with which the technology changes is staggering, and the formal standards process can't keep pace with it. Various composites of system standards exist because the market demands that solutions be implemented immediately. In today's open systems, both de facto and de jure standards are combined to create interoperable systems. It is the strategic combination of both types of standards that enables open systems to keep pace with rapidly changing technology.

One key element of this middle-of-the-road approach is the use of strategically placed layers of software, to allow the adjoining upper and lower layers of software within the operating system to provide different functions that work together. These software layers provide a standardized set APIs to the software layers above and below themselves. A good example is the Network Device Interface Specification (NDIS), which was jointly developed by Microsoft and 3Com in 1989. Another example is the Desktop Management Interface (DMI) created by the Desktop Management Task Force (DMTF), an industry organization with more than 300 vendor members, including Microsoft, Intel, IBM, and Novell.

The benefit of this architecture is that it allows software modules above and below the layer to be substituted for software modules developed using the same standards. This means you can start out with a module that implements a de facto standard and later supplement or replace it with one that implements a de jure standard. In effect, you end up with the best of both worlds — open systems and industry standards.


Client/Server Computing

The Windows NT operating system is designed for client/server computing. Client/server computing generally means connecting a single-user, general-purpose workstation (client) to multiuser, general-purpose servers, with the processing load shared between both. The client requests services, and the server responds by providing the services.

The Windows NT operating system also extends the client/server model to individual computers. For example, the user runs applications, which are clients that request services from the protected subsystems, which are servers. The idea is to divide the operating system into several discrete processes, each of which implements a set of cohesive services, such as process-creation or memory-allocation. These processes communicate with their clients, with each other, and with the kernel component of the server by passing well-defined messages back and forth.

The client/server approach results in a modular operating system. The servers are small and self-contained. Because each runs in its own protected, user-mode process, a server can fail without taking down the rest of the operating system. The self-contained nature of the operating-system components also makes it possible to distribute them across multiple processors on a single computer (symmetric multiprocessing) or even across multiple computers on a network (distributed computing).


Object-Based Computing

Software objects are a combination of computer instructions and data that models the behavior of things, real or imagined, in the world. Objects are composed of the following elements.

  • Attributes, in the form of program variables, which collectively define the object's state
  • Behavior, in the form of code modules or methods that can modify those attributes
  • An identity that distinguishes one object from all others

Objects interact with each other by passing messages back and forth. The sending object is known as the client and the receiving object is known as the server. The client requests, and the server responds. In the course of conversation, the client and server roles often alternate between objects. Windows NT is not an object-oriented system in the strictest sense, but it does use objects to represent internal system resources.

Windows NT uses an object metaphor that is pervasive throughout the architecture of the system. When viewed using Windows NT, all of the following appear as ordinary objects.

  • Devices, such as printers, tape drives, keyboards, and terminal screens
  • Processes and threads
  • Shared memory segments
  • Access rights


Multitasking and Multiprocessing

Multitasking and multiprocessing are closely related terms that are easily confused. Multitasking is an operating-system technique for sharing a single processor among multiple threads of execution. Multiprocessing refers to computers with more than one processor. A multiprocessing computer can execute multiple threads simultaneously, one thread for each processor in the computer. A multitasking operating system only appears to execute multiple threads at the same time; a multiprocessing operating system actually does so.

Multiprocessing operating systems can be either asymmetric or symmetric. The main difference is in how the processors operate. In asymmetric multiprocessing (ASMP), the operating system typically sets aside one or more processors for its exclusive use. The remainder of the processors run user applications. In symmetric multiprocessing (SMP), any processor can run any type of thread. The processors communicate with each other through shared memory. The Windows NT operating system is an SMP system.

SMP systems provide better load-balancing and fault tolerance. Because the operating system threads can run on any processor, the chance of hitting a CPU bottleneck is greatly reduced. A processor failure in the SMP model will only reduce the computing capacity of the system. In the ASMP model, if the processor that fails is an operating system processor, the whole computer can go down.

SMP systems are inherently more complex than ASMP systems. A tremendous amount of coordination must take place within the operating system to keep everything synchronized. For this reason, SMP systems are usually designed and written from the ground up.


Kernel and User Mode

In modern operating systems, applications are kept separate from the operating system itself. The operating-system code runs in a privileged processor mode known as the kernel, and has access to system data and hardware. Applications run in a nonprivileged processor mode known as user mode, and have limited access to system data and hardware through a set of tightly controlled APIs.

One of the design goals of the Windows NT operating system was to keep the base operating system as small and efficient as possible. This was accomplished by allowing only those functions that could not reasonably be performed elsewhere to remain in the base operating system. The functionality that was pushed out of the kernel ended up in a set of nonprivileged servers known as the protected subsystems. The protected subsystems provide the traditional, operating-system support to applications through a feature-rich set of APIs.

This design results in a very stable base operating system. Enhancements occur at the protected subsystem level. New protected subsystems can even be added without modification to either the base operating system or the other existing protected subsystems.

Executive

The executive is the kernel-mode portion of the Windows NT operating system and, except for a user interface, is a complete operating system unto itself. The executive is never modified or recompiled by the system administrator.

Figure 1.1 Windows NT operating system architecture

The executive is actually a family of software components that provide basic operating-system services to the protected subsystems and to each other. The executive components are listed below.

  • I/O Manager
  • Object Manager
  • Security Reference Monitor
  • Process Manager
  • Local Procedure Call Facility
  • Virtual Memory Manager
  • Window Manager
  • Graphics Device Interface
  • Graphics Device Drivers

The executive components are completely independent of one another and communicate through carefully controlled interfaces. This modular design allows existing executive components to be removed and replaced with ones that implement new technologies or features. As long as the integrity of the existing interface is maintained, the operating system runs as before. The top layer of the executive is called the System Services, which are the interfaces between user-mode protected subsystems and kernel mode. For details on the executive and its components, see Chapter 1, "Windows NT Architecture," in the Microsoft Windows NT Workstation 4.0 Online Resource Guide.

Protected Subsystems

The protected subsystems are user-mode servers that are started when Windows NT is started. There are two types of protected subsystems: integral and environment. An integral subsystem is a server that performs an important operating system function, such as security. An environment subsystem is a server that provides support to applications written for or native to different operating system environments, such as OS/2.

Windows NT currently ships with three environment subsystems: the Win32® subsystem, the POSIX subsystem, and the OS/2 subsystem.

The Win32 (or 32-bit Windows) subsystem is the native subsystem of Windows NT. It provides the most capabilities and efficiencies to its applications and is the subsystem of choice for new software development. The POSIX and OS/2 subsystems provide compatibility environments for their respective applications and are not as feature-rich as the Win32 subsystem.


Basic Concepts of Network Architecture

Networking software must perform a wide range of functions to enable communications among computers. Some of these functions are listed below.

  • Device and I/O redirection
  • Process address registration
  • Interprocess connection
  • Password encryption and decryption
  • Message segmentation and desegmentation
  • Frame routing between networks
  • Frame delimiting and media-access arbitration
  • Pulse encoding of bits

To reduce the design complexity of a network, these functions are organized into groups, which are then allocated to a series of layers. The purpose of each layer is to offer services to the other layers, shielding the layers from the details of how the offered services are actually implemented. The services provided by a particular layer are a product of the network functions allocated to that layer and are usually built upon services offered by other layers. The design of the set of layers and of how they function with each other constitutes a network architecture.

Figure 1.2 Layered design of network services


Communication Between Layers

Communication between layers within a computer is handled differently from communication between two computers. The layers within a computer communicate with each other using vertical interfaces. The layers on different computers communicate with their counterparts using protocols.

Peer Relationships—Protocols

Peer-to-peer communications are performed using protocols. For example, layer 4 on one computer carries on a conversation with layer 4 on another computer. The rules and conventions used in this conversation are collectively known as the layer-4 protocol. The communication between the layers is considered peer-to-peer communication. Functions performed in layer 4 of one computer are communicated to layer 4 of another computer.

Vertical Relationships—Interfaces

Each layer ultimately communicates with its peer on the other computer. However, no data passes directly from layer 4 on one computer to layer 4 on another. Instead, each layer passes data and control information to the layer immediately below it, until the lowest layer is reached and the data is transmitted onto the network media. The receiving computer then passes the data and control information from layer to layer until it reaches its own layer 4.

There is a well-defined interface between each pair of layers. The interface defines which services the lower layer offers to the upper one and how those services will be accessed.


Transmitting and Receiving Data Across a Network

When two computers transmit data over the network, one is a transmitting or sending computer and one is a receiving computer. Data is passed in frames, which are messages broken into smaller units with transport headers attached. To understand how frames are transferred through a network, we need to look at both ends of the transfer process: transmitting and receiving.

Transmitting

Data frames are formed whenever the sending computer initiates a request for communication. Frame formation begins at the highest layer and continues down through each successive layer. The protocol at each layer adds control information (in the form of headers and trailers) to the data that was passed down from the layer above. The frame is then passed to the layer below according to the definition of the interface. Eventually, the data passes through all layers of the protocol stack and is transmitted onto the network media.

Receiving

At the receiving end, the frame is passed from the lower layers to the higher layers in accordance with the definition of the interfaces. The protocol at each layer interprets only the information contained in the headers and trailers that were placed there by its peer on the transmitting end. The protocol considers the rest of the frame to be the data unit, which it is responsible for delivering to the layer above it.


The Open Systems Interconnect Model

In the early years of networking, sending and receiving data across a network was confusing because large companies, such as IBM, Honeywell, and Digital Equipment Corporation had individual standards for connecting computers. The transmit and receive processes had to "talk" to the same protocols to communicate. It was unlikely that applications operating on different equipment from different vendors would be able to communicate. Vendors, users, and standards bodies needed to agree upon and implement a standard architecture that would allow computer systems to exchange information even though they were using software and equipment from different vendors.

In 1978, the International Standards Organization (ISO) introduced a model for Open Systems Interconnect (OSI) as a first step toward international standardization of the various protocols required for network communication. This ISO OSI model incorporates the following qualities.

  • It is designed to establish data-communications standards that promote multivendor interoperability.
  • It consists of seven layers, with a specific set of network functions allocated to each layer and guidelines for implementation of the interfaces between layers.
  • It specifies the set of protocols and interfaces to implement at each layer.

OSI Layers

Each layer of the OSI model exists as an independent module. In theory, you can substitute one protocol for another at any given layer without affecting the operation of layers above or below, although you probably wouldn't want to do so.

The principles used to create the seven-layer model are listed below.

  • A layer should be created only when a different level of abstraction is required.
  • Each layer should perform a well-defined function.
  • The function of each layer should be chosen with the goal of defining internationally standardized protocols.
  • The layer boundaries should be chosen to minimize the information flow across the interfaces.
  • The number of layers should be large enough to enable distinct functions to be separated, but few enough to keep the architecture from becoming unwieldy.

The following diagram shows the numbering of the layers, beginning with the physical layer, which is closest to the network media.

Figure 1.3 Layers of the OSI model

Physical Layer

The physical layer is the lowest layer of the OSI model. This layer controls the way unstructured, raw, bit-stream data is sent and received over a physical medium. This layer describes the electrical or optical, mechanical, and functional interfaces to the physical network medium. The physical layer carries the signals for all of the higher layers.

Data-encoding modifies the simple, digital-signal pattern (1s and 0s) used by the computer to better accommodate the characteristics of the physical medium and to assist in bit and frame synchronization.

Data encoding resolves the following issues.

  • Which signal pattern represents a binary 1
  • How the receiving station recognizes when a "bit-time" starts
  • How the receiving station delimits a frame

Physical medium attachment resolves the following issues.

  • Whether an external transceiver will be used to connect to the medium
  • How many pins the connectors have and what each pin is used for

The transmission technique determines whether the encoded bits will be transmitted by means of baseband (digital signaling or broadband (analog) signaling.

Physical-medium transmission determines whether it is appropriate to transmit bits as electrical or optical signals, based on the following criteria.

  • Which physical-medium options can be used
  • How many volts should be used to represent a given signal state in the specific physical medium
Data-link Layer

The data-link layer provides error-free transfer of data frames from one computer to another over the physical layer. The layers above this layer can assume virtually error-free transmission over the network.

The data-link layer provides the following functions.

  • Establishing and terminating alogical link (virtual-circuit connection) between two computers identified by their unique network interface card (NIC) addresses
  • Controlling frame flow by instructing the transmitting computer not to transmit frame buffers
  • Sequentially transmitting and receiving frames
  • Providing and expecting frame-acknowledgment, and detecting and recovering from errors that occur in the physical layer by retransmitting non-acknowledged frames and handling duplicate frame receipts
  • Managing media access to determine when the computer is permitted to use the physical medium
  • Delimiting frames to create and recognize frame boundaries
  • Error-checking frames to confirm the integrity of the received frame
  • Inspecting the destination address of each received frame and determining if the frame should be directed to the layer above
Network Layer

The network layer controls the operation of the subnet. It determines which physical path the data takes, based on the network conditions, the priority of service, and other factors.

The network layer provides the following functions.

  • Transferring the frameto a router if the network address of the destination does not indicate the network to which the station is attached
  • Controlling subnet traffic to allow an intermediate system to instruct a sending station not to transmit its frame when the router's buffer fills up. If the router is busy, the network layer can instruct the sending station to use an alternate router
  • Allowing the router to fragment a frame when a downstream router's maximum transmission unit (MTU) size is less than the frame size. The frame fragments will be reassembled by the destination station
  • Resolving the logical computer address (at the network layer) with the physical network-interface-card (NIC) address (at the data-link layer), if necessary
  • Keeping an accounting record of frames forwarded by subnet intermediate system to produce billing information

The network layer at the transmitting computer must build its header in such a way that the network layers residing in the subnet's intermediate systems can recognize the header and use it to route the data to the destination address.

This layer eliminates the need for higher layers to know anything about the data transmission or intermediate switching technologies used to connect systems. The network layer is responsible for establishing, maintaining, and terminating the connection to one or to several intermediate systems in the communication subnet.

In the network layer and the layers below it, the peer protocols are between each computer and its immediate neighbor, which is often not the ultimate destination computer. The source and destination computers may be separated by many intermediate systems.

Transport Layer

The transport layer makes sure that messages are delivered in the order in which they were sent and that there is no loss or duplication. It removes the concern from the higher layer protocols about data transfer between the higher layer and its peers.

The size and complexity of a transport protocol depend on the type of service it can get from the network layer or data link layer. For a reliable network layer or data-link layer with virtual-circuit capability, such as NetBEUI's LLC layer, a minimal transport layer is required. If the network layer or data-link layer is unreliable or supports only datagrams (as TCP/IP's IP layer and NWLink's IPX layer do), the transport layer should include frame sequencing and acknowledgment, and associated error-detection and recovery.

Functions of the transport layer include the following tasks.

  • Accepting messages from the layer above and, if necessary, splitting them into frames
  • Providing reliable, end-to-end message delivery with acknowledgments
  • Instructing the transmitting computer not to transmit when no receive buffers are available
  • Multiplexing several process-to-process message streams or sessions onto one logical link and keeping track of which messages belong to which sessions

The transport layer can accept large messages, but there are strict size limits imposed by the layers at the network level and lower. Consequently, the transport layer must break up the messages into smaller units, called frames, and attach a header to each frame.

If the lower layers do not maintain sequence, the transport header (TH) must contain sequence information, which enables the transport layer on the receiving end to present data in the correct sequence to the next higher layer.

Unlike the lower subnet layers, whose protocols are between immediately adjacent nodes or computers, the transport layer and the layers above it are true source-to-destination layers. They are not concerned with the details of the underlying communications facility. Software for layers on the source computer at the transport level and above carries on a conversation with similar software on the destination computer, using message headers and control messages.

Session Layer

The session layer establishes a communications session between processes running on different computers, and can support message-mode data transfer.

Functions of the session layer include:

  • Allowing application processes to register unique process addresses, such as NetBIOS names. It provides the means by which these process addresses can be resolved to the network-layer or data-link-layer NIC addresses, if necessary.
  • Establishing, monitoring, and terminating a virtual-circuit session between two processes identified by their unique process addresses. A virtual-circuit session is a direct link that seems to exist between the sender and receiver: In reality, the connection is established through circuits.
  • Delimiting messages, to add header information that indicates where a message starts and ends. The receiving session layer can then refrain from indicating any message data to the overlying application until the entire message has been received.
  • Informing the receiving application when buffer space is insufficient for the entire message and that the message is incomplete (called message synchronization). The receiving session layer may also use a control frame to inform the sending session layer how many bytes of the message have been successfully received. The sending session layer can then resume sending data at the byte following the last byte acknowledged as received. When the application subsequently provides another buffer, the session layer can place the remainder of the message in that buffer and indicate to the application that the entire message has been received.
  • Performing other support functions that allow processes to communicate over the network, such as user authentication and resource-access security.
Presentation Layer

The presentation layer serves as the data translator for the network. This layer on the sending computer translates data from the format sent by the application layer into a common format. At the receiving computer, the presentation layer translates the common format to a format known to the application layer.

The presentation layer provides the following functions.

  • Character-code translation, such as from ASCII to EBCDIC
  • Data conversion, such as bit order, CR-to-CR/LF, and integer-to-floating point
  • Data compression, which reduces the number of bits that need to be transmitted
  • Data encryption, which renders data unreadable until it has been unencrypted, for security purposes. An example is password encryption
Application Layer

The application layer serves as the window for users and application processes to access network services. The application layer provides the following functions.

  • Resource sharing and device redirection
  • Remote file access
  • Remote printer access
  • Interprocess communication support
  • Remote procedure call support
  • Network management
  • Directory services
  • Electronic messaging, including e-mail messaging
  • Simulation of virtual terminals

Data Flow in the OSI Model

The OSI model presents a standard data flow architecture, with protocols specified in such a way that layer n at the destination computer receives exactly the same object as was sent by layer n at the source computer.

Figure 1.4 OSI model data flow

The sending process passes data to the application layer, which attaches an application header (AH) and then passes the frame to the presentation layer.

The presentation layer can transform data in various ways, if necessary, such as by translating it and adding a header. It then gives the result to the session layer. The presentation layer is not "aware" of which portion (if any) of the data received from the application layer is AH and which portion is actually user data, because that information is irrelevant to the presentation layer's role.

The process is repeated from layer to layer until the frame reaches the data-link layer. There, in addition to a header, a data trailer (DT) is added to aid in frame synchronization. The frame is then passed down to the physical layer, where it is actually transmitted to the receiving computer.

On the receiving computer, the various headers and the DT are stripped off one by one as the frame ascends the layers and finally reaches the receiving process.

Although the actual data transmission is vertical, each layer is programmed as if the transmission were horizontal. For example, when a sending transport layer gets a message from the session layer, it attaches a transport header (TH) and sends it to the receiving transport layer. The fact that the message actually passes to the network layer on its own machine is unimportant.

Vertical Interface Terminology in the OSI Model

In addition to defining the ideal seven-layer architecture and the network functions allocated to each layer, the OSI model also defines a standard set of rules and associated terms that govern the interfaces between layers.

The active protocol elements in each layer are called entitie s, which are typically implemented by means of a software process. For example, the TCP/IP protocol suite contains two entities within its transport layer: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Entities in the same layer on different computers are called peer entities.

The layer directly below layer-n entities implements services that will be used by layer n.

For data transfer services, OSI defines the terminology for the discrete data components passed across the interface and between peer entities, as described in the following example.

  • The layer-n entity passes an interface data unit (IDU) to the layer-n–1 entity.
  • The IDU consists of a protocol data unit (PDU) and some interface control information (ICI).
  • The PDU is the data that the layer-n entity wishes to pass across the network to its peer entity. It consists of the layer-n header and the data that layer n received from layer n+1.
  • The layer-n PDU becomes the layer n–1 service data unit (SDU), because it is the data unit that will be serviced by layer n.
  • The ICI is made up of control information, such as the length of the SDU, and the addressing information that the layer below needs to do its job.
  • When layer n–1 receives the layer-n IDU, it strips off and "considers" the ICI, adds the header information for its peer entity across the network, adds ICI for the layer below, and passes the resulting IDU to the layer n–2 entity.

Figure 1.5 Vertical interface entities

Problems can occur in the data-flow path between two network stations. These problems can include errant, restricted, or even halted communication. Vertical and peer-trace utilities can be developed by third-party vendors to trace network communication errors.

Vertical Interface Trace Utilities

Layer entities within a computer can call layer entities above and below them by means of established interface-call mechanisms (such as an interrupt in MS-DOS or, in Windows NT, an API-function call or IRP submission)and then pass a defined IDU structure. These call mechanisms provide the means to write a trace utility, which can do the following items.

  • Capture the interface-call-mechanism entry point, saving the original entry point.
  • Gain control when the entry point is called.
  • Examine the structure being passed, "snapshot" all or part of the IDU structure, and then write the snapshot to a buffer or log file.
  • Pass control to the original entry point.

If the data-flow problem is due to a layer entity's passing incorrect or incorrectly formatted ICI information, an examination of the log generated by the interface trace utility should reveal the cause of the problem. Vertical-interface trace utilities that can be used to troubleshoot networking include the NBTRAP (NetBIOS interface trace) utility for MS-DOS and the TDITRACE (Transport Driver Interface interface trace) utility for Windows NT, among others.

Peer-protocol Trace Utilities

A specially configured computer can connect to the physical medium to receive and examine all frames sent to and from specified network addresses. The user can set the computer software to display frame-header information at any functional layer. The user can then view peer-protocol conversations between selected computers. If the data-flow problem is due to an error in the peer protocol, the user can detect it by examining the trace. Peer-protocol trace utilities include Sniffer from Network General and Microsoft Network Monitor, among others.

Figure 1.6 Troubleshooting, using a Data Flow Trace

IEEE Standard 802 for Low-level Protocols

Recognizing a need for standards in the local area network (LAN) market, the IEEE undertook Project 802. Named for the year (1980) and month (February) of its inception, Project 802 defines a family of low-level protocol standards at the physical and data-link layers of the OSI model.

Under the terms of IEEE 802, the OSI data-link layer is further divided into two sublayers: Logical Link Control (LLC) and Media Access Control (MAC).

Figure 1.7 Comparison of IEEE layers and the OSI model

Data-link-layer functions allocated to the LLC sublayer include the following.

  • Establishing and terminating links
  • Controlling frame traffic
  • Sequencing frames
  • Acknowledging frames

Data-link-layer functions allocated to the MAC sublayer include the following items.

  • Managing media access
  • Delimiting frames
  • Checking frame errors
  • Recognizing frame addresses

Project 802 specifications include the following categories.

  • 802.1 Overview of project 802, including higher layers and internetworking
  • 802.2 Logical Link Control (LLC)
  • 802.3 Carrier Sense Multiple Access with Collision Detect (CSMA/CD)
  • 802.4 Token Bus
  • 802.5 Token Ring
  • 802.6 Metropolitan Area Network
  • 802.7 Broadband Technology Advisory Group
  • 802.8 Optical Fiber Technology Advisory Group
  • 802.9 Voice/Data Integration on LANs
  • 802.10 Standard for Interoperable LAN Security

The low-level protocol specifications 802.3 CSMA/CD, 802.4 Token Bus, and 802.5 Token Ring differ at the physical layer and MAC sublayer, but are compatible at the LLC sublayer.

The 802 standards have been adopted by the following standards bodies.

  • ANSI, as American National Standards
  • National Bureau of Standards (NBS), as government standards
  • ISO, as international standards (known as ISO 8802)

ANSI FDDI Specification

Closely related to the IEEE 802 standards is a more recently developed low-level protocol standard, Fiber Distributed Data Interchange (FDDI). FDDI was developed by ANSI and is based on the use of fiber-optic cable.

FDDI differs from the IEEE 802 standards at the physical layer and MAC sublayer, but is compatible with the IEEE standards at the LLC sublayer.

Data-transfer Services

Protocol entities within a network architecture provide various types of data-transfer services from a layer to the layers above it. The most prevalent data-transfer services are called reliable connection and unreliable connectionless.

A connection service requires a virtual circuit or connection to be established from the source computer to a single destination computer before any data transfer can take place. A connection acts like a tube: The sender pushes objects in at one end, and the receiver takes them out at the other end, in proper sequence. Because sequencing is provided, a message that is larger than the maximum transmit-frame size can be broken down into multiple frames, sent across the network, and re-sequenced at the receiving computer.

A connectionless service requires no initial connection and offers no guarantee that the data units will arrive in sequence. No connection is required, so messages can be sent to one or multiple destination stations. No sequencing is provided, so messages can be sent only in single-frame size.

A reliable service never loses data because the receiver acknowledges receipt of all data sent. If the sender doesn't receive acknowledgment, it re-sends.

With an unreliable service, no acknowledgments are sent, so there is no guarantee that data sent was ever received.

Microsoft network products require that the underlying network drivers provide both reliable-connection and unreliable-connectionless data-transfer services.

Microsoft network products use unreliable-connectionless data transfer only when there is a need to send data simultaneously to many stations. Often, unreliable-connectionless data transfer is used to locate the name of a computer. Once the computer name is received, reliable-connection data transfer is used to connect to the computer and complete the desired transaction. For example, an unreliable-connectionless data transfer may be sent to all computers in a domain (such as net send /d:<domain name> "hello") to find the name of a server that provides a particular service.

Data-transfer Modes

Different protocol entities offer different modes by which data can be transferred across the network from one process to another. As indicated in Table 1.1, some protocols, such as the NetBEUI NBFP, support more than one data-transfer mode.

Table 1.1 Data-transfer Mode Definitions and Protocols

Data-transfer mode | Mode type | Definition | Protocol
Reliable connection | Message mode | Message delimination and synchronization | NetBEUI NBFP, TCP/IP NetBT, NWLink NBIPX
 | Byte-stream mode | Byte granular data sequencing and acknowledgment | TCP/IP TCP
 | Packetstream mode | Packet granular data sequencing and acknowledgment | NetBEUI, LLC, MSDLC, NWLink SPX
Unreliable connectionless | Datagram mode |  | NetBEUI NBFP and LLC;MSDLC, TCP/IP UDP and IP; NWLink IPX

The following sections discuss the attributes of various data-transfer modes.

Reliable Connection Message Mode

When the sending client submits a larger-than-packet-size message to be sent, the sending protocol entity breaks the message into frame-sized segments. These include message-delimiter information in the protocol header, which identifies where the client submitted message starts and ends. This process allows the receiving-protocol driver to receive the entire client message before indicating the data to the receiving client.

If the receiving-client buffer fills up before the receiving-station protocol entity has received the entire message, it will still provide the partial message to the receiving client. It will also indicate that the data provided is a partial message and that the receiving client must supply another buffer to receive the remaining portion of the message.

When the receiving-protocol entity has received the entire message, it returns a message to the sending-protocol entity, acknowledging receipt of the entire message.

Reliable Connection Byte-stream Mode

When the sending client submits a larger-than-packet-size message, the sending-protocol-driver entity breaks the message into segments but does not include message-delimiter information in the protocol header. The receiving-station-protocol entity provides the data to the receiving client when the receiving client provides the buffers to receive it, without any regard to the original message size.

When the receiving-protocol entity provides the data to the receiving client, it returns a byte acknowledgment to the sending-protocol entity, acknowledging receipt of all data up to a specified byte. The sending client can then begin sending the message at the last byte acknowledged.

Reliable Connection Packetstream Mode

In this mode, the sending client can submit only packet-size messages. The receiving protocol provides the packet-by-packet data in sequence to the receiving client.

While the receiving protocol entity provides a frame of data to the receiving client, it returns a message to the sending protocol entity, acknowledging receipt of all packets up to the specified packet number.

Note

The Windows Sockets emulator emulates message-mode data transfer over the NWLink SPX packet stream. The Sockets emulator component will break large messages into packets and place message delimiters in the packet stream. The receiving Sockets emulator will not provide the received data to the receiving Sockets client until the entire message has been received.

Unreliable Connectionless Datagram Mode

The sending client can submit only packet-size messages to be sent. If the data unit received is larger than the receiving client's next receive buffer, then as much of the received data unit as will fit is placed in the receiving client's buffer and provided to the client. The portion of the received data unit that could not fit in the client buffer is simply lost; no associated error is returned to the receiving client. If the data unit received is smaller than the client buffer, the protocol entity will place the received data unit in the client buffer and immediately provide the message, without waiting for more data to be received.

No acknowledgment is returned to the sending-protocol entity.

The following diagram illustrates the data transfer process: 'S' (on the right side of the diagram) indicates a SUCCESS return status code on the receive. 'E' indicates an error status on the receive: ERROR_MORE_DATA on message mode data transfer.

Figure 1.8 Data-transfer modes


The Windows NT Layered Network Architecture

A significant difference between the Windows NT operating system and other operating systems is that the networking capabilities were built into the system from the ground up. With MS-DOS, Windows 3.x, and OS/2, networking was added to the operating system.

By providing both client and server capabilities, a computer running Windows NT Server or Windows NT Workstation can be either a client or server in either a distributed-application environment or a peer-to-peer networking environment.

The following illustration shows the specific way Windows NT implements the OSI model.

Figure 1.9 Windows NT layered network architecture

To understand the Windows NT operating system capabilities, it is important to understand the network architecture. The networking architecture with its layered organization provides expandability by allowing other functions and services to be added.

The rest of the chapter is devoted to an explanation of the concepts and features of the Windows NT layered networking architecture, including the following topics.

  • Boundary layers
  • Network protocols
  • Streams
  • Distributed processing
  • Distributed component object model
  • Network resource access
  • Workstation service
  • Server service
  • Binding options
  • Remote Access Service
  • Services for Macintosh


Boundary Layers

A boundary is the unified interface between the functional layers in the Windows NT network architecture model. Creating boundaries as breakpoints in the network layers helps open the system to outside development, making it easier for outside vendors to develop network drivers and services. Because the functionality that must be implemented between the layers is well defined, developers need to program only between the boundary layers instead of going from the top to the bottom. Boundary layers also enable software developed above and below a level to be integrated without rewriting.

There are two significant boundary layers in the Windows NT operating system network architecture: the Network Driver Interface Specification (NDIS) 3.0 boundary layer and TDI boundary layer.

The NDIS 3.0 boundary layer provides the interface to the NDIS wrapper and device drivers.

Figure 1.10 Windows NT boundary layers

Transport Driver Interface

TDI is a common interface for a driver (such as the Windows NT redirector and server) to communicate with the various network transports. This allows redirectors and servers to remain independent of transports. Unlike NDIS, there is no driver for TDI; it is simply a standard for passing messages between two layers in the network architecture.

Network Driver Interface Specification 3.0

In 1989, Microsoft and 3Com jointly developed a specification defining an interface for communication between the MAC sublayer and protocol drivers higher in the OSI model. Network Driver Interface Specification (NDIS) is a standard that allows multiple network adapters and multiple protocols to coexist. NDIS permits the high-level protocol components to be independent of the network interface card by providing a standard interface. The network interface card driver is at the bottom of the network architecture. Because the Windows NT network architecture supports NDIS 3.0, it requires that network adapter-card drivers be written to the NDIS 3.0 specification. NDIS 3.0 allows an unlimited number of network adapter cards in a computer and an unlimited number of protocols that can be bound to a single adapter card.

In Windows NT, NDIS has been implemented in a module called Ndis.sys, which is referred to as the NDIS wrapper.

The NDIS wrapper is a small piece of code surrounding all of the NDIS device drivers. The wrapper provides a uniform interface between protocol drivers and NDIS device drivers, and contains supporting routines that making it easier to develop an NDIS driver.

Figure 1.11 NDIS Wrapper

Previous implementations of NDIS required a protocol manager (PROTMAN) to control access to the network adapter. The primary function of PROTMAN was to control the settings on the network adapter and the bindings to specific protocol stacks. The Windows NT operating system networking architecture does not need a PROTMAN module because adapter settings and bindings are stored in the registry and configured using Control Panel.

Because the NDIS wrapper controls the way protocols communicate with the network adapter card, the protocols communicate with the NDIS wrapper rather than with the network adapter card itself. This is an example of the modularity of the layered model. The network adapter card is independent from the protocols; therefore, a change in protocols does not require changing settings for the network adapter card.


Network Protocols

The Windows NT operating system ships with four network protocols:

  • Data Link Control (DLC)
  • NetBEUI
  • TCP/IP
  • NWLink (IPX/SPX)

Figure 1.12 Windows NT network protocols

Data Link Control

Unlike the other protocols, the Data Link Control (DLC) protocol is not designed to be a primary protocol for network use between personal computers. DLC provides applications with direct access to the data-link layer but is not used by the Windows NT operating system redirector. Since the redirector cannot use DLC, this protocol is not used for normal-session communication between computers running Windows NT Server or Windows NT Workstation.

The DLC protocol is primarily used for two tasks.

  • Accessing IBM mainframes, which usually run 3270 applications.
  • Printing to Hewlett-Packard printers connected directly to the network.

Network-attached printers, such as the HP III, use the DLC protocol because the received frames are easy to take apart and because DLC functionality can easily be coded into read-only memory (ROM).

DLC needs to be installed only on those network machines that perform these two tasks, such as a print server sending data to a network HP printer. Client computers sending print jobs to the network printer do not need the DLC protocol; only the print server communicating directly with the printer needs the DLC protocol installed.

The registry location for the DLC parameters is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DLC

The registry entry for the DLC driver indicates that it is loaded after the kernel has been started (Start 0x1), and it is dependent on having an NDIS group service available. Its linkage shows that it is bound to the network adapter by the appropriate NDIS device driver.

NetBIOS Extended User Interface

IBM introduced NetBIOS Extended User Interface (NetBEUI) in 1985. NetBEUI was developed for small departmental LANs of 20 to 200 computers. It was assumed that these LANs would be connected by gateways to other LAN segments and mainframes.

NetBEUI version 3.0 is included with Windows NT Server and Windows NT Workstation. It features the following advantages.

  • Provides a fast protocol on small LANs
  • Breaks the 254-session barrier of previous versions of NetBEUI
  • Provides much better performance over slow links than previous versions of NetBEUI
  • Is completely self-tuning and has good error protection
  • Uses a small amount of memory
  • Does not require configuring

NetBEUI has two disadvantages.

  • NetBEUI is not routable.
  • NetBEUI performance across WANs is poor.

The registry location for the NetBEUI parameters is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NBF

The NetBEUI registry entry looks like the DLC entry. Like the DLC driver, NetBEUI is dependent on having an available NDIS group service. Also, under the linkage key, NetBEUI is bound to the network adapter entry by way of the NDIS device driver entry.

Strictly speaking, NetBEUI 3.0 is not truly NetBEUI because it is not inherently extending the NetBIOS interface. Instead, its upper-level interface conforms to the TDI. However, NetBEUI 3.0 still uses the NetBIOS Frame Format (NBF) protocol and is completely compatible and interoperable with previous versions of NetBEUI.

Network applications speaking directly to the NetBEUI 3.0 protocol driver now must use TDI commands instead of NetBIOS commands. This is a departure from earlier implementations of NetBEUI on MS-DOS and OS/2, which provided the programming interface as part of the transport's device driver. There is nothing wrong with this, but in the Windows NT operating system implementation, the programming interface (NetBIOS) has been separated from the protocol (NetBEUI) to increase flexibility in the layered architecture. Two points summarize the difference between these two.

  • NetBEUI is a protocol.
  • NetBIOS is a programming interface.

Transmission Control Protocol/Internet Protocol

TCP/IP is an industry-standard suite of protocols designed for WANs. It was developed in 1969, resulting from a Defense Advanced Research Projects Agency (DARPA) research project on network interconnection.

DARPA developed TCP/IP to connect its research networks. This combination of networks continued to grow and now includes many government agencies, universities, and corporations. This global WAN is called the Internet.

The Windows NT TCP/IP allows users to connect to the Internet and to any machine running TCP/IP and providing TCP/IP services.

Some of the advantages of TCP/IP protocol are that it provides the following functions.

  • Providing connectivity across operating systems and hardware platforms
  • Providing access to the Internet
  • Providing a routable protocol
  • Supporting Simple Network Management Protocol (SNMP)
  • Supporting Dynamic Host Configuration Protocol (DHCP), which provides dynamic IP-address assignments
  • Supporting Windows Internet Name Service (WINS), which provides a dynamic database of IP address-to-NetBIOS name-resolution mappings

The registry location for TCP/IP parameters is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip

NWLink (IPX/SPX)

NWLink is an IPX/SPX-compatible protocol for the Windows NT network architecture. It can be used to establish connections between computers running Windows NT Server or Windows NT Workstation and MS-DOS, OS/2, and Microsoft Windows through a variety of communication mechanisms.

NWLink is simply a protocol. By itself, it does not allow a computer running Windows NT Server or Windows NT Workstation to access files or printers shared on a NetWare server, or to act as a file or print server to a NetWare client. To access files or printers on a NetWare server, a redirector must be used, such as the Client Service for NetWare (CSNW) on Windows NT Workstation or the Gateway Service for NetWare (GSNW) on Windows NT Server.

NWLink is useful if there are NetWare client/server applications running that use Sockets or NetBIOS over the IPX/SPX protocol. The client portion can be run on a Windows NT Server or Windows NT Workstation system to access the server portion on a NetWare server, and vice versa.

NWNBLink contains Microsoft enhancements to Novell NetBIOS. The NWNBLink component is used to format NetBIOS-level requests and pass them to the NWLink component for transmission on the network.

The registry location for NWLink parameters is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NWLINK


Streams

Streams are multiple data channels that allow broader bandwidth for data transfer. There are two reasons for writing a protocol to use the Streams device driver.

  • Streams makes it easier to port existing protocols to the Windows NT operating system.
  • Streams encourages protocols to be organized in a modular, stackable style, thus moving closer to the original vision of the OSI model.

Figure 1.13 Windows NT 3.1 Streams

In Windows NT version 3.1, both TCP/IP and NWLink were surrounded by a Streams device driver. Calls to the TCP/IP or NWLink protocol first passed through the upper layer of the Streams device driver, and then to the NDIS device driver by way ofthe lower layer of the Streams device driver. The streams device driver exposes the TDI interface at its top and the NDIS interface at the bottom. Streams is a significant departure from the way protocols were developed for MS-DOS and OS/2.

Streams has one great disadvantage: overhead. The protocol requires more instructions to pass a request from the TDI through Streams than if Streams were not used. This is why TCP/IP and NWLink do not use Streams in Windows NT version 3.5 or later.


Distributed Processing

A powerful computer can share its processing power, executing tasks on behalf of other computers. Applications that split processing between networked computers are called distributed applications. A client/server application is a distributed application in which processing is divided between a workstation (the client) and a more powerful server. The client portion is sometimes referred to as the front end and the server portion is sometimes referred to as the back end.

The client portion of a client/server application usually consists of just the user interface to the application. It runs on the client workstation and takes a low-to- average amount of processing power. Typically, processing done by the client portion requires a large network bandwidth. For example, the client portion would handle screen graphics, mouse movements, and keystrokes.

The server portion of a client/server application often requires large amounts of data storage, computing power, and specialized hardware. It performs operations that include database lookups, updates, and mainframe data access.

The goal of distributed processing is to move the actual application processing from the client system to a server system with the power to run large applications. During execution, the client portion formats requests and sends them to the server for processing. The server executes the request.


Distributed Component Object Model

In addition to supporting component object model (COM) for interprocess communication on a local computer, Windows NT Server now supports distributed component object model (DCOM). DCOM (or Networked OLE) is a system of software objects designed to be reusable and replaceable. The objects support sets of related functions, such as sorting, random-number generation, and database searches. Each set of functions is called an interface, and each DCOM object can have multiple interfaces. When applications access an object, they receive an indirect pointer to the interface functions. From then on, the calling application doesn't need to know where the object is or how it does its job.

DCOM allows you to efficiently distribute processes across multiple computers so that the client and server components of an application can be placed in optimal locations on the network. Processing occurs transparently to the user. Thus, the user can access and share information without needing to know where the application components are located. If the client and server components of an application are located on the same computer, DCOM can be used to transfer information between processes. DCOM is platform independent and supports any 32-bit application that is DCOM-aware.

Note

Before you can use an application with DCOM, you must use DCOM Configuration to set the application's properties.

Advantages of Using DCOM

DCOM is the preferred method for developers to use in writing client/server applications for Windows NT.

With DCOM, interfaces can be added or upgraded without deleting the old ones, so applications aren't forced to upgrade each time the object changes. Functions are implemented as dynamic-link libraries, so changes in the functions, including new interfaces or the way the function works, can be made without recompiling the applications that call them.

Windows NT 4.0 supports DCOM by making the implementation of application pointers transparent to the application and the object. Only the operating system needs to know if the function called is handled in the same process or across the network. This frees the application from concerns with local or remote procedure calls. Administrators can choose to run DCOM applications on local or remote computers, and can change the configuration for efficient load balancing.

For example, suppose your company's payroll department uses an application with DCOM to print paychecks. When a payroll employee runs a DCOM-enabled client application on a desktop, the application starts a business-rules server. Then, the server application connects to a database server and retrieves employee records, such as salary information. The business-rules server then transforms the payroll information into the final output and returns it to the client to print.

Your application may support its own set of DCOM features. For more information about configuring your application to use DCOM, see your application's documentation.

DCOM builds upon remote procedure call (RPC) technology by providing a more scalable, easier-to-use mechanism for integrating distributed applications on a network. A distributed application consists of multiple processes that cooperate to accomplish a single task. Unlike other interprocess communication (IPC) mechanisms, DCOM gives you a high degree of control over security features, such as permissions and domain authentication. It can also be used to launch applications on other computers or to integrate web-browser applications that run on the ActiveX™ platform.

Microsoft Visual Basic®, Enterprise Edition customers who are currently using Remote Automation can easily migrate their existing applications to use DCOM. For more information, see your Visual Basic documentation or visit the Visual Basic web site at www.microsoft.com/vbasic.

Setting Security on DCOM Applications

The Windows NT 4.0 security model is easily extended to DCOM objects. Administrators set permissions on DCOM applications and can vary those permissions for local and remote execution.

Once a DCOM-enabled application is installed, you can use DCOM Configuration (in Control Panel) for the following purposes.

  • To disable DCOM so that it can't be used for the computer or the application.
  • To set the location of the application.
  • To set permissions on the server application by specifying which user accounts can or cannot access or start it. You can grant permissions that apply to all applications installed on the computer or to only a particular application.
  • To set the user account (or identity) that will be used to run the server application. The client application uses this account to start processes and access resources on other computers in the domain. If the server application is installed as a service, you can run the application using the built-in System account or a Windows NT Server service account that you have created.
  • To control the level of security (for example, packet encryption) for connections between applications.

The computers running the client application and the server application must both be configured for DCOM. On the computer running as a client, you must specify the location of the server application that will be accessed or started. For the computer running the server application, you must specify the user account that will have permission to access or start the application, and the user account that will be used to run the application.

Interprocess Communication Mechanisms for Distributed Processing

The connection between the client and server portions of distributed applications must allow data to flow in both directions. There are a number of ways to establish this connection. The Windows NT operating system provides seven different Interprocess Communication (IPC) mechanisms.

  • Named Pipes
  • Mailslots
  • NetBIOS
  • Windows Sockets
  • Remote Procedure Calls (RPCs)
  • Network Dynamic Data Exchange (NetDDE)
  • Server Message Blocks (SMBs)
  • Distributed Component Object Model (DCOM)
Named Pipes and Mailslots

A pipe is a portion of memory that can be used by one process to pass information to another. A pipe connects two processes so that the output of one can be used as input to the other.

Named pipes and mailslots are actually written as file system drivers, so implementation of named pipes and mailslots differs from implementation of other IPC mechanisms. There are entries in the registry for NPFS (Named Pipe File System) and MSFS (Mailslot File System). As file systems, they share common functionality, such as security, with the other file systems. Local processes can also use named pipes and mailslots. As with all of the file systems, remote access to named pipes and mailslots is accomplished through the redirector.

Named pipes provide connection-oriented messaging. Named pipes are based on OS/2 API calls, which have been ported into the Win32 base API set. Additional asynchronous support has been added to named pipes to make support of client/server applications easier.

In addition to the APIs ported from OS/2, the Windows NT operating system provides special APIs that increase security for named pipes. Using a feature called impersonation, the server can change its security identity to that of the client at the other end of the message. A server typically has more permissions to access databases on the server than the client requesting services has. When the request is delivered to the server through a named pipe, the server changes its security identity to the security identity of the client. This limits the server to only those permissions granted to the client rather than its own permissions, thus increasing the security of named pipes.

The mailslot implementation in the Windows NT operating system is a subset of the Microsoft OS/2 LAN Manager implementation. The Windows NT operating system implements only second-class mailslots, not first-class mailslots. Second-class mailslots provide connectionless messaging for broadcast messages. Delivery of the message is not guaranteed, although the delivery rate on most networks is quite high. Connectionless messaging is most useful for identifying other computers or services on a network, such as the Computer Browser service offered in the Windows NT operating system.

For a description of connectionless messaging, see "Data Transfer Modes," earlier in this chapter.

NetBIOS

NetBIOS is a standard programming interface in the personal-computing environment for developing client/server applications. NetBIOS has been used as an IPC mechanism since the introduction of the interface in the early 1980s.

A NetBIOS client/server application can communicate over various protocols:

  • NetBEUI Frame protocol (NBF).
  • NWLink NetBIOS (NWNBLink).
  • NetBIOS over TCP/IP (NetBT). NetBT provides RFC 1001/1002 NetBIOS support for the TCP/IP protocol stack.

From a programming perspective, higher-level IPC mechanisms, such as named pipes and RPC, have superior flexibility and portability.

NetBIOS uses the following components.

  • Netapi32.dll, which shares the address space of the NetBIOS user-mode application. (However, Netapi32.dll is used for more than NetBIOS requests.)
  • NetBIOS emulator, which provides the NetBIOS mapping layer between NetBIOS applications and the TDI-compliant protocols.

Figure 1.14 NetBIOS programming interface

MS-DOS and NetBIOS applications are hard-coded to use a specific LANA number for communicating on the network. You can assign a LANA number to each network route. The network route consists of the protocol driver and the network adapter that will be used for NetBIOS commands sent to its assigned LANA number.

To assign a LANA number to a network route

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Click NetBIOS Interface, and then click Properties.

The NetBIOS Configuration dialog box appears.

5. Click the number you want under Lana Number, and then click Edit.

6. Type a new number, and click OK.

Windows Sockets

The Windows Sockets API provides a standard interface to protocols with different addressing schemes. The Sockets interface was developed at the University of California, Berkeley, in the early 1980s. The Windows Sockets API was developed to migrate the Sockets interface into the Windows and Windows NT environments. Windows Sockets was also developed to help standardize an API for all operating system platforms. Windows Sockets is supported on the following protocols.

  • TCP/IP
  • NWLink (IPX/SPX)

Figure 1.15 Windows Sockets programming interface

Windows Sockets consists of the following items.

  • Wsock32.dll, which shares the address space of the Windows Sockets user-mode application.
  • Windows Sockets emulator, which provides the Windows Sockets mapping layer between the Windows Sockets applications and the TDI-compliant protocols.

Remote Procedure Call

Much of the original work on Remote Procedure Call (RPC) was initiated at Sun Microsystems. This work has been carried forward by the Open Software Foundation (OSF) as part of their Distributed Computing Environment (DCE). The Microsoft RPC implementation is compatible with the OSF/DCE standard RPC.

It is important to note that it is compatible but not compliant. In this situation, compliance implies that you started with the OSF source code and worked forward. For a number of reasons, Microsoft developed RPC from the ground up. The RPC mechanism is completely compatible with other DCE - based RPC systems, such as the ones for HP and IBM/AIX systems, and will interoperate with them.

The Microsoft RPC mechanism is unique in that it uses the other IPC mechanisms to establish communications between the client and the server. RPC can use the following to communicate with remote systems:

  • Named pipes
  • NetBIOS
  • Windows Sockets

If the client and server portions of the application are on the same machine, local procedure calls (LPCs) can be used to transfer information between processes. This makes RPC the most flexible and portable of the IPC choices available.

RPC is based on the concepts used for creating structured programs, which can be viewed as having a "backbone" to which a series of "ribs" can be attached. The backbone is the mainstream logic of the program, which should rarely change. The ribs are the procedures that the backbone calls on to do work or perform functions. In traditional programs, these ribs were statically linked to the backbone and stored in the same executable.

Windows and OS/2 use data-link libraries (DLLs). With DLLs, the procedure code and the backbone code are in different pieces. This enables the DLL to be modified or updated without changing or redistributing the backbone portion.

RPC takes the concept one step further and places the backbone and the ribs on different computers. This raises many issues, such as data formatting, integer-byte ordering, locating which server contains the function, and determining which communication mechanism to use.

RPC is the developer's preferred method for writing client/server applications for Windows NT. The components necessary to use a remote procedure call are the following items.

  • Remote Procedure Stub (Proc Stub), which packages remote procedure calls to be sent to the server by means of the RPC run time.
  • RPC Run Time (RPC RT), which is responsible for communications between the local and remote computer, including the passing of parameters.
  • Application Stub (APP Stub), which accepts RPC requests from RPC RT, unwraps the package, and makes the appropriate call to the remote procedure.
  • Remote Procedure, which is the actual procedure that is called by the network.

Client applications are developed with a specially compiled "stub" library. The client application "thinks" it will call its own subroutines. In reality, these stubs will transfer the data and the function to the RPC RT module. This module will be responsible for finding the server that can satisfy the RPC command. Once found, the function and data will be sent to the server, where they are picked up by the RPC RT component on the server. The server piece then loads the library needed for the function, builds the appropriate data structure, and calls the function.

The function interprets the call as coming from the client application. When the function is completed, any return values will be collected, formatted, and sent back to the client through the RPC RT. When the function returns to the client application, it will have the appropriate returned data or an indication that the function failed.

Figure 1.16 How RPC calls operate

Network Dynamic Data Exchange

Network Dynamic Data Exchange (NetDDE) is an extension of the Dynamic Data Exchange (DDE) protocol that has been in use since Windows version 2.x. NetDDE enables users to use DDE over a NetBIOS-compatible network. To understand NetDDE, you need to know something about DDE.

DDE is a protocol that allows applications to exchange data. To perform such an exchange, the two participating applications must first engage in a DDE conversation. The application that initiates the DDE conversation is the DDE client application, and the application that responds to the client request is the DDE server application.

A single application can be simultaneously engaged in multiple DDE conversations, acting as the DDE client application in some DDE conversations and as the DDE server application in others. This allows a user to set up a DDE link between applications and have one of the applications automatically update another.

Figure 1.17 NetDDE

NetDDE extends all of the DDE capabilities so that they can be used across the network, using the NetBIOS emulator. This enables applications on two or more workstations to dynamically share information. NetDDE is not a special form of DDE but rather a service that examines the information contained in a DDE conversation and looks for a special application name. Implementing NetDDE in this manner allows any DDE application to take advantage of NetDDE without modification.

The NetDDE service examines DDE requests, looking for the use of a special application name reserved by NetDDE, which is preceded by the name of the remote system. The reserved application name is NDDE$; therefore, NetDDE is looking for DDE requests that use an application name in the following form: \\<servername>\ndde$.

Before a user can connect to a printer or directory from a remote location, the printer or directory must be shared. Similarly, a NetDDE share must be created on a computer before an application on that computer can use NetDDE to communicate with the application on another computer. NetDDE-aware applications, such as Chat, automatically create a NetDDE share for themselves during installation. For other applications, a NetDDE share can be created with ClipBook Viewer, and data can then be exchanged through the ClipBoard. In addition, Windows NT includes the DDE Share utility (Ddeshare.exe), which can be used to set up a NetDDE share so that applications can directly exchange data.

NetDDE shares are defined in the registry. They are accessed by communicating with the Network DDE Service Data Manager (DSDM), which is the Windows NT operating system service that supports the rest of NetDDE.

Because NetDDE is simply an extension of DDE, the same APIs used to establish a DDE conversation are used to establish NetDDE conversations.

In Windows NT 3.1, the NetDDE services automatically load at system startup. In Windows NT 3.5 and later, the default startup type for NetDDE is manual, which improves startup time. The startup type for the NetDDE services can be configured through Control Panel.

Server Message Blocks

The Server Message Blocks (SMB) protocol, developed jointly by Microsoft, Intel, and IBM, defines a series of commands used to pass information between networked computers. The redirector packages network-control-block (NCB) requests meant for remote computers in a SMB structure. SMBs can be sent over the network to remote devices. The redirector also uses SMBs to make requests to the protocol stack of the local computer, such as "Create a session with the file server."

SMB uses four message types, which are listed below.

  • Session control messages, which consist of commands that start and end a redirector connection to a shared resource at the server.
  • File messages, which are used by the redirector to gain access to files at the server.
  • Printer messages, which are used by the redirector to send data to a print queue at a server and to get status information about the print queue.
  • Message messages, which allow an application to exchange messages with another workstation.

The provider DLL listens for SMB messages destined for it and removes the data portion of the SMB request so that it can be processed by a local device.

SMBs provide interoperability between different versions of the Microsoft family of networking products and other networks that use SMBs, including those on the following list.

  • MS® OS/2 LAN Manager
  • Microsoft Windows for Workgroups
  • IBM LAN Server
  • MS-DOS LAN Manager
  • DEC PATHWORKS
  • Microsoft LAN Manager for UNIX
  • 3Com 3+Open
  • MS-Net


Network Resource Access

Applications reside above the redirector and server services in user mode. Like all other layers in the Windows NT networking architecture, there is a unified interface for accessing network resources, which is independent of any redirectors installed on the system. Access to resources is provided through one of two components: the Multiple Universal Naming Convention Provider (MUP) and the Multi-Provider Router (MPR).

Multiple Universal Naming Convention Provider

When applications make I/O calls containing Universal Naming Code (UNC) names, these requests are passed to the Multiple Universal Naming Convention Provider (MUP). MUP selects the appropriate UNC provider (redirector) to handle the I/O request.

Universal Naming Convention Names

UNC is a naming convention for describing network servers and the share points on those servers. UNC names start with two backslashes followed by the server name. All other fields in the name are separated by a single backslash. A typical UNC name would appear as: \\server\share\subdirectory\filename.

Not all of the components of the UNC name need to be present with each command; only the share component is required. For example, the command dir\\servername\sharename can be used to obtain a directory listing of the root of the specified share.

Why MUP?

One of the design goals of the Windows NT networking environment is to provide a platform upon which others can build. MUP is a vital part of allowing multiple redirectors to coexist in the computer. MUP frees applications from maintaining their own UNC-provider listings.

How MUP Works

MUP is actually a driver, unlike the TDI interface, which merely defines the way a component on one layer communicates with a component on another layer. MUP also has defined paths to UNC providers (redirectors).

I/O requests from applications that contain UNC names are received by the I/O Manager, which in turn passes the requests to MUP. If MUP has not seen the UNC name during the previous 15 minutes, MUP will send the name to each of the UNC providers registered with it. MUP is a prerequisite of the Workstation service.

Figure 1.18 Multiple Universal Naming Convention Provider

When a request containing a UNC name is received by MUP, it checks with each redirector to find out which one can process the request. MUP looks for the redirector with the highest registered-priority response that claims it can establish a connection to the UNC. This connection remains as long as there is activity. If there has been no request for 15 minutes on the UNC name, then MUP once again negotiates to find an appropriate redirector.

Multi-provider Router

Not all programs use UNC names in their I/O requests. Some applications use WNet APIs, which are the Win32 network APIs. The Multi-Provider Router (MPR) was created to support these applications.

MPR is similar to MUP. MPR receives WNet commands, determines the appropriate redirector, and passes the command to that redirector. Because different network vendors use different interfaces for communicating with their redirector, there is a series of provider DLLs between MPR and the redirectors. The provider DLLs expose a standard interface so that MPR can communicate with them. The DLLs "know" how to take the request from MPR and communicate it to their corresponding redirector.

Figure 1.19 Multi-provider Router

The provider DLLs are supplied by the network-redirector vendor and should automatically be installed when the redirector is installed.


The Workstation Service

All user-mode requests go through the Workstation service. This service consists of two components.

  • The user-mode interface, which resides in Lmsvcs.exe in Windows NT 3.1 and Services.exe in Windows NT 3.5 and later.
  • The redirector (Rdr.sys), which is a file-system driver that interacts with the lower-level network drivers by means of the TDI interface.

The Workstation service receives the user request, and passes it to the kernel-mode redirector.

Figure 1.20 Workstation Service

Windows NT Redirector

The redirector (RDR) is a component that resides above TDI and through which one computer gains access to another computer. The Windows NT operating system redirector allows connection to Windows for Workgroups, LAN Manager, LAN Server, and other MS-Net-based servers. The redirector communicates to the protocols by means of the TDI interface.

The redirector is implemented as a Windows NT file system driver. Implementing a redirector as a file system has several benefits, which are listed below.

  • It allows applications to call a single API (the Windows NT I/O API) to access files on local and remote computers. From the I/O Manager perspective, there is no difference between accessing files stored on a remote computer on the network and accessing those stored locally on a hard disk.
  • It runs in kernel mode and can directly call other drivers and other kernel-mode components, such as Cache Manager. This improves the performance of the redirector.
  • It can be dynamically loaded and unloaded, like any other file-system driver.
  • It can easily coexist with other redirectors.

Figure 1.21 Windows NT redirector

Interoperating with Other Networks

Besides allowing connections to LAN Manager, LAN Server, and MS-Net servers, the Windows NT redirector can coexist with redirectors for other networks, such as Novell NetWare and Banyan VINES.

While Windows NT includes integrated networking, its open design provides transparent access to other networks. For example, a computer running Windows NT Server can concurrently access files stored on Windows NT and NetWare servers.

Providers and the Provider-interface Layer

For each additional type of network, such as NetWare or VINES, you must install a component called a provider. The provider is the component that allows a computer running Windows NT Server or Windows NT Workstation to communicate with the network. The Windows NT operating system includes two providers; Client Services for NetWare and Gateway Services for NetWare.

Client Services for NetWare is included with Windows NT Workstation and allows a computer running Windows NT Workstation to connect as a client to the NetWare network. The Gateway service, included with Windows NT Server, allows a computer running Windows NT Server to connect as a client to the NetWare network. Other provider DLLs are supplied by the appropriate network vendors.

Accessing a Remote File

When a process on a Windows NT computer tries to open a file that resides on a remote computer, the following steps occur.

First, the process calls the I/O Manager to request that the file be opened.

Then, the I/O Manager recognizes that the request is for a file on a remote computer, and passes the request to the redirector file-system driver.

Finally, the redirector passes the request to lower-level network drivers, which transmit it to the remote server for processing.

Workstation Service Dependencies

Configuration requirements for loading the Workstation service include:

  • A protocol that exposes the TDI interface must be started.
  • The MUP driver must be started.


The Server Service

Windows NT includes a second component, called the Server service. Like the redirector, the Server service sits above TDI, is implemented as a file system driver, and directly interacts with various other file-system drivers to satisfy I/O requests, such as reading or writing to a file.

The Server service supplies the connections requested by client-side redirectors and provides them with access to the resources they request.

When the Server service receives a request from a remote computer asking to read a file that resides on the local hard drive, the following steps occur.

  • The low-level network drivers receive the request and pass it to the server driver (SRV).
  • The Server service passes a read-file request to the appropriate local file-system driver.
  • The local file-system driver calls lower-level, disk-device drivers to access the file.
  • The data is passed back to the local file-system driver.
  • The local file-system driver passes the data back to the Server service.
  • The Server service passes the data to the lower-level network drivers for transmission back to the client computer.

Figure 1.22 Server Service

Like the Workstation service, the Server service is composed of two parts.

  • Server, a service that runs in the Services.exe, which is the Service Control Manager, where all services start. Unlike the Workstation service, the Server service is not dependent on the MUP service because the server is not a UNC provider. It does not attempt to connect to other computers, but other computers connect to it.
  • Srv.sys, a file system driver that handles the interaction with the lower levels and directly interacts with various file system devices to satisfy command requests, such as file read and write.


Binding Options

Earlier in this chapter, we discussed how the Windows NT network architecture consists of a series of layers and how components in each layer perform specific functions for the layers above and below it. The bottom of the network architecture ends at the network adapter card, which moves information between computers that are part of the network.

Figure 1.23 Network protocol bindings

The linking of network components on different levels to enable communication between those components is called binding. A network component can be bound to one or more network components above or below it. The services that each component provides can be shared by all the components bound to it.

When adding network software, Windows NT automatically binds all dependent components accordingly.

In the Network window, the Bindings tab displays the bindings of the installed network components, from the upper-layer services and protocols to the lowest layer of network adapter drivers. Bindings can be enabled and disabled, based on the use of the network components installed on the system.

Figure 1.24 The Settings tab of the Network window

Bindings can be ordered or sequenced to optimize the system's use of the network. For example, if NetBEUI and TCP/IP are installed on a computer, and if most of servers that the computer connects to are running only TCP/IP, the Workstation bindings should be examined. The administrator of this computer would want to make sure that the Workstation is bound to TCP/IP first and that NetBEUI is at the bottom of the list.

In Windows NT 3.1, the redirector uses the following method to establish a connection.

  • First, the redirector submits the connect request to the first protocol driver in the bindings order and waits for that protocol driver to complete the request and return.
  • If the first protocol driver's return indicates that it could not connect to the specified server, then the redirector submits the connect request to the second protocol driver in the bindings order.
  • This continues down the bindings order until a protocol-driver return indicates that the connection was successful or until all protocol drivers have been tried and have failed.

In Windows NT 3.5 and later, the redirector uses the following method to establish a connection.

  • The redirector simultaneously submits the connect request to all protocol drivers.
  • When one of the protocol drivers successfully completes the request, the redirector waits until all higher-priority protocol drivers, if there are any, have been returned. (The priority is based on the bindings order.)
  • The redirector then proceeds to use the highest-priority protocol driver that returned with success status, and it disconnects all connections that may have been established through lower-priority protocol drivers.


Remote Access Service

The Windows NT Workstation and Windows NT Server RAS connects remote or mobile workers to corporate networks. Optimized for client/server computing, RAS is implemented primarily as a software solution, and is available on all Microsoft operating systems.

To understand the RAS architecture, it is important to make the distinction between RAS and remote-control solutions, such as Cubix and pcANYWHERE. RAS is a software-based, multiprotocol router, while remote-control solutions work by sharing screen, keyboard, and mouse control over a WAN connection. In a remote-control solution, users share a CPU or multiple CPUs on the server. In contrast, a computer running Windows NT RAS server's is dedicated to communications, not to running applications.

Point-to-Point Protocol

The Windows NT operating system supports the Point-to-Point Protocol (PPP) in RAS. PPP is a set of industry-standard framing and authentication protocols. PPP negotiates configuration parameters for multiple layers of the OSI model.

PPP support in Windows NT 3.5 and later (and Windows 95) means that computers running Windows can dial into remote networks through any server that complies with the PPP standard. PPP compliance enables a Windows NT Server to receive calls from other vendors' remote-access software and to provide network access to them.

The PPP architecture also enables clients to load any combination of IPX, TCP/IP, and NetBEUI. Applications written to the Windows Sockets, NetBIOS, or IPX interfaces can now be run on a remote computer running Windows NT Workstation. The following figure illustrates the PPP architecture of RAS.

Figure 1.25 Point-to-Point Protocol

RAS Connection Sequence

The RAS connection sequence is key to understanding the PPP protocol. Upon connecting to a remote computer, the PPP negotiation begins.

  • First, framing rules are established between the remote computer and server. This allows continued communication (frame transfer) to occur.
  • Next, the RAS server uses the PPP authentication protocols (PAP, CHAP, SPAP) to authenticate the remote user. The protocols invoked depend on the security configurations of the remote client and server.
  • Once authenticated, the Network Control Protocols (NCPs) are used to enable and configure the server for the LAN protocol that will be used on the remote client.

When the PPP connection sequence is successfully completed, the remote client and RAS server can begin to transfer data using any supported protocol, such as Windows Sockets, RPC, or NetBIOS. The following illustration shows where the PPP protocol is on the OSI model.

Figure 1.26 PPP within the OI model

If a remote client is configured to use the NetBIOS Gateway or Serial Line Internet Protocol (SLIP), this sequence is invalid.

Point-to-Point Tunneling Protocol

Point-to-point tunneling protocol (PPTP) is a new networking technology that supports multiprotocol, virtual private networks (VPNs). PPTP enables remote users to securely access corporate networks across the Internet. This eliminates the need for corporations to invest in communications lines, such as ISDN, between corporate sites.

If you select PPTP filtering, you effectively disable the selected network adapter for all other protocols. Only PPTP packets will be allowed in. A typical scenario in which you might use this is with a computer that is multihomed and that has one network adapter (with PPTP filtering enabled) connected to the Internet and another network adapter connected to the internal corporate network. Clients outside the corporate network can use PPTP to connect to this machine from across the Internet and thus gain secure access to the corporate network.

For more information about working with Windows NT on the Internet, see the Microsoft Windows NT Server 4.0 Internet Guide.

NetBIOS Gateway

Windows NT continues to support NetBIOS gateways, the architecture used in previous versions of the Windows NT operating system and LAN Manager. Remote users connect using NetBEUI, and the RAS server translates packets to IPX or TCP/IP, if necessary. This enables users to share network resources in a multiprotocol LAN, but prevents them from running applications that rely on IPX or TCP/IP on the client. The NetBIOS gateway is used by default when remote clients use NetBEUI. The following illustration shows the NetBIOS gateway architecture of RAS.

Figure 1.27 NetBIOS gateway architecture of RAS

An example of the NetBIOS gateway capability is remote network access for Lotus Notes users. While Lotus Notes does offer dial-up connectivity, dial-up is limited to the Notes application. RAS complements this connectivity by providing a low-cost, high-performance, remote-network connection for Notes users, which connects Notes and offers file and print services with access to other network resources.

Serial Line Internet Protocol

SLIP is an older communications standard found in UNIX environments. SLIP does not provide the automatic negotiation of network configuration and encrypted authentication that PPP can provide. SLIP requires user intervention. Windows NT RAS can be configured as a SLIP client, enabling users to dial into an existing SLIP server. RAS does not provide a SLIP server in Windows NT Server.

For more information about RAS issues, see the Rasphone.hlp online Help file on the Windows NT distribution disks (or, if RAS has been installed, see systemroot\System32).


Services for Macintosh

Through Windows NT Services for Macintosh, Macintosh users can connect to a Windows NT server in the same way they would connect to an AppleShare server. Windows NT Services for Macintosh will support an unlimited number of simultaneous AFP connections to a Windows NT server, and Macintosh sessions will be integrated with Windows NT sessions. The per-session memory overhead is approximately 15K.

Existing versions of LAN Manager Services for the Macintosh can be easily upgraded to Windows NT Services for Macintosh. OS/2-based volumes that already exist are converted with permissions intact. Graphical installation, administration, and configuration utilities are integrated with existing Windows NT administration tools. Windows NT Services for Macintosh requires System 6.0.7 or higher and is AFP 2.1-compliant; however, AFP 2.0 clients are also supported. AFP 2.1 compliance provides support for logon messages and server messages.

Support for Macintosh networking is built into the core operating system for Windows NT Server. Windows NT Services for Macintosh includes a full AFP 2.0 file server. All Macintosh file system attributes, such as resource data forks and 32-bit directory IDs, are supported. As a file server, all filenames, icons, and access permissions are intelligently managed for different networks. For example, a Word for Windows file will appear on the Macintosh with the correct Word for Macintosh icons. These applications can also be launched from the File Server as Macintosh applications. When files are deleted, no orphaned resource forks will be left to be cleaned up.

Windows NT Services for Macintosh fully supports and complies with Windows NT security. It presents the AFP security model to Macintosh users and allows them to access files on volumes that reside on CD-ROM or other read-only media. The AFP server also supports both cleartext and encrypted passwords at logon time. The administrator has the option to configure the server not to accept cleartext passwords.

Services for Macintosh can be administered from Control Panel and can be started transparently if the administrator has configured the server to use this facility.

Macintosh-accessible volumes can be created in My Computer. Services for Macintosh automatically creates a Public Files volume at installation time. Windows NT file and directory permissions are automatically translated into corresponding Macintosh permissions.

Windows NT Services for Macintosh has the same functionality as the LAN Manager Services for Macintosh 1.0 MacPrint. Administration and configuration are also easier. There is a user interface for publishing a print queue on AppleTalk and a user interface for choosing an AppleTalk printer as a destination device. The Windows NT print subsystem handles AppleTalk despooling errors, and uses the built-in printer support in Windows NT. (The PPD file scheme of Macintosh Services 1.0 is not used.) Services for Macintosh also has a PostScript-compatible engine that allows Macintosh computers to print to any Windows NT printer as if they were printing to a LaserWriter.


Chapter 2 - Network Security and Domain Planning

Network security refers to the protection of all components — hardware, software, and stored data — of a computer network from damage, theft, and unauthorized use. A computer security plan that is well thought out, implemented, and monitored makes authorized use of network computers easy and unauthorized use or accidental damage difficult or impossible.

Microsoft included security as part of the initial design specifications for Windows NT, and it is pervasive in the operating system. The security model includes components to control who accesses which objects (such as files and shared printers), which action an individual user can take on an object (such as write access to a file), and which events are audited.

Security over a Windows NT network incorporates domains and trust relationships to provide the most secure networking operating system available.

This chapter provides:

  • An overview of the Windows NT security model and architecture.
  • A description of how the features of the security model control access to resources.
  • An overview of auditing security events.
  • A description of how domains work to implement security over the network.
  • Considerations for planning your domain structure, including a description of the Microsoft domain model.
  • Troubleshooting.

This chapter presumes a good understanding of Windows NT domains. For background information about domains, see "Managing Windows NT Server Domains" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.


Security Model Architecture

Figure 2.1 on the facing page shows the components of the Windows NT security model, which include:

  • Logon processes, which accept logon requests from users. These include the initial interactive logon, which displays the initial logon dialog box to the user, and remote logon processes, which allow access by remote users to a Windows NT server process.
  • Local Security Authority (LSA), which ensures that the user has permission to access the system. This component is the center of the Windows NT security subsystem. It generates access tokens, manages the local security policy, and provides interactive user authentication services. LSA also controls audit policy and logs the audit messages generated by the Security Reference Monitor.
  • Security Account Manager (SAM), also known as the directory database, which maintains the user-accounts database. This database contains information for all user accounts and group accounts. SAM provides user validation services, which are used by LSA.
  • Security Reference Monitor, which checks that the user has permission to access an object and perform whatever action the user is attempting. This component enforces the access validation and audit generation policy defined by LSA. It provides services to both kernel and user modes to ensure the users and processes attempting access to an object have the necessary permissions. This component also generates audit messages when appropriate.

Figure 2.1 Windows NT Security Components

Together, these components are known as the security subsystem. This subsystem is called an integral subsystem, not an environmental subsystem, because it affects the entire Windows NT operating system.

The Windows NT security model is designed for C2-level security, as defined by the U.S. Department of Defense. Some of the most important requirements of C2-level security are:

  • The owner of a resource (such as a file) must be able to control access to the resource.
  • The operating system must protect objects so that they are not randomly reused by other processes.

For example, the system protects memory so that its contents cannot be read after it is freed by a process. When a file is deleted, users must not be able to access the data from that file.

  • Each user must identify himself or herself by typing a unique logon name and password before being allowed access to the system. The system must be able to use this unique identification to track the activities of the user.
  • System administrators must be able to audit security-related events. Access to this audit data must be limited to authorized administrators.
  • The system must protect itself from external interference or tampering, such as modification of the running system or of system files stored on disk.

For more information about C2-level security, see "Security Considerations and C2 Security Rating," later in this chapter.


Controlling Access

Windows NT Server provides control of what network computer users can and cannot do, while still giving them access to the resources they need. You can allow some users to connect to a resource (such as a printer) or perform an action (such as changing a file) while preventing others from doing so. You can even control access to system functions, such as setting a computer's system clock. This can be done for users working at the computer in which the resource is located and for users connecting to the resource over the network.

The following features allow and restrict access:

  • User accounts
  • User rights
  • User groups
  • Subjects and impersonations
  • Security information about objects (permissions)

Implementing security over a network also involves the use of domains and domain controllers, which are presented in the section "Windows NT Server Domains" later in this chapter.


User Accounts

An individual who participates in a domain must have a user account to log on to the network and use domain resources, such as files, directories, and printers.

An administrator creates a user account by assigning a user name to an account, specifying the user's identification data, and defining the user's rights on the system. The account includes user information, group memberships, and security-policy information. Windows NT Server then assigns a unique security identifier (SID) to the new account.

Each SID is unique for all time. For example, suppose Sally, who has a Windows NT account, leaves her job at a company but later returns to a different job at the same company. When Sally leaves, the administrator deletes her account, and Windows NT no longer accepts her security ID as valid. When Sally returns, the administrator creates a new account, and Windows NT generates a new security ID for that account. The new security ID does not match the old one, so nothing from the old account is transferred to the new account.

When a user logs on, Windows NT creates a security-access token. This includes a security ID for the user, other security IDs for the groups to which the user belongs, and other information, such as the user's name and the names of the groups to which that user belongs. Every process that runs on behalf of this user will have a copy of his or her access token. For example, when Sally starts Notepad, the Notepad process receives a copy of Sally's access token.

Windows NT refers to the security IDs within a user's access token when he or she tries to access an object. The security IDs are compared to the list of access permissions for the object to ensure that the user has sufficient permission to access the object.

For more information about access tokens, see Chapter 6, "Windows NT Security Model," in the Microsoft Windows NT Workstation 4.0 Resource Guide.


User Rights

User rights are rules that determine the actions a user can perform. Unless the computer is a domain controller, they are computer-specific policies. If it is a domain controller, the computer policy extends to all domain controllers in the domain.

Note

In the current release of Windows NT, the set of user rights is defined by the system and cannot be changed. Future versions of Windows NT may allow software developers to define new user rights appropriate to their application.

User rights can be assigned to individual user accounts, but are usually (and more efficiently) assigned to groups. Predefined (built-in) groups have sets of user rights already assigned. Administrators usually assign user rights by adding a user account to one of the predefined groups or by creating a new group and assigning specific user rights to that group. Users who are subsequently added to a group automatically gain all user rights assigned to the group account.

There are several user rights that administrators of high-security installations should be aware of and possibly audit. Of these, you might want to change the default permissions for two rights: Log on locally and Shut down the system.

Table 2.1 Default user rights that may require changing

User Right | Groups assigned this right by default | Recommended change
Log on locally Allows a user to log on at the computer, from the computer's keyboard. | Administrators, Backup Operators, Everyone, Guests, Power Users, and Users | Deny Everyone and Guests this right.
Shut down the system (SeShutdownPrivilege) Allows a user to shut down Windows NT. | Administrators, Backup Operators, Everyone, Power Users, and Users | Deny Everyone and Users this right.

The rights in the following table generally require no changes to the default settings, even in the most highly secure installations.

Table 2.2 Default user rights

Right |  | Allows |  | Initially assigned to
Access this computer from the network |  | A user to connect to the computer over the network. |  | Administrators, Everyone, Power Users
Act as part of the operating system (SeTcbPrivilege) |  | A process to perform as a secure, trusted part of the operating system. Some subsystems are granted this right. |  | (None)
Add workstations to the domain (SeMachineAccountPrivilege) |  | Nothing. This right has no effect on computers running Windows NT. |  | (None)
Back up files and directories (SeBackupPrivilege) |  | A user to back up files and directories. This right supersedes file and directory permissions. |  | Administrators, Backup Operators
Bypass traverse checking (SeChangeNotifyPrivilege) |  | A user to change directories and to access files and subdirectories, even if the user has no permission to access parent directories. |  | Everyone
Change the system time (SeSystemTimePrivilege) |  | A user to set the time for the internal clock of the computer. |  | Administrators, Power Users
Create a pagefile (SeCreatePagefilePrivilege) |  | Nothing. This right has no effect in current versions of Windows NT. |  | Administrators
Create a token object (SeCreateTokenPrivilege) |  | A process to create access tokens. Only the Local Security Authority can do this. |  | (None)
Create permanent shared objects (SeCreatePermanentPrivilege) |  | A user to create special permanent objects, such as \\Device, that are used within Windows NT. |  | (None)
Debug programs (SeDebugPrivilege) |  | A user to debug various low-level objects, such as threads. |  | Administrators
Force shutdown from a remote system (SeRemoteShutdownName) |  | A user to shut down a remote computer. |  | Administrators
Generate security audits (SeAuditPrivilege) |  | A process to generate security-audit log entries. |  | (None)
Increase quotas (SeIncreaseQuotaPrivilege) |  | Nothing. This right has no effect in current versions of Windows NT. |  | (None)
Increase scheduling priority (SeIncreaseBasePriorityPrivilege) |  | A user to boost the execution priority of a process. |  | Administrators, Power Users
Load and unload device drivers (SeLoadDriverPrivilege) |  | A user to install and remove device drivers. |  | Administrators
Lock pages in memory (SeLockMemoryPrivilege) |  | A user to lock pages in memory so they cannot be paged out to a backing store, such as Pagefile.sys. |  | (None)
Log on as a batch job |  | Nothing. This right has no effect in current versions of Windows NT. |  | (None)
Log on as a service |  | A process to register with the system as a service. |  | (None)
Log on locally |  | A user to log on at the computer from the computer keyboard. |  | Administrators, Backup Operators, Guests, Power Users, Users
Manage auditing and security log (SeSecurityPrivilege) | A user to specify what types of resource access (such as file access) are to be audited, and to view and clear the security log. This right does not allow a user to set system auditing policy using Audit on the User Manager Policy menu. Members of the Administrators group can always view and clear the security log. |  | Administrators
Modify firmware environment variables (SeSystemEnvironmentPrivilege) | A user to modify system- environment variables stored in nonvolatile RAM on systems that support this type of configuration. |  | Administrators
Profile single process (SeProfSingleProcess) | A user to perform profiling (performance sampling) on a process. |  | Administrators, Power Users
Profile system performance (SeSystemProfilePrivilege) | A user to perform profiling (performance sampling) on the system. |  | Administrators
Replace a process-level token (SeAssignPrimaryTokenPrivilege) | A user to modify a process's security-access token. This is a powerful right, used only by the system. |  | (None)
Restore files and directories (SeRestorePrivilege) | A user to restore backed-up files and directories. This right supersedes file and directory permissions. |  | Administrators, Backup Operators
Shut down the system (SeShutdownPrivilege) | A user to shut down Windows NT. |  | Administrators, Backup Operators, Power Users, Users
Take ownership of files or other objects (SeTakeOwnershipPrivilege) | A user to take ownership of files, directories, printers, and other objects on the computer. This right supersedes permissions protecting objects. |  | Administrators


Grouping Users with Similar Needs

Administrators typically group users according to the network access their jobs require. For example, most accountants working at a certain level will probably need access to the same servers, directories, and files. By using group accounts, administrators can simultaneously grant rights and permissions to multiple users. Other users can be added to an existing group account at any time, instantly gaining the rights and permissions granted to the group account.

There can be two types of group accounts:

  • A global group consists of several user accounts from one domain, which are grouped together under an account name. A global group can contain user accounts from only a single domain : the domain in which the global group was created. Global signifies that the group can be granted rights and permissions to use resources in multiple (global) domains. A global group can contain only user accounts (not other groups). A global group cannot be created on a computer running Windows NT Workstation or on a computer set up as a member server.

For more information about member servers see "Windows NT Server Domains" later in this chapter.

  • A local group can include user accounts and global groups from one or more domains, grouped together under one account name. Users and global groups from outside the local domain can be added to the local group only if they belong to a trusted domain. Local signifies that the group can be granted rights and permissions to use resources in only a single (local) domain. A local group can contain users and global groups, but it cannot contain other local groups.

When working with groups, use these guidelines:

  • It is best to grant rights and permissions to local groups and to use the global group as the method of adding users to the local groups.

Global groups are the best method for simultaneously adding many users to another domain. The necessary rights and permissions are provided by the local group to which the global groups are added.

  • Global groups are the most efficient way to add users to local groups.
  • Global groups can be added to local groups in the same domain or in trusting domains, or to computers running Windows NT Workstation or Windows NT Server as a member server in either the same domain or a trusting domain.

Windows NT Server has built-in both local and global user groups. For more information about built-in groups, see "Working with User and Group Accounts" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.


Subjects and Impersonation

One objective of the Windows NT security model is to ensure that the programs that a user runs have no more access to objects than the user does. That is, if a user is granted only read access to a file, then when he or she runs a program, that program cannot write to the file. The program, like the user, is granted read-only permission.

A subject is the combination of the user's access token and the program that is acting on the user's behalf. Windows NT uses subjects to track and manage permissions for the programs users run.

When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context controls what access the subject has to objects and system services.

To accommodate the client/server model of Windows NT, there are two classes of subjects within the Windows NT security architecture:

  • A simple subject, which is a process that was assigned a security context when the corresponding user logged on. It is not acting in the capacity of a protected server, which may have other subjects as clients.
  • A server subject, which is a process implemented as a protected server (such as the Win32 subsystem), and which has other subjects as clients. In this role, a server subject typically has the security context of those clients available for use when acting on their behalf.

When a subject calls an object service through a protected subsystem, the subject's token is used within the service to determine who made the call and to decide whether the caller has sufficient access authority to perform the requested action.

Windows NT allows one process to take on the security attributes of another through a technique called impersonation. For example, a server process typically impersonates a client process to complete a task involving objects to which the server does not normally have access.


Security Information for Objects (Permissions)

All named objects in Windows NT and some unnamed objects can be secured. A security descriptor describes the security attributes for an object. An object's security descriptor includes four parts:

  • An owner security ID, which indicates the user or group who owns the object. The owner of an object can change the access permissions for the object.
  • A group security ID, which is used only by the POSIX subsystem and ignored by the rest of Windows NT.
  • A discretionary access control list (ACL), which identifies the users and groups who are granted or denied specific access permissions. Discretionary ACLs are controlled by the owner of the object.
  • A system ACL, which controls the auditing messages the system will generate. System ACLs are controlled by the security administrators.

For details and background information about security in Windows NT 4.0, see Chapter 6, "Windows NT Security," in the Microsoft Windows NT Workstation Resource Guide.

Types of Objects

The permissions that can be granted or denied for an object depends on the type of object. For example, you can specify permissions, such as Manage Documents and Print for a printer queue, and specify Read, Write, Execute for a directory.

Permissions of an object are also affected by whether that object is a container object or a noncontainer object. A container object is one that logically contains other objects; a noncontainer object does not contain other objects. For example, a directory is a container object that logically contains files and other directories. Files are noncontainer objects. This distinction between container and noncontainer objects is important because objects within a container object can inherit certain permissions from the parent container.

Note

NTFS supports ACL inheritance from directory objects to file objects that are created within the directory. For more information about NTFS, see "Disk and File System Basics" and "Choosing a File System" in the Microsoft Windows NT Workstation Resource Guide.

Access Control Lists and Access Control Entries

Each ACL is made up of access control entries (ACEs), which specify access or auditing permissions to that object for one user or group. There are three ACE types: two for discretionary access control and one for system security.

The discretionary ACEs are AccessAllowed and AccessDenied. These explicitly grant and deny access to a user or group of users. The first AccessDenied ACE denies the user access to the resource, and no further processing of ACEs occurs.

Note

There is an important distinction between a discretionary ACL that is empty (one that has no ACEs in it) and an object without any discretionary ACL. In the case of an empty discretionary ACL, no accesses are explicitly granted, so access is implicitly denied. For an object that has no ACL at all, there is no protection assigned to the object, so any access request is granted.

SystemAudit is a system security ACE that is used to keep a log of security events (such as who accesses which files) and to generate and log security audit messages.

Access Masks

Each ACE includes an access mask, which defines all possible actions for a particular object type. An access mask can be compared to a menu, from which you select permissions to grant or deny.

Specific types include access options that apply specifically to an object type. Each object type can have up to 16 specific access types. Collectively, the specific access types for a particular object type are called the specific access mask. These are defined when the object type is defined.

For example, Windows NT files have the following specific access types:

  • ReadData
  • WriteData
  • AppendData
  • ReadEA (Extended Attribute)
  • WriteEA (Extended Attribute)
  • Execute
  • ReadAttributes
  • WriteAttributes

Standard types apply to all objects and consist of these access permissions:

  • SYNCHRONIZE, which is used to synchronize access and to allow a process to wait for an object to enter the signaled state.
  • WRITE_OWNER, which is used to assign a write owner.
  • WRITE_DAC, which is used to grant or deny write access to the discretionary ACL.
  • READ_CONTROL, which is used to grant or deny read access to the security descriptor and owner.
  • DELETE, which is used to grant or deny delete access.

Generic types are broad types of access used when protecting an object. Exact implementation of these is determined by the application defining an object. For example, an application that defines a voice-annotation object might define specific access rights by using VOICE_PLAY and VOICE_EDIT for playing and editing the object. It might set up a generic mapping structure in which GENERIC_EXECUTE maps to VOICE_PLAY and GENERIC_WRITE maps to both VOICE_PLAY and VOICE_EDIT.

The following table shows the generic types that are mapped from specific and standard types.

Table 2.3 Generic types of access masks

Generic type | Mapped from these specific and standard types
FILE_GENERIC_READ | STANDARD_RIGHTS_READ FILE_READ_DATA FILE_READ_ATTRIBUTES FILE_READ_EA SYNCHRONIZE
FILE_GENERIC_WRITE | STANDARD_RIGHTS_WRITE FILE_WRITE_DATA FILE_WRITE_ATTRIBUTES FILE_WRITE_EA FILE_APPEND_DATA SYNCHRONIZE
FILE_GENERIC_EXECUTE | STANDARD_RIGHTS_EXECUTE FILE_READ_ATTRIBUTES FILE_EXECUTE SYNCHRONIZE

Specific and standard types appear in the details of the security log. Generic types do not appear in the security log. Instead, the corresponding specific and standard types are listed.

Access Control Inheritance

When you create new objects within a container object, the new objects inherit permissions by default from the parent object.

In the case of files and directories, changing the permissions on a directory affects that directory and its files but does not automatically apply to existing subdirectories and their contents. They will do so if you select the Replace Permissions On Existing Files check box and the Replace Permissions On Subdirectories check box in the Directory Permissions dialog box.


Access Validation

When a user tries to access an object, Windows NT compares security information in the user's access token with the security information in the object's security descriptor.

A desired access mask for the subject is created, based on the type of access the user is attempting. This desired access mask, usually created by a program that the user is running, is compared with the object's ACL. (All generic access types in the ACL are mapped to standard and specific access types.) Each ACE in the ACL is evaluated as follows:

1. The security ID in the ACE is compared with the set of security IDs in the user's access token. If a match is not found, the ACE is skipped.

Further processing is based upon the type of the ACE. AccessDenied ACEs are ordered (and therefore processed) before AccessAllowed ACEs.

2. If access is denied, the system checks whether the original desired access mask contained only a ReadControl and WRITE_DAC. If so, the system checks whether the requester is the owner of the object. If so, then access is granted.

3. For an AccessDenied ACE, the actions in the ACE access mask are compared with the desired access mask. If any access is found in both masks, access is denied. Otherwise, processing continues with the next requested ACE.

4. For an AccessAllowed ACE, the actions in the ACE are compared with those listed in the desired access mask. If all accesses in the desired access mask are matched in the ACE, no further processing is necessary, and access is granted. Otherwise, processing continues with the next ACE.

5. If the contents of desired access mask are still not completely matched at the end of the ACL, access is implicitly denied.


Auditing Security Events

Windows NT includes auditing features you can use to collect information about how your system is being used. These features also allow you to monitor events related to system security, to identify any security breaches, and to determine the extent and location of any damage. The level of audited events is adjustable to suit the needs of your organization. Some organizations need little auditing information, while others are willing to trade some performance and disk space for detailed information they can use to analyze their system.

Note

When you enable auditing, remember that there is a small performance overhead for each audit check the system performs.

Windows NT can track events related to the operating system itself and to individual applications. Each application can define its own auditable events. Definitions of these events are added to the Registry when the application is installed on your Windows NT computer.

Audit events are identified to the system by the event source-module name (which corresponds to a specific event type in the Registry) and an event ID.

The security log in Event Viewer can list events by category and by event ID. The following categories of events are listed in the security log. (Those in parentheses are found in the Audit Policy dialog box in User Manager.)

Table 2.4 Security Events that can be audited

Category | Meaning
Account Management (User and Group Management) | These events describe high-level changes to the user-accounts database, such as User Created or Group Membership Change. Potentially, a more detailed, object-level audit is also performed. (See the "Object Access" category, below).
Detailed Tracking (Process Tracking) | These events provide detailed subject-tracking information, such as program activation, handle duplication, and indirect object access.
Logon/Logoff (Logon and Logoff) | These events describe a single logon or logoff attempt, whether successful or unsuccessful. Included in each logon description is an indication of what type of logon (that is, interactive, network, or service)was requested or performed.
Object Access (File and Object Access) | These events describe both successful and unsuccessful accesses to protected objects.
Policy Change (Security Policy Changes) | These events describe high-level changes to the security policy database, such as assignment of privileges or logon capabilities. Potentially, a more detailed, object-level audit is also performed. (See the "Object Access" category, above).
Privilege Use (Use of User Rights) | These events describe both successful and unsuccessful attempts to use privileges. The category also includes information about when some special privileges are assigned. These special privileges are audited only at assignment time, not at the time of use.
System Event (System) | These events indicate something occurred that affects the security of the entire system or audit log.

For more information about auditing security events, see "Windows NT Security" in the Microsoft Windows NT Workstation Resource Guide, and "Monitoring Events" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.


Windows NT Server Domains

A domain is a logical grouping of network servers and other computers that share common security and user-account information. Within domains, administrators create one user account for each user. Users then log on to the domain, not to individual servers in the domain.

The term domain does not refer to a single location or specific type of network configuration. Computers in a single domain can share physical proximity on a small LAN or can be located in different parts of the world. They communicate over any of various physical connections, such as dial-up lines, ISDN, fiber, Ethernet, token ring, frame relay, satellite, and leased lines.

The domain structure provides the following advantages for maintaining a secure network:

  • Single Logon Procedure

Network users can connect to multiple servers by logging on to a single network.

  • Universal Resource Access

The user needs only one domain user account and password to use network resources.

  • Centralized Network Administration

A centralized view of the entire network from any workstation on the network provides the ability to track and manage information on users, groups, and resources in a distributed network. This single point of administration for multiple servers simplifies the management of a Windows NT Server – based network.

For detailed information about domains, see "Managing Windows NT Server Domains" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.


The Directory Database

The directory database, SAM, stores all security and user-account information for a domain. The master copy of the directory database is stored on the primary server and is regularly replicated to backup servers to maintain centralized security. When a user logs on to a domain, the Windows NT Server software checks the user name and password against the directory database.


Domain Controllers

Domain controllers are computers running Windows NT Server that use one shared directory to store security and user-account information for the entire domain; they comprise a single administrative unit. Within a domain, domain controllers manage all aspects of user/domain interactions. Windows NT domain controllers use the information in the directory database to authenticate users logging on to domain accounts. There are two types of domain controllers:

  • The primary domain controller (PDC), which tracks changes made to domain accounts and stores the information in the directory database. A domain has one PDC.
  • A backup domain controller (BDC), which maintains a copy of the directory database. This is periodically synchronized with the directory database on the PDC. A domain can have multiple BDCs.

For more information about domain controllers, see "Managing Windows NT Server Domains" the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.


Member Servers

Computers running Windows NT Server can be configured as member servers, which do not store copies of the directory data base and therefore do not authenticate accounts or receive synchronized copies of the directory database. These servers are dedicated to specific tasks, such as print or file servers, or to high-volume applications, such as databases.


Trust Relationships

Windows NT Server directory services provide security across multiple domains through trust relationships. A trust relationship is a link that combines two domains into one administrative unit that can authorize access to resources on both domains.

There are two types of trust relationships:

  • In a one-way trust relationship, one domain trusts the users in the other domain to use its resources. More precisely, one domain trusts the domain controllers in the other domain to validate user accounts to use its resources. The resources that become available are in the trusting domain, and the accounts that can use them are in the trusted domain. If user accounts located in the trusting domain need to use resources located in the trusted domain, that requires a two-way trust relationship.
  • A two-way trust relationship is two one-way trusts: Each domain trusts user accounts in the other domain. Users can log on to their domain account from computers in either domain. Each domain can have its own accounts and resources. Global user accounts and global groups can be used from either domain to grant rights and permissions to resources in either domain.

Note

Using resources located on any domain, trusting or otherwise, is always subject to permissions associated with the resources.

Through File Manager, users from the trusted domain can be given rights and permissions to objects in the trusting domain, as if they were members of the trusting domain. Users in the trusted domain can browse resources in the trusting domain, subject to account privilege.

For example, suppose the London domain trusts the Topeka domain of a corporate network. User EmilyP, who is a member of the Topeka domain, wants to access Myfile.txt, which is a file located on a computer in the London domain running Windows NT Server. When EmilyP attempts to log on to the server in London, her user account information is not transferred to the London domain's user database. Because London trusts Topeka, the London domain has access to user information in the Topeka domain's user-account database.


Domain Security Policies

Windows NT Server and Windows NT Workstation settings can provide different levels of security for user actions on the domain or computer, respectively.

You can define three security policies that apply to the domain as a whole:

  • The Account policy controls how user accounts use passwords.
  • The Audit policy controls the types of events the security log records.
  • The Trust Relationships policy controls which domains are trusted and which domains are trusting domains. A trust relationship requires two or more single domains. This policy is available in a single-domain model (in which only one domain exists) only if the domain administering the computer is a domain controller.

The User Rights policy controls access rights given to groups and user accounts. User rights are applied at the domain level, and affect overall domain security.

For more information about the account policy, the audit policy, and the trust relationships policy, see "Managing Windows NT Server Domains" and for more information about the user-rights security policy, see "Working With User and Group Accounts," in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide


Computer Accounts and Secure Communications Channels

Each computer running Windows NT Workstation and Windows NT Server that participates in a domain has its own account in the directory database, called a computer account. A computer account is created when the computer is first identified to the domain (rather than to a workgroup) during network setup at installation or when the administrator uses Server Manager to define the computer account.

When a computer running Windows NT Workstation or Windows NT Server logs on to the network, the NetLogon service on the client computer creates a secure communications channel with the NetLogon service on the server. A secure communications channel exists when computers at each end of a connection are satisfied that the computer on the other end has correctly identified itself. Computers identify themselves using their computer accounts. When the secure communications channel has been established, a communications session can begin between the two computers.

To maintain security during the communications session, internal trust accounts are set up between the workstation and the server, between the primary and backup domain controllers, and between domain controllers in both domains of a trust relationship.

Computer accounts and the secure channels they provide enable administrators to remotely manage workstations and member servers. They also affect the relationships between a workstation and domain servers, and between primary and backup domain controllers.

The computer account is part of an implicit one-way trust relationship between the client computer and the controllers in its domain. Workstations request logon authentication for a user account from a domain server in the same way a server in a trusting domain requests validation from a server in a trusted domain. This trust relationship enables administrators to select a workstation or member server for administration in the same way they select a domain.

When the computer account is created, the Domain Admins global group is automatically added to the workstation or member server's Administrators local group. Domain administrators can then use Windows NT Server utilities to remotely manage the computer's user and group accounts, including adding global groups to the computer's local groups. Domain administrators can perform any functions on the computer itself that are allowed by the Administrators local group.

For Windows NT Server domain controllers, computer accounts link the BDCs with the PDCs and pair up trusting and trusted domains. Server trust accounts, created while setting up the secure communications channel, allow BDCs to copy the master directory database from the PDC. Interdomain trust accounts allow domain controllers in a trusted domain to pass through authentication of user accounts to the trusting domain.


Security in Mixed Operating System Environments

Windows NT Server has an open networking architecture that allows flexibility in communicating with other network products. Client computers running operating systems other than Windows NT Workstation or Windows NT Server can interact with computers in a Windows NT Server domain. However, they do not have domain computer accounts and, therefore, do not have Windows NT Workstation logon security. Users running other operating systems can have user accounts stored in the directory database, but the computer itself does not have logon security to restrict access to its own resources.

Computers running Windows NT Workstation or Windows NT Server can also interact with servers and clients running other operating systems. Various protocols and other software that allows interoperability are either included with Windows NT Server or are available separately.

Workgroup Clients

A workgroup is a collection of computers (not users) that form an administrative unit and do not belong to a domain. In a workgroup, each computer tracks its own user- and group-account information and — in contrast to domain controllers — does not share this information with other workgroup computers.

Workgroup members log on only to workstation accounts and can view directories of other workgroup members over the network.

Computers running Windows NT Workstation, Windows NT Server, Windows for Workgroups, or Windows 95 can be configured to participate in either a domain or a workgroup. When setting up one of these computers for networking, you specify a computer name and a workgroup name. If the workgroup name matches a domain name, the computer name appears in the browse list for that domain. The computer can browse computers running Windows NT Server and Windows NT Workstation that participate in either a domain or a workgroup. You can specify whether the computer will log on to a Windows NT Server domain or a workgroup when you set up Windows NT.

Windows 95 Clients

Access to Windows NT Server networking is built in to Windows 95. Users with domain accounts who run Windows 95 can log on to their accounts the same way users running Windows NT Workstation do. Windows 95 user-account logons can be validated by both Windows NT Server domain controllers and LAN Manager 2.x domain controllers.

MS-DOS Clients

MS-DOS client computers running one of the following components can use shared network resources on the respective servers:

  • Microsoft Network Client for MS-DOS version 3.0 enables computers running MS-DOS to interact with domain controllers running Windows NT Server and with computers running Windows NT Workstation or LAN Manager 2.x servers.
  • Microsoft LAN Manager for MS-DOS version 2.2 enables computers running MS-DOS to interact with LAN Manager 2.x servers and Windows NT Server domain controllers.

Because computers running MS-DOS cannot store user accounts, they don't participate in domains the way Windows NT computers do. Each computer running MS-DOS usually has a default domain for browsing. An MS-DOS user with a domain account can be set up to browse any domain, not merely the domain containing the user's account.

LAN Manager 2.x Servers and Clients

Windows NT Server interoperates with Microsoft LAN Manager 2.x systems. Computers running LAN Manager workstation software on MS-DOS, Windows 3.1, or OS/2 can connect to servers running Windows NT Server. LAN Manager 2.x servers (on computers running either OS/2 or UNIX) can also work with servers running Windows NT Server — even in the same domain.

Microsoft LAN Manager for OS/2 version 2.2 is a component of Windows NT Server that enables computers running OS/2 version 1.3x to interact with LAN Manager 2.x servers and computers running Windows NT Workstation and Windows NT Server. If an OS/2 version 1.3x system is running these components, it can share network resources with the respective servers.

Novell NetWare Clients

You can connect computers running Windows NT Server to NetWare file and print resources by using NWLink protocol software and Gateway Service for NetWare. You can also enable a gateway to share NetWare file and print resources with Microsoft networking clients without NetWare client software.

NetWare client computers can also connect to file and print resources and server applications on computers running Windows NT Server.

Macintosh Clients

Microsoft Windows NT Server Services for Macintosh is a component of Windows NT Server that enables Windows clients and Apple Macintosh clients to share files and printers. With Services for Macintosh, one computer running Windows NT Server can act as a server for both types of computer, and Macintosh computers can share resources with any client supported by Windows NT Server, including MS-DOS and LAN Manager client computers.


Logon and Authentication Processes

Before doing anything on a Windows NT system, a user must log on to the system by supplying a username and password. Windows NT uses the username for identification and password for validation. Different processes at several levels protect resources, but logon security protects overall access to a domain or computer. The logon process requires users to identify themselves to the domain or the computer. The user name and password that the user types in the Logon Information dialog box are checked against either the computer directory database (if the user is logging on to a user account defined on the computer) or the domain directory database (if the user is logging on to a domain user account).

Once authenticated, an account is available for use with all Windows NT Server network services and compatible server applications, such as the Microsoft BackOffice™ suite of server products. Through directory services, authentication enables a user logging on to a single Windows NT Server domain to use other applications, such as Microsoft SQL Server and Microsoft Exchange Server, and network services, such as Services for Macintosh.

The initial logon process for Windows NT is interactive, meaning that the user must type information at the keyboard in response to a dialog box that appears on the screen. Windows NT grants or denies access based upon the information the user provides.

The steps included in the interactive logon and validation process are:

1. The user presses Ctrl+Alt+Del.

2. When the user provides a username and a password, the logon process calls the LSA.

3. The LSA runs the appropriate authentication package.

4. The authentication package checks the user-accounts database to see if the account is local. If it is, the username and password are verified against those held in the user accounts database. If not, the requested logon is forwarded to an alternate authentication package.

5. When the account is validated, SAM (which owns the user-accounts database) returns the user's security ID and the security IDs of any global groups to which the user belongs.

6. The authentication package creates a logon session and then passes the logon session and the security IDs associated with the user to LSA.

7. If the logon is rejected, the logon session is deleted, and an error is returned to the logon process.

If the logon is not rejected, an access token, containing the user's security ID and the security IDs of Everyone and other groups, is created. It also contains the user rights (described in the next section) assigned to the collected security IDs. This access token is returned to the logon process with a Success status.

8. The logon session calls the Win32 subsystem to create a process and attach the access token to the process, thus creating a subject for the user account. (Subjects are described in the section called "Subjects and Impersonation," earlier in this chapter.)

9. For an interactive Windows NT session, the Win32 subsystem starts the desktop for the user.

After the validation process, a user's shell process (that is, the process in which the desktop is started for the user) is given an access token. The information in this access token is reflected by anything the user does or any process that runs on the user's behalf.

Note

Windows NT has the ability to support multiple authentication packages that are implemented as DLLs. This flexibility allows third-party software vendors the opportunity to integrate custom authentication packages with Windows NT. For example, a network vendor might augment the standard Windows NT authentication package by adding one that allows users to log on simultaneously to Windows NT and to the vendor's network.


Interactive and Remote Logon

Two logon processes can start logon authentication:

  • Interactive Logon
  • Remote Logon

Interactive Logon Authentication

Interactive logon occurs when the user types information in the Logon Information dialog box displayed by the computer's operating system. In Domain, the user selects either the name of a domain or the name of the computer being used for logon, depending on where the user account being logged on to is defined. If the computer is a member of a workgroup and not of a domain, the Logon Information dialog box does not have a place for typing in the domain name.

The following table compares the logon options for a user on a computer running Windows NT in a workgroup, in a domain, and in a domain with a trust relationship. The unique identifier used by Windows NT after logon depends on the location of the database used to log on the user. The third column in this table describes the unique identifier used in each case. Any network connection requests sent elsewhere on the network include this unique identifier.

Table 2.5 Summary of Interactive Logon Authentication

Computer is in | User can logon at | Unique identifier
Workgroup | Local database | Computername and username
Domain | Local database Domain database | Computername and username Domain name and username
Domain with a trust relationship | Local database Home domain database Trusted domain database | Computername and username Domain name and username Trusted-domain name and username
Domain without a trust relationship | Local database | Computername and username Untrusting-domain name and username

Remote Logon Authentication

Remote logon takes place when a user is already logged on to a user account and makes a network connection to another computer. For example, the user connects to another computer using the Map Network Drive dialog box or the net use command.

A security-access token created at interactive logon is assigned to the initial process created for the user. When the user tries to access a resource on another computer, the remote server authenticates the user again and creates a security-access token for the user. The security-access token is placed in a table stored on the remote server. The server creates a user identifier (UID) for the user and maps it to the user's security-access token. This UID is sent back to the client redirector and is used in all further server-message-block (SMB) communication between the server and client. Subsequently, whenever a request for any resource on that server (and not just in the same share)comes in from the client, the UID identifies the user to the server process. The server checks the table and uses the security-access token stored for the UID.

For example, if a user attempts to connect to \\Myserver\share, a table entry on \\Myserver is set up with the user's SID. This is mapped to the user's access token. Later, if the user attempts to access a share called \art on \\Myserver, the original table entry will be used. The server examines the user's SID, locates an existing table entry, and validates (or denies) access to the files by comparing the access-token information to the access rights of the user. The attempt is successful in this example because the user had already established read access with the connection to \\Myserver\share.

If the user attempts to update information on \\Myserver\art and does not have write access to the share, access is denied. Even if the user is added to a group with write permissions, access will be denied because the one table entry still contains static information about the user's SID. The user must log off and log on again to create a new table entry. Then, the user will be able take advantage of the group's write permissions.

The server process creates a SID for the user and maps it to the user's security-access token. This SID is sent back to the client redirector and is used in all further server message block (SMB) communication between the server and client. Whenever a resource request comes in from the client, the SID identifies the user to the server process. The security-access token that maps to the user ID identifies the user to the remote security subsystem.

Figure 2.2 Remote logon authentication

The steps in a successful remote logon at a computer running Windows NT Workstation or Windows NT Server are:

1. The client computer sends the username, password, and domain name (the data entered in the Begin Logon dialog box) of the user to the remote Windows NT server.

2. The authenticating server compares the logon username and password with information in the user-accounts database.

3. If access is authorized, the server's LSA constructs an access token and passes it to the server process, which creates a user ID that refers to the access token.

4. The user ID is then returned to the client computer for use in all subsequent requests to the server.

After the session has been created, the client computer sends requests marked with the user ID it received during session setup. The server matches the user ID with the access token in an internal table. This access token at the server is used for access authentication.

The steps in a successful, remote logon at a Workgroup computer connecting to a computer running Windows NT in a domain are:

1. The local directory database performs interactive logon for the user at the workgroup computer (the client).

2. The client's username and a function of the password are passed to the specific server in the domain to which the client is trying to connect. This server checks the username and password with information in its local directory database. If there is a match, access to this server is allowed.

The steps in a successful remote logon at a domain computer connecting to a computer running Windows NT in the same domain are:

1. The domain's directory database performs interactive logon for the user at the client computer.

2. The client's domain name, username, and a function of the password are passed to the computer being accessed, which passes them to a computer running Windows NT Server in the domain.

3. The computer running Windows NT Server verifies that the domain name for the client matches this domain.

4. The computer running Windows NT Server checks the username and password against the domain's directory database. If there is a match, access is allowed.

The steps in a successful remote logon at a domain client in a trusted domain connecting to a Windows NT computer are:

1. The domain's directory database performs interactive logon for the user at the client computer.

2. The client's domain name, user name, and a function of the password are passed to the computer being accessed. That computer passes the logon information to a Windows NT Server in the domain.

3. The computer running Windows NT Server verifies that the client's domain is a trusted domain and then passes the client's identification information to a computer running Windows NT Server in the trusted domain.

4. A computer running Windows NT Server in the trusted domain (that is, in the same domain as the client computer) checks the user name and password against the domain's directory database. If there is a match, access is allowed.


The NetLogon Service

The NetLogon service provides users with a single access point to a domain's PDC and all BDCs.

The NetLogon service also synchronizes changes to the directory database stored on the PDC to all domain controllers. The size of the directory database is limited only by the number of registry entries permitted and by the performance limits of the computer.

The Windows NT Server NetLogon service automatically synchronizes the directory database. Based on settings in the registry, the PDC sends timed notices, which signal the BDCs to request directory changes from the PDC. The notices are staggered so that not all BDCs request changes at the same time. When a BDC requests changes, it informs the PDC of the last change it received, so the PDC is always aware of which BDC needs changes. If a BDC is up-to-date, the Net Logon service on the BDC does not request changes.

The Change Log

Changes to the directory database consist of any new or changed passwords, new or changed user and group accounts, and any changes in the associated group memberships and user rights.

Changes to the domain-directory database are recorded in the change log. The size of the change log determines how long changes can be held. The default NetLogon-service setting for updates is every five minutes, and the change log holds about 2,000 changes. As a new change is added, the oldest change is deleted. When a BDC requests changes, the changes that occurred since the last synchronization are copied to the BDC.

The change log keeps only the most recent changes. If a BDC does not request changes in a timely way, the entire domain directory database must be copied to that BDC. For example, if a BDC is offline for a time, more changes could occur during that time than can be stored in the change log.

Partial and Full Synchronization

Partial synchronization is the automatic, timed replication to all domain BDCs of directory database changes that have occurred since the previous synchronization.

Full synchronization is copying the entire directory database to a BDC. Full synchronization is automatically performed when changes have been deleted from the change log before replication takes place or when a new BDC is added to a domain.

The default NetLogon-service setting for update timing (every five minutes) and the size of the change log (about 2000 changes) ensure that full synchronization will not be required under most operating conditions.

The NetLogon service accepts logon requests from any client and provides complete authentication information from the directory database.

The NetLogon service runs on any Windows NT computer that is a member of a domain and requires the Workstation service. It also requires the Access This Computer from Network right, which is set in User Manager on computers running Windows NT Workstation, or in User Manager for Domains on domain controllers. A domain controller also requires that the Server service be running.

User Authentication

On a computer running Windows NT Workstation or a computer that is not a domain controller running Windows NT Server, the NetLogon service processes logon requests for the local computer and passes through logon requests to a domain controller.

The NetLogon service processes authenticates a logon request in three steps:

1. Discovery.

2. Secure channel setup.

3. Pass-through authentication (where necessary).

Discovery

When the computer starts up, it must determine the location of a domain controller within the domain and in each trusted domain. (There is an implicit trust between the workstation and domain controllers in the workstation's own domain.)

Locating the domain controller is called discovery. If the computer is part of a workgroup, rather than of a domain, the NetLogon service terminates. (If the workstation is not connected to a network, Windows NT treats it like a member of a workgroup consisting of one member.) Once a domain controller is discovered, it is used for subsequent user-account authentication.

When a domain controller starts up, the NetLogon service attempts discovery with all trusted domains. Discovery is not necessary on the domain controller's own domain, because it has access to its own directory database. Each domain is called three times in intervals of five seconds before discovery fails. If a trusted domain does not respond to a discovery attempt, the domain controller attempts another discovery every 15 minutes until it locates a domain controller on the trusted domain.

If the domain controller receives another request for authorization before discovery is successfully completed, it immediately attempts another discovery, no matter when discovery was last attempted.

Secure Communication Channel

The Net Logon services from each computer issue challenges to and receive challenges from every other computer, to verify the existence of their valid computer accounts. When verification is complete, a communication session is set up between the computers and used to pass user-identification data.

The NetLogon service maintains security on these communication channels by using user-level security to create the channel. The following special internal-user accounts are created:

  • Workstation trust accounts, which allow a domain workstation to perform pass-through authentication for a computer running Windows NT Server in the domain, as described later in this chapter.
  • Server trust accounts, which allow computers running Windows NT Server to get copies of the master-domain database from the domain controller.
  • Interdomain trust accounts, which allow a computer running Windows NT Server to perform pass-through authentication to another domain.

The NetLogon service attempts to set up a secure channel when it is started and discovery is complete. If it fails, NetLogon retries every 15 minutes or whenever an action requiring pass-through authentication occurs. To reduce network overhead for trusted domains, the NetLogon service on a domain controller creates a secure channel only when it is needed.

The first time a user logs on to a domain account from a given workstation, a domain controller downloads validated logon information (from the domain directory database) to the workstation. This information is cached on the workstation. If a domain controller is not available on subsequent logons, the user can log on to the domain account using the cached logon information.

Computers running Windows NT Workstation and Windows NT Server store the information authenticating the last several (the default number is ten) users who logged on interactively. The credentials for users who log on to the local computer are also stored in that computer's local directory database.

Pass-through Authentication

Pass-through authentication occurs in the following cases:

  • Case 1: An interactive logon in which a user logs on to a computer running Windows NT Workstation or to a computer running Windows NT Server as a member server, and the name in Domain in the Logon Information dialog box is not the computer name.
  • Case 2: An interactive logon in which the computer being logged onto is a domain controller but the name in Domain is not the domain to which the controller belongs.
  • Case 3: A remote logon (connecting to a computer over the network).

Note

If the logon computer is not running Windows NT Workstation or Windows NT Server, domain controller authentication has no effect on the user's ability to use resources on the logon computer.

In case 1, the logon computer sends the logon request to a domain controller in the domain to which the computer account belongs. The controller first checks the domain name. If the domain names matches the controller's domain, the controller authenticates the logon credentials against its directory database and passes the account-identification information back to the logon computer, allowing the user to connect to resources on both the logon computer and the domain.

If the domain does not match the controller's domain, the controller checks whether the domain is a trusted domain. If it is, the domain controller passes the logon request through to a domain controller in the trusted domain. That domain controller authenticates the username and password against the domain directory database and passes the account-identification information back to the initial domain controller, which sends it back to the logon computer.

If the logon credentials supplied match the account-identification information, logon succeeds. If not, logon fails.

In case 2, the controller checks the domain name to see if it is a trusted domain. (The domain controller does not check for computer name because its directory database contains only domain accounts). If the domain is a trusted domain, the controller passes the logon information to a domain controller in the trusted domain for authentication. If the trusted domain controller authenticates the account, the logon information is passed back to the initial domain controller, and the user is logged on. If the account is not authenticated (is not defined in the trusted domain directory database), the logon fails.

If, in case 3, the user is logged on to a computer or domain account and then tries to make a network connection to another computer, pass-through authentication proceeds as in interactive logons. The credentials used at interactive logon are also used for pass-through authentication unless the user overrides those credentials by typing a different domain or computer name and user name in a dialog that appears under the following circumstances:

  • When the user types an entry in Connect As in the Map Network Drive dialog box.
  • When the user clicks Start, clicks Run, and types the UNC path at the prompt, using the syntax \\Servername\sharename.

The figure below illustrates pass-through authentication. In this example, AnnM wants to access a computer in the London domain. Because the London domain trusts AnnM's home domain, Topeka, it asks the Topeka domain to authenticate AnnM's account information.

Figure 2.3 Pass-through authentication

If the user tries to make a network connection to a remote computer in an untrusted domain, the logon proceeds as if the user were connecting to an account on the remote computer. That computer authenticates the logon credentials against its directory database. If the account is not defined in the directory database but the Guest account on the remote computer is enabled, and if the Guest account has no password set, the user will be logged on with guest privileges. If the Guest account is not enabled, the logon fails.

For information about the Guest account, see the Microsoft Windows NT Server 4.0 Concepts and Planning Guide, Chapter 2, "Managing User and Group Accounts."

If the computer being connected to is a BDC in the domain in which the user account is defined, but the BDC fails to authenticate the user's password, the BDC passes through the logon request to the PDC in the same domain. For example, this happens if authentication is attempted after the password changes but before the BDC synchronizes with the PDC.

Figure 2.4 Passthrough authentication in Windows NT


Interdomain Trust Accounts

When one domain is permitted to trust another, User Manager for Domains creates an interdomain trust account in the directory database of the trusted domain. A trusted-domain object is created in the LSA of the trusting domain, and a secret object is created in the LSA of the trusting domain. This account is like any other global user account, except that the USER_INTERDOMAIN_TRUST_ACCOUNT bit in the control field for the account is set. The interdomain trust account is used only by the primary domain controller and is invisible in User Manager for Domains. The password is randomly generated and is maintained by User Manager for Domains.

When this trust relationship is established, the NetLogon service on the trusting domain attempts discovery on the trusted domain, and the interdomain trust account is authenticated by a domain controller on the trusted domain.

Similar accounts and procedures are used in the trust relationships between a PDC and a BDC, and between a domain controller running Windows NT and a computer running Windows NT Workstation in that domain.

In the following example, the trusted domain is referred to as Master and the trusting domain is referred to as Resource. The Master contains the user account information; the Resource trusts the Master to validate user access to its resources.

On each domain controller in RESOURCE, an LSA trusted-domain object represents the trust. This object contains the name of the trusted domain and the domain SID. The LSA trusted-domain object is replicated from the trusting domain PDC to each of the BDCs in the trusting domain.

On each domain controller in RESOURCE, a password is stored in an LSA secret object G$$<TrustedDomainName>, such as G$$MASTER. This object is stored in the registry key

HKEY_LOCAL_MACHINE\Security\Policy\Secrets

The LSA secret object for the trusted-domain trust relationship is replicated from the PDC in the trusting-domain to each of the trusting-domain BDCs.

On each domain controller in MASTER, the password is stored in the directory database user account marked as INTERDOMAIN_TRUST_ACCOUNT, such as RESOURCE$. This can be viewed in the registry path \SAM\SAM\Domains\Account\Users\Names

(HKEY_LOCAL_MACHINE subtree)

This account is replicated from the trusted-domain PDC to each of the trusted-domain BDCs.

These accounts are created when a trust is established. The administrator of the trusted domain, MASTER, permits RESOURCE to trust the MASTER accounts. When the domain is added in User Manager to the Trust Relationships dialog box, a hidden user account is created in the directory database for use by the trusting domain. The account contains the specified password, such as RESOURCE$.

For details on how to set up a trust relationship see "Managing Windows NT Server Domains" in Microsoft Windows NT Server 4.0 Concepts and Planning and online Help.

The administrator of the trusting domain establishes the trust. The administrator provides the password specified earlier, and User Manager creates the LSA secret object. The server in RESOURCE attempts to setup a session with the domain controller in MASTER, using the password RESOURCE$. The domain controller in MASTER responds with the error "0xc0000198, Status_Nologon_Interdomain_Trust_Account" because the special Interdomain Trust Account cannot be used in a normal session logon, and the session fails.

This error informs the domain controller in the RESOURCE domain that the trust account exists and a trust is possible. Upon receiving that response, it establishes a null session and then uses remote-procedure-call (RPC) transactions to call the remote APIs that establish the trusted domain relationship. A secure channel is set up later by the NetLogon service, using the trust information that was stored by the User Manager.

After the trust is established, the RESOURCE PDC changes the password for the trusted-domain object. All domain controllers in each domain receive the trust account objects through normal domain synchronization of the directory and the LSA databases. The domain controllers in RESOURCE receive the LSA secret object during the update of the LSA database, and the domain controllers in MASTER receive the account in the directory-database update. With these objects, any domain controller in the trusting domain can set up a secure channel to any domain controller in the trusted domain.

Maintenance of these accounts includes periodic password changes. Every seven days, the PDC of the trusting domain automatically changes the password of the trusted domain object by the following steps.

1. Setting the OldPassword field of the LSA secret object to the previous NewPassword field.

2. Selecting a new password.

3. Setting the NewPassword field in the LSA secret object to the selected password.

This ensures that the domain controllers can always access a valid password in the event of a crash.

4. Sending an I_NetServerPasswordSet RPC call to a domain controller of the trusted domain, asking it to set the password in the directory-database-user trust account to the value of the NewPassword field in the LSA secret object of the trusting domain. The trusting PDC sends the RPC call to the trusted domain controller with which it established the secure channel. That domain controller passes the request through to the trusted PDC.

The password is now changed on both PDCs. Normal replication distributes the objects to the BDCs.

A domain controller of the trusted domain (MASTER) never initiates the password change. It is always initiated by the trusting domain PDC. Initiating the password change requires that the secure channel has been set up.

It is possible, but not likely, that the trusting domain controller will change the password without updating a domain controller in the trusted domain. For example, this might happen if the trusted domain controller failed during the process and did not received the updated password. As a safeguard, both the old and new passwords are kept in the LSA secret object on the trusting side. The PDC in the trusting domain never changes the new password unless it has successfully set up a secure channel using the current new password. If the secure-channel setup fails because the new password is invalid, the trusting PDC tries the old password. If a secure channel is established using the old password, it immediately (within 15 minutes) continues the password change algorithm with step 4 (above).


Planning Your Domain Design

The three domain models, single domain, single master domain, and multiple master domain, make use of trust relationships. The trust relationships provides flexibility. For detailed information about the three domain models, see "Managing Windows NT Server Domains" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.

The domain model you select should match the way you want to manage your organization. The number of users in the organization, the topology, and the location will also influence how domains will be designed, implemented, and where the resources will be located. Because there are few limits imposed by Windows NT software, other aspects of the computing environment must be considered to provide guidelines for the decisions you make about your domain model.

The following assumptions are made:

  • Unlike the Windows NT Server software, server hardware imposes limits on the number of users or sessions it can support.

Unless otherwise noted, it is assumed that the Windows NT Server to be used as the PDC is a 486/33 machine (or higher) with 32 MB of physical RAM and a 1 GB hard disk. Test conditions at Microsoft included base Windows NT Server services, moderate file and print activity, Remote Access Service, SNA Server, and SQL Server.

  • Real-life limits of the Windows NT Server system often go beyond the capacity of the server.
  • The process of design and selection is recursive.

Decisions made earlier in the process must be verified in light of information available later in the process. Therefore, you should anticipate making several passes through the process until all decisions at all steps match the available information.

There are many ways to implement your domain model. The following examples illustrate some of the flexibility of domains. These examples are followed by a list of business and equipment considerations that can affect your domain design.


Multiple Independent Lines of Business

Corporation with independent lines of business, such as a consulting division, a real estate division, and a retail sales division, may have separate marketing, sales, and data-processing groups within each of those divisions. At the center of the firm is a small group focused on functional services, such as accounting, finance, and human resources. Usually, users in a division need to access only the resources in their own division. There are times when an employee needs access to resources in another division, which requires that the master domains connect to each other.

Figure 2.5 Multiple Independent Lines of Business domain model

A multiple master-domain model is the best choice for this case because the organization lacks a data-processing staff in its central division. The domain model can be constructed to acknowledge the data-processing autonomy of divisions as they exist. Trust relationships can be created between the master domains, as necessary.


A Large Organization

A large firm (approximately 100,000 employees) may have multiple locations. By using master domains, the number of users per master domain can be as high as 40,000 because the machine accounts are kept in the resource domains. The company can create three master domains of approximately 33, 000 users each or, to accommodate growth of the user base, four master domains of approximately 25,000 users each.

Figure 2.6 Large Organization domain model

The domain in which a user is defined can be based on any grouping or sequencing, such as alphabetical, divisional, departmental, or by location. Which domain is used in defining a particular user is unimportant because a trust relationship exists between each resource domain and each master domain.


Branch Offices

In a branch office, a single domain or single-master domain can usually be used. Companies with many small branch offices can group branch offices together into regional domains that will provide administration for the branches.

When the branch office is linked to the PDC by means of a communications link or modem, a BDC would be the on-site server. The BDC handles local authentication and local file and print services. A second BDC can be added for fault tolerance.

Figure 2.7 Branch Offices domain model


Secure Domains

In the multiple master-domain model, all master domains are linked to each other by trust relationships. Users in all domains can then access resources in any domain. However, some records should not be available for all employees to access, such as confidential financial records and personnel files. The solution is to create domains that are exclusively for the departments with confidential records, such as Finance and Human Resources. Those domains are trusted by the master MIS domain, but they do not trust other domains. Finance and HR users can then access MIS resources, but their own resources remain secure.

Figure 2.8 Secure domain model


Management and Administration Considerations

Windows NT enables you to manage user accounts either centrally or decentrally. With centralized management, there is usually one directory database and, therefore, one master domain, in which all user-account information is stored. Users are defined on the network only once and are given access permissions to resources based on their logon identity in the central user database. The single-domain model and single master-domain models are centrally managed. A multiple master-domain model can also be centrally managed by adding designated administrators to appropriate Admin groups.

With decentralized management, more than one directory database contains information about different user accounts in the organization. You can create trust relationships to enable domains to access resources in other domains. The multiple master-domain model and the single-domain models can use decentralized management.

In planning your domain model, you'll need to establish administrative policies and procedures for how you will:

  • Manage and monitor domains and accounts.
  • Manage and monitor resources.
  • Establish addressing and naming conventions.


Location Considerations

The two most important location considerations are where to locate the BDCs that will act as account logon servers and how to plan account-synchronization traffic across wide area network (WAN) links. If your WAN speed or bandwidth is low, you will want users to log on at a local BDC.

The next consideration is whether your networked organization is in one site or in several sites, connected by WAN links. A site is a well-connected LAN and may communicate by fast links, such as bridges and routers, but not by asynchronous WAN links, such as T1, 56K, or ISDN. Sites generally correspond to physical locations, such as Seattle, Paris, and New York.

The physical distribution of BDCs is determined by several factors: line speed, link reliability, administrative access, protocol, user-authentication requirements, the number of users to be supported at a site, and locally available resources.

The diagram below shows part of a network topology that one of these domains services. The networked hub sites in London, Paris, and Warsaw, which all belong to a European domain.

Figure 2.9 Locating domain controllers

The European PDC is in London, which is the network's main hub to Europe. The European PDC replicates to the BDCs at each site, including New York.


Synchronization over WAN and Remote Area Service

Consideration should be given to the amount of traffic that account synchronization places on WAN or Remote Access Service (RAS) dial-up lines. Avoid full synchronizations across WAN links. Full synchronizations are required when first setting up a new PDC or bringing a new location online. Full synchronizations are also initiated when more than 2,000 changes happen to users or groups within a short time (less than one hour). If you anticipate high change activity, you can increase the value for the size of the change log. If the above conditions do not exist, the synchronization process will include only the changes made in the directory database since the last time synchronization occurred.

BDC Over a RAS Link

A BDC can be connected to a remote domain using Windows NT, a modem, and the Windows NT Server RAS.

Using a RAS-connected BDC as a PDC

If a RAS-connected BDC is expected to be promoted to PDC at some time when it is remotely connected to the domain, this BDC should be set up as a dial-out-only RAS client (RAS is not running on this computer). If you promote the RAS-connected client, NetLogon stops, changes roles, and restarts. RAS depends on NetLogon, so when NetLogon stops, you would lose your connection. By having the RAS client dial-out services on this remote BDC, it can function as a PDC because that functionality does not depend on NetLogon running constantly. If neither the RAS server (which could also be a BDC) nor the RAS-connected BDC are ever expected to serve as PDC, this is not an issue. A RAS-connected BDC that has been promoted to PDC will function as it should, but may respond more slowly, depending on line speed.

Partial Synchronization with a RAS-connected BDC

The default value for ChangeLogSize should be increased if either of the following conditions exist:

  • A remote site has a RAS-connected BDC that dials in nightly to do a partial synchronization of any changes.
  • Daily changes to the SAM/LSA database sometimes exceed 2,000.

Changing the default log size may also be necessary if many changes occur while a BDC is off-line. Otherwise, that BDC may be forced to do a full synchronization of the database.

If few changes occur during the time a BDC is not connected to the PDC, then the default size is sufficient. If an administrator notices a BDC doing full synchronizations, then it is probably a good idea to increase the ChangeLogSize. The default value for ChangeLogSize is 64K, which handles approximately 2,000 changes.

Calculating Replication Times

Managing the amount of network traffic so that response time remains acceptable is an important part of administration. When the PDC is located across a WAN or modem link, you can estimate the amount of traffic and time needed to replicate directory database changes to and from the PDC and then schedule this traffic to meet the needs of the site. The following chart helps you calculate the time needed for replication:

 | Factors |
Password changes per month | Number of user accounts | A
 | Passwords expire in how many (calendar) days | B
 | Divide B by 30 | C
 | User account changes A + C | D
Additional changes per month | If number not knows, use 5% of D | E
 | New user accounts | F
 | Group changes * 4 | G
 | New machine accounts * 5 | H
Amount of data to be replicated per month | D + E + F + G + H | I
Total monthly replication time | Compute throughput; modern/line speed in bps, If in KB, multiply by 1024 (i.e. 56KB = 57344 bps) | J1
 | J1 * 8 bits/bytes = | J2
 | J2 * 60 sec./min. = | J3
 | J3 * 60 min./hour = total throughput | J
 | I/J = total replication time (hours/month) | K

Figure 2.10 Job Aid to Calculate Monthly Replication Time


Security Considerations and C2 Security Rating

The National Computer Security Center (NCSC) was formed to help businesses and home users protect proprietary and personal data. The first goal of the NCSC was to create a document containing the technical standards and criteria to be used in evaluating computer systems. The NCSC also established a process by which software venders such as Microsoft could submit their security-related products for evaluation.

NCSC Security ratings range from "A" to "D," in which "A" represents the highest security. The "C" rating is generally applied to business software. Each rating is further divided into classes. For example, in the "C" division, software may be rated either "C2" or "C1," with "C2" representing the higher security. The most important feature requirements for operating systems rated "C2" focus on the following features.

  • Discretionary access and control
  • Identification and authentication
  • Auditing
  • Object reuse

An operating system must be able to define and control its users' access to objects (such as files and directories), provide a way for users to uniquely identify themselves, provide a way to audit security-related events and actions of individual users, and protect one process from accessing the data for another process.

For discretionary access and control, Windows NT enables an administrator or user to determine who can access files and how those files will be accessed. Other uses of Windows NT can be controlled, such as access to printers and network-server sharepoints.

Identification and authentication in Windows NT is achieved through the logon Secure Attention Sequence. All users must log on to start Windows NT. When a Windows NT users type their usernames and passwords to log on locally, they must first press Control+Alt+Delete to verify that no Trojan Horse programs are present. (A Trojan Horse is a program that can capture a user's logon information, thereby providing network access.) Because each user has a unique user name, domain name, and password combination, Windows NT can assure a user's unique identity.

Using Windows NT, a system administrator can audit all security events and user actions. The User Manager enables an administrator to specify which events (such as logon or file access) will be monitored. All audited information is stored in the Event Log, which can be viewed in Event Viewer.

One of the important issues in software security is object reuse. In a secure operating system, such as Windows NT, all allocation and deallocation of objects (such as files, directories, and memory) must be protected. Only users with proper access permissions should be allowed access. In Windows NT, this is achieved through a robust object manager that either initializes or zeros out objects before presenting them to a user.

The process of software evaluation is comprehensive. The NCSC evaluation is based on a series of standards published in the "Orange Book." Additional documents cover the evaluation process and are collectively referred to as the "Rainbow Series."

Microsoft Windows NT C2 Evaluation

The evaluation process begins when a software vendor presents a proposal to the NCSC, requesting the evaluation process. If approved, the software vendor must demonstrate to the NCSC that the product design and supporting documentation are complete. If satisfied, a team of NCSC evaluators are assigned to evaluate the new product. The most time-consuming part of the process is the evaluation itself. As part of the evaluation, the NCSC evaluators look at each aspect of the system to confirm that security has been properly implemented and to assess that security-testing of the system is complete. Once satisfied, the software is presented to the NCSC Technical Review Board for final approval. If approved, an entry is placed on the Evaluated Products List, indicating the success. The NCSC evaluation team releases a Final Evaluation Report, which covers all evaluated aspects of the software.

Microsoft began the process of the Windows NT Platform evaluation in 1991. In July 1995, Microsoft met its first milestone: a C2 Orange Book listing of the base operating system of the Windows NT Platform version 3.5 (with Service Pack 3).

The Windows NT operating system also received NCSC recognition for two B-level features: B2 Trusted Path and B2 Trusted Facility Management.

  • The Trusted Path functionality prevents Trojan-horse programs from intercepting username and password information during initial logging on.
  • The Trusted Facility Management functionality Windows NT supports separate account roles for operator and administrator functions.

For example, Windows NT provides separate administrative roles for Administrators, users tasked with backups, users tasked with administrating printers, privileged Power Users, and Users.

Microsoft is currently involved in evaluating the Windows NT Platform version 4.0 to obtain the rating of C2 in a homogeneous networked environment. The NCSC publication "Trusted Network Interpretation," also called the "Red Book," serves as an interpretation of the Orange Book, as it applies to networking for this evaluation.

The typical NCSC security-evaluation cycle takes longer than the product release cycle of Windows NT. No significant changes have been made to the Windows NT security model from version 3.5 to versions 3.51 and 4.0.

The United Kingdom and Germany have an evaluation process similar to the one in the United States. This is the Information Technology Security Evaluation Criteria (ITSEC). In 1996, the Windows NT version 3.51 platform (in a homogeneous network environment) will complete its first ITSEC evaluation. Windows NT version 3.51 is seeking a C2 rating with an assurance rating of E3. In an ITSEC evaluation, the assurance rating given to a product indicates the level of analysis and supporting documentation used in developing the product. The greater the assurance rating, the higher the assurance. An E3 rating is typically mapped to the level of analysis performed in a "B" level evaluation.

In the Windows NT Final Evaluation Report, the NCSC security evaluators wrote, "One of the major initial design goals for Windows NT was to assure C2-level security through an integral, uniform protection mechanism. All system resources are treated as objects, and thus a single security 'gate' can be the protection component that all users must pass through to acquire system resources.

"This results in much greater assurance that the system meets the applicable security criteria, because a single security mechanism is easier to understand and to verify then multiple ad hoc mechanisms. When security is not an absolute requirement of the initial design, it is virtually impossible through later add-ons to provide the kind of uniform treatment to diverse system resources that Windows NT provides."

For more information on the security design of Windows NT, see Microsoft Windows NT 3.5 Guidelines for Security, Audit, and Control, published by Microsoft Press, and the Microsoft Web Server.


Domain-naming Conventions

When planning your domain, consideration needs to be given to the names of the domains. Once implemented, it is recommended that domain names not change. Changing domain names requires the reinstallation of every server that belongs to the renamed domain. For clarity, use domain names that reflect of the general business areas they serve.

Group-naming and Assignment Conventions

A corporation could create a global group for every resource domain. That group could include all those who use that domain as their primary resource base. Other global groups could be created for all departments or locations, and the members of each department could automatically be made members of their department groups. The group name should reflect the domain and the department For example, a Microsoft department in England might be named Mic-UK. Other groups may be created for job categories, such as Mic-UK-Managers.

Username Conventions

Ideally, one user ID and password would allow access to all of a user's resources. Microsoft Client Services for NetWare passes Windows NT usernames and passwords to NetWare. To take advantage of this, set up a user account on NetWare with the same account name and password as in Windows NT. Banyan VINES systems can also be configured in this way by setting the VINES username and password to match the ones in Windows NT and NetWare. Upon logging on, the user will also be logged on to VINES.

For details about configuring for Banyan VINES on a Windows NT network, see Chapter 5, "Network Services: Enterprise Level."

If the user's password cannot be sent to other systems, the next best thing is to have a consistent full-name property within each company organization.


Tools and Checklists for Domain Planning

For ease of administration, the preferred domain model is the single-domain model. If the single-domain model can not be used, the second choice should be the single master-domain model. If neither of these is acceptable, an administrator can use trust relationships to centralize all user administration into a single domain, eliminating the need to administer each domain separately.

The following sections contain tools and checklists to help you choose the proper domain model for your organization.


Domain Selection Matrix

It is useful to view the characteristics of the domain models side by side, to match the characteristics and benefits of each implementation model to the needs of your organization. If the needs of your organization change, you can review this matrix to determine the optimal implementation model.

If you have already established an implementation model, it is a good idea to review the following chart to see the benefits or trade-offs of other domain models.

Table 2.6 Domain Selection Matrix

Domain Attribute | Single Domain | Single Master Domain | Multiple Master Domain | Independent Single Domains with Trust relationships
Fewer than 40,000 users per domain | X | X | X |
More than 40,000 users per domain |  |  | X |
Centralized account management | X | X |  |
Centralized resource management | X |  | X | X
Decentralized account management |  |  | X | X
Decentralized resource management |  | X | X |
Central MIS | X | X |  |
No central MIS |  |  |  | X

*User account numbers are approximate. The exact SAM file size is dependent on the number of user accounts, computer accounts, and group accounts.


Location Considerations Checklist

Determine the location of the user community using the following checklist.

  • Where will users log on?

Ensure adequate access to an authenticating BDC.

  • Do users need to be able to log on from more than one location?

If so, their accounts cannot be tied to a location. Consider using a single master-domain or multiple master-domain model.

  • What resource availability is required?
  • Does a user need to be able to log on even when the WAN to the central location is down?

Or, is all data central, so that no local processing can be done without the WAN?

  • How fast are the WAN links?

The speed of the links needed between locations should be determined by the resource usage across the links and by the frequency of changes to settings for users and groups.


Hardware Requirements

When selecting a computer for use as a PDC or BDC, use the hardware guidelines in Table 2.7, below. The table assumes that the computers will function only as PDCs and that no other major Windows NT operations will occur, such as moderate file server, SQL server, SNA server, and remote access server. All numbers are in megabytes (MB) and it is assumed that the computer's pagefile size is at least 250 MB.

Table 2.7 Domain Controller Hardware Requirements

SAM Size | Registry Size | Paged Pool | Minimum CPU Needed | Pagefile | RAM
5 | 25 (default) | 50 (default) | 486dx/33 | 32 | 16
10 | 25 | 50 | 486dx/33 | 64 | 32
15 | 25 | 50 | Pentium, MIPS, Alpha AXP | 96 | 48
20 | 30 | 75 | Pentium, MIPS, Alpha AXP | 128 | 64
30 | 50 | 100 | Pentium, MIPS, Alpha AXP | 256 | 128
45 | 75 | 128 | Pentium, MIPS, Alpha AXP | 332 | 166
60 | 102 | 128 | SMP | 394 | 197
75 | 102 | 128 | SMP | 512 | 256

For more information, refer to Large Domain Testing Overview, available from Microsoft Product Support Services.


Number of Domains Necessary

The number of users in a domain is a function of the size of the directory database. Figure 2.11 can help you determine the number of domains you need. The single-domain model and the single master-domain model can accommodate at least 26,000 user accounts if both user accounts and computer accounts are stored in the database.

Built-in local groups for a domain include Administrators, Domain Admins, Users, Domain Users, Guests, Domain Guests, Account Operators, Backup Operators, Print Operators, Server Operators, and Replicator.

 | Factors |
Calculating SAM database size | Number of users, multiply by 1KB | A KB
 | Number of machines , multiply by 0.5KB (workstations, servers, printers, etc.) | B KB
 | Number of custom groups, multiply by 4 KB | C KB
 | Built-in local groups | D 44KB
 | Total SAM size: A + B + C + D = | E KB
 | Convert SAM size to MB, multiply E by .001024 | F
 | Minimum # of domains = F / 40* (round up to the next whole number |

* Maximum recommended SAM Database size is 40 MB.

Figure 2.11 Job aide to calculate the number of master domains


Number of Trusted Domains

In the multiple master-domain model, user accounts are stored in master domains, and resources (machine accounts) are stored in all other domains. In this model, each resource domain trusts all master domains with a one-way trust.

On each domain controller in the resource domain, the existence of the trust relationship is represented by an LSA trusted-domain object. The object contains the name of the trusted domain and the domain security identifier (SID). The password associated with the trust link is stored in a LSA secret object, which is stored in the following registry key.

HKEY_LOCAL_MACHINE\Security\Policy\Secrets

In the Windows NT operating system, LSA secrets are used for other things and, until this version, the number of LSA secrets was fixed at 256. As a result, the recommended limit for trusted master domains was 128 per resource domain. This recommendation has been removed with the introduction of Windows NT 4.0 because the number of available LSA secrets has been significantly increased.

The second restriction limiting the number of master domains trusted by the resource domains is the nonpaged pool size of the domain controllers on which the resource domains are stored. When a domain controller starts, it attempts to discover domain controllers in each trusted domains by sending a message to each trusted domain. Each domain controller in the trusted domains responds with a message to the starting domain controller. The response is temporarily stored in the nonpaged pool until NetLogon can read it.

The RAM on your Windows NT computer is divided into two categories: nonpaged and paged. Nonpaged must stay in memory and cannot be written to or retrieved from peripherals. Peripherals include disks, the LAN, CD-ROMs, and other devices. Paged memory is RAM that the system can use and later reuse to hold different pages of memory from peripherals.

For more information on memory, see the Microsoft Windows NT Workstation Resource Guide, Chapter 12, "Detecting Memory Bottlenecks."

Windows NT Server 4.0 provides a default nonpaged pool size, which provides for a substantially higher number of trusted domains than earlier versions did. Table 2.8, below, lists the default nonpaged-pool size that is configured when Windows NT Server is installed on computers with different amounts of physical memory. The table also shows the recommended maximum number of trusted domains that will operate, based on the specified nonpaged pool size.

Table 2.8 Trusted domains needed for nonpaged-pool sizes

Nonpaged Pool Size | # of Trusted Domains | Total Physical Memory
1.2 MB | 140 | 32 MB
2.125 MB | 250 | 64 MB
4.125 MB | 500 | 128 MB

Calculating Required Nonpaged and Paged Pool Sizes

Nonpaged and paged pool sizes are calculated from the physical memory on the computer when it starts up. Although the default nonpooled size is sufficient in most cases, you can approximate the values for an X86-based computer if you find it is necessary to change the nonpaged and paged pool size of your computer.

Table 2.9 Terms and values used to calculate the nonpaged pool size

Term | Value
Minimum Nonpaged Pool Size | 256K
MinimumAdditionNonPagedPoolPerMb | 32K
DefaultMaximumNonPagedPool | 1MB
MaximumAdditionNonPagedPoolPerMb | 400K
Pte_Per_Page | 1024
Page_Size | 4096

Calculating Nonpaged Pool Size

NonPagedPoolSize = MinimumNonpagedPoolSize + ((Physical MB-4) * MinAdditionNonPagedPoolPerMb)
  • Example: On a 32 MB x86-based computer
  • MinimumNonPagedPoolSize = 256K
  • NonPagedPoolSize = 256K + ((32-4) * 32K) = 1.2 MB

MaximumNonPagedPoolSize = DefaultMaximumNonPagedPool; + ((Physical MB-4) * MaxAdditionNonPagedPoolPerMb

IF: MaximumNonPagedPoolSize < (NonPagedPoolSize + Page_Size * 16)
THEN: MaximumNonPagedPoolSize = (NonPagedPoolSize + Page_Size * 16)
IF: NonPagedPoolSize >= 192 MB
THEN: NonPagedPoolSize = 192 MB

  • Example: On a 32 MB x86-based computer
  • MaximumNonPagedPoolSize = 1 MB + ((32 - 4) * 400K) = 12.5 MB
Calculating Paged Pool Size

Size = (2 * MaximumNonPagedPoolSize) / Page_Size Size = (Size + Pte_Per_Page - 1)) / Pte_Per_Page PagedPoolSize = Size * Page_Size * Pte_Per_Page If PagedPoolSize >= 192 MB PagePoolSize = 192 MB
  • Example: On a 32 MB x86-based computer

    Size = (2 * 12.5 MB) / 4096 = 6400 Size = (6400 + (1024 - 1)) / 1024 = 7.25 Paged Pool Size = 7.25 * 4096 * 1024 = 30 MB

Note If both the nonpaged and paged pool values are set to zero in the registry, then the paged pool size will approximately equal the memory size.

Changing Nonpooled and Pooled Page Size

Nonpooled and pooled page values can be changed in the registry. The page pooled memory management parameters are located in the following registry key.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session \Memory Management Manager

Warning Using the Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of the Registry Editor can be solved. Use this tool at your own risk.

Increasing the size of NonPaged pool consumes physical memory that cannot be used for any other purpose.

Increasing the number of trusted domains increases the datagram traffic from each domain controller in the trusting domain.


Number of BDCs Necessary

The ratio of workstations to servers in a domain is a way to maintain responsiveness during logging on. More BDCs (also called domain servers) permit more users to log on simultaneously. One BDC can support up to 2,000 user accounts. The server configuration in Table 2.10 is for a 486/66 computer with 32 MB of RAM, running Windows NT Server.

Table 2.10 BDCs per number of user accounts

Number of workstations | Number of BDC servers
10 | 1
100 | 1
500 | 1
1,000 | 1
2,000 | 1
5,000 | 2
10,000 | 5
20,000 | 10
30,000 | 15

It is a good idea to perform the initial setup of all BDCs on site or over high-speed links because each new BDC will need a full synchronization with the PDC. Many companies set up their BDCs at the same site as the PDC and then ship them to their intended locations. This is the most efficient method for sites that have only low-speed or RAS access.


Microsoft Corporation Worldwide Network Background

Microsoft currently has approximately 16,000 user accounts and 35,000 network nodes worldwide. The Microsoft staff is evenly divided: About half the employees are located at or near the Redmond, Washington campus, and the rest are distributed among approximately 150 sites in 52 countries. All sites require full access to information and electronic mail.

In order to fulfill the goals of worldwide access to corporate information and to demonstrate its commitment to Windows NT Server technology, Microsoft designed its worldwide network around the Windows NT domain structure. The Microsoft worldwide-domain strategy includes the following goals.

  • Optimum availability to all Microsoft sites
  • Centralized support and administration
  • The ability to recover from an extended WAN link interruption without requiring a full synchronization of the SAM to the PDC

To meet these goals, the Microsoft Information Technology Group (ITG) implemented a multiple master-domain model. The plan uses a relatively small number of first-tier, master-account domains (which are administered by ITG) and strategically placed PDCs and BDCs, to provide optimum availability and performance.

Many sites are connected to the network by (slower) 64K links. These are not yet cost-effective to upgrade and upgrades are not available in some locations. When requested, ITG will provide administration of second-tier domains.

Microsoft ITG worked to keep the number of master account domains as small as possible in order to achieve the following objectives.

  • To keep administration centralized
  • To make global groups feasible

Microsoft ITG chose to limit the number of departmental, site, and developer server domains because it is easier to divide large domains than to combine many small ones into a larger domain when needed. For example, there is one ITG-NETWORKS domain. All servers for the Corporate Networks department are maintained in this domain.


Implementation

Because every user and global group account in the company exists in one of the master-account domains, and because all domains trust every master-account domain in the company, every user and global group account in the company is functional in all domains.

In all cases, ITG has full administrative permissions on all the domains in the model. All domain controllers can be backed up, restored, and updated with current builds and new system-configuration files.

There are some disadvantages to the multiple master-domain model. The most challenging issue is administration of individualized global groups. Managing global groups becomes impractical unless it can be based on a database, against which data can be compared. In this way, a group would automatically be updated if an individual no longer requires membership in that group. ITG provides global groups (based on department accounts) and updates membership (based on HR records). Other global groups are reviewed by case. Users are added to a master-account domain based on their current geographic location. If a user moves to a different site within Microsoft (such as from Redmond to Northern Europe), the user will be removed from and added to the appropriate master-account domains. When the user account is recreated in another domain, the account SID changes, so account permissions must be reapplied.

Windows for Workgroup systems belong to a second-tier domain to ensure that they have full access to the domain model. They use their account on the master account domain and use the second-tier domain as their workgroup. This allows access to domain servers that are using Windows NT security.

All Windows NT Server-based systems running RAS are located in a second-tier domain. Because there is a trust relationship between all domains in the corporate model, a user can dial into a RAS server anywhere in the model without additional administration.


Administration

ITG has sole authority to establish a trust relationship between the master domains and another domain on the Microsoft corporate network. ITG can administer all servers running Windows NT Server in a trust relationship within the Microsoft domains structure. Microsoft ITG uses the following criteria to establish a trust relationship with a second-tier domain.

  • Any product-development group is eligible to create one second-tier domain with trust relationships to the master account domains until every defined development business unit has a second-tier domain.

For example, Apps-Word, Apps-Excel, Sys-WFW, or Sys-WinNT are second-tier domains.

  • Every site outside the Redmond campus is eligible to create one resource domain with trust relationships with the master account domains.

For example, USA-Atlanta, USA-Chicago, FRA-Paris, and GER-Munich are resources domains.

  • ITG uses a standard administrative account that is part of the second-tier Domain Administrators group.

This enables ITG to perform administrative duties and assist the domain administrator when needed. It also enables ITG to perform backups of domain servers.


The Microsoft Worldwide Domain Model

Master-user account domains contain all user accounts for the worldwide domain structure. Master-account-domain names represent the user's geographic location, to assist in distribution of BDCs.

Figure 2.12 Microsoft worldwide domain model

The Microsoft network acknowledges two categories of administration. ITG is solely responsible for administration of some domains. Other domains are jointly administered by ITG and specific user groups, such as developers, sites, and others. Domain-administration permissions can be given to a group of users within their second-tier domain. ITG retains the option of allowing any of the departmental-server domains to have both their own domain administrators and ITG administration.

Domain Controller Locations

ITG provides master-account domains (first-tier), which are used by a specific set of sites. The name and size of these master-account domains are determined by geographic limitations, network topology, and the number of accounts to be supported. The PDC for the Redmond, NorthAmerica, and SouthAmerica master-account domains are located in Redmond. Others are located near the constituent users, where local data centers provide administrator resources. A BDC for the master-account domain is located at each remote site, for authentication of accounts at that site.

The European master account domain PDCs are in England, with a BDC for each European master account domain at each respective site.

Worldwide, a BDC for the global master account domain is also located at each network hub site.

Special Domain Considerations

Microsoft maintains two domains that, for security, have restricted access to and from the other domains. The groups using these special domains are the Microsoft Human Resources group and vendors who do business with Microsoft.

The Human Resources department maintains a secure network because of the confidential nature of its information. The HR master domain is isolated from the other domains on the network and is separately wired, so that it is not physically connected to the other network.

Vendors use the servers in the second restricted domain as a drop-off point. Microsoft employees can access the domain through a one-way trust relationship, but vendors are restricted to the vendor domain.

WAN Protocols

On the Microsoft corporate network, TCP/IP is used by Windows NT Server to forward authentication requests between domain controllers across a WAN. Every server in the master account domain can process logon requests from the domain user accounts.

Dynamic Host Configuration Protocol

Every server in the corporate domain runs TCP/IP. Adding Dynamic Host Configuration Protocol (DHCP) to the Microsoft network has significantly reduced administrative overhead for WAN management because individual machine TCP/IP addresses are configured automatically by DHCP.

Naming Conventions

Microsoft devised a naming convention for the corporate-domain structure to provide a consistent, worldwide interface to its users. The naming convention for second-tier domains is based on geographic location (USA-Atlanta), business (ITG-Networks), or development group (Apps-Word).

The following table shows some of the current domains. The rule is to use {division}-{department}. Another factor in establishing the domain name is to encompass the largest practical group.

Site domains are determined by {country code}-{city name}. Every site is permitted one resource domain in the corporate domain model.

Table 2.11 Microsoft first-tier and second-tier domain names

Master Account Domains (First-tier):

REDMOND | FAREAST | NORTHERNEUROPE | SOUTHPACIFIC
AFRICA | MIDDLEEAST | SOUTHAMERICA |
CENTRALEUROPE | NORTHAMERICA | SOUTHERNEUROPE |

Departmental and Site Resource Domains (Second-tier):

APPS-EXCEL | FRA-PARISEHQ | OPS-FACILITIES | SYS-BUSINESS
APPS-MULTIMEDIA | GER-BERLIN | OPS-MSPRESS | SYS-HARDWARE
APPS-POWERPOINT | GER-MUNICH | POL-WARSAW | SYS-MARKETING
APPS-WORD | ITG-APPS | PSS-BP | SYS-MSDOS-WIN
AT-RESEARCH | ITG-DEVELOPMENT | PSS-LP | SYS-WINNT
AUT-VIENNA | ITG-NETWORKS | PSS-RWG | USA-ATLANTA
FIN-ACCTSVRS | ITG-SQL | SWI-NYON | USA-DENVER


Troubleshooting Problems

This section discusses categories of typical problems users might face, such as the following situations.

  • Problems viewing a server's shared resources
  • Problems accessing a shared resource
  • BDC failure to authenticate a user's password
  • Problems caused by multiple PDCs in a domain
  • Problems created by special characters in the domain name


Viewing a Server's Shared Resources

Suppose an employee named AnnM logs on to a Windows NT domain with her password, Yippee. She wants to view the shared resources on a server named \\Products, but her password there is Hooray. Ann will see the following message on screen:

Error 5: Access has been denied.

AnnM asks the administrator of \\Products to change her password, but the administrator leaves the User Must Change Password At Next Logon check box selected. When AnnM tries again to view the server's shared resources, she will see the following message displayed on the screen:

Error 2242: The password of this user has expired.

When the administrator of \\Products clears the User Must Change Password At Next Logon check box, AnnM will be able to see the server's shared resources.


Accessing a Server's Shared Resources

Two examples help explain some access issues.

  • Suppose another employee, JeffH, wants to access a shared directory on \\Products but has no account on that domain. He is allowed access to this resource through the Guest account for \\Products and receives the associated permissions.
  • Suppose AnnM is logged on to a Windows NT domain with the password Yippee. She wants to connect to the shared directory on \\Products, where her password is Hooray. Because there is an account for AnnM, she is not allowed to gain access by using the Guest account. Instead, Windows NT prompts AnnM for the valid password on \\Products.


BDC Failure to Authenticate the User's Password

If the computer being connected to is a BDC for the domain in which the user account is defined but the BDC fails to authenticate the user's password, this indicates that the password has changed but the BDC is not synchronized at the time the user logs on. In this case, the BDC passes the logon request through to the PDC in the same domain.

As a precaution, users who change their passwords should log on to all computers to which they have access within about 15 minutes of making the change. This ensures that the cached credentials are up-to-date on each machine and that the user will be able to log on with the cached credentials even if the PDC is unavailable during logon.


Avoiding Multiple PDCs in a Single Domain

Do not configure multiple PDCs on a single domain. The following scenario is an example of the problems involved.

Suppose a system administrator installs a computer running Windows NT Server. The computer is called \\Main_unit, which is designated during installation as the PDC of a domain called MyDomain.

Later, the system administrator shuts down \\Main_unit and turns off. Then, the system administrator installs another server, called \\Second_unit, which is also designated as the PDC for MyDomain. Because \\Main_unit is not currently on the network, the original MyDomain is not known, and the installation of \\Second_unit and creation of MyDomain proceeds without error. The two domains are not identical; they have different Security IDs.

When the system administrator turns \\Main_unit on again, the NetLogon service discovers another PDC on the network. NetLogon fails, and \\Main_unit can no longer participate in the domain.

The system administrator now has a serious problem. It is not possible to simply demote \\Main_unit from a PDC to a BDC and continue. The Security ID (SID) for \\Main_unit will not be recognized by the current PDC, \\Second_unit, and \\Main_unit cannot join MyDomain in any capacity.

This situation happens because a unique domain SID is created whenever a PDC is created. All BDCs and user accounts within the domain share this domain SID as a prefix to their own SIDs. When \\Second_unit is installed as a PDC, its SID prefix is different from the \\Main_unit prefix, and the two computers can never participate in the same domain.

The system administrator cannot change the name of \\Main_unit and rejoin MyDomain because the SID is fixed when Windows NT Server is installed. If \\Main_unit is to be the PDC of MyDomain, the system administrator must shut down both \\Main_unit and \\Second_unit, start up \\Main_unit, and then reinstall Windows NT Server on \\Second_unit, designating it as a BDC during setup.

To avoid this problem, \\Second_unit should be installed as a backup domain controller while \\Main_unit is running. Then, if \\Main_unit is taken offline, \\Second_unit can be promoted to PDC. When \\Main_unit is ready to go online again, \\Second_unit can be demoted to a BDC. The SID for \\Main_unit is recognized by \\Second_unit. When \\Main_unit is restarted, it becomes the PDC again.

(In general, it should not be necessary to designate a new PDC unless the original PDC is going to be down for a long time.)


Special Characters in Domain Names

The following special characters are illegal in domain names (in addition to * and space).

#define ILLEGAL_NAME_CHARS_STR TEXT ("\"/\\[]:|<>+=;,?") CTRL_CHARS_STR

Even though some special characters such as period (.) are valid, underscore (_) and dash (-) would be better choices as special characters in domain names.


Chapter 3 - Windows NT Browser Service

Users on a Windows NT network often need to know what domains and computers are accessible from their local computer. Viewing all the network resources available is called browsing. The Windows NT Browser service maintains a list (called the browse list) of all available domains and servers. The browse list can be viewed using Windows NT Explorer and is provided by a browser in the local computer's domain.

Note

For the purposes of this discussion, the term server refers to any computer that can provide resources to the rest of the network. If a computer running Windows NT Workstation can share file or print resources with other computers on the network, it is considered a server in the context of the browser system. The computer does not have to be actively sharing resources to be considered a server.

This chapter includes descriptions of the following topics.

  • The types of browser computers
  • How browsers can work together to provide an accurate browser list, even if the master browser fails
  • Master-browser elections
  • The API calls used to register computers for the browser list and to receive the list from the master browser
  • How browsing across domains is handled


The Windows NT Browser Service

Windows NT assigns browser tasks to specific computers on the network. The computers work together to provide a centralized list of shared resources, eliminating the need for all machines to maintain their own lists. This reduces the CPU time and network traffic needed to build and maintain the list.

The Windows NT Browser system consists of a master browser, backup browsers, and browser clients. The computer that is the master browser maintains the browse list and periodically sends copies to the backup browsers. When a browser client needs information, it obtains the current browse list by remotely sending a NetServerEnum application programming interface (API) call to either the master browser or a backup browser.

A datagram is a network message packet that can be sent to a mailslot on a specified computer (a directed datagram) or to a mailslot on any number of computers (a broadcast datagram). This centralized-browser architecture reduces the number of datagrams sent to produce the available resource list. The centralized-browser architecture also reduces demands on the client CPU and memory.


Specifying Browser Computers

When you start a computer running Windows NT Workstation or Windows NT Server, the Browser service looks in the registry for the configuration parameter MaintainServerList to determine whether or not a computer will become a browser. This parameter is found under:

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters

Table 3.1 Allowable Values for the MaintainServerList parameter

Parameter Value | Meaning
No | This computer will never participate as a browser.
Yes | This computer will become a browser. Upon startup, this computer attempts to contact the master browser to get a current browse list. If the master browser cannot be found, the computer will force a browser election. This computer will either be elected master browser or become a backup browser. Yes is the default value on a computer running Windows NT Server.
Auto | This computer, referred to as a potential browser, may or may not become a browser, depending on the number of currently active browsers. The master browser notifies this computer whether or not it will become a backup browser. Auto is the default value for computers running Windows NT Workstation.

On any computer with an entry of Yes or Auto for the MaintainServerList parameter, Windows NT Setup configures the Browser service to start automatically when the computer starts.

Another parameter in the registry, IsDomainMasterBrowser, helps to determine which servers become master browsers and backup browsers The registry path for this parameter is as shown below.

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters

Setting the IsDomainMasterBrowser parameter entry to True or Yes on a computer makes that computer a preferred master browser. A preferred master browser has priority over other computers in master browser elections. Whenever a preferred master browser starts, it forces a browser election.

Any computer running Windows NT Workstation or Windows NT Server can be configured as a preferred master browser. When the Browser service is started on the preferred master-browser computer, the Browser service forces an election. Preferred master browsers are given priority in elections, which means that if no other condition prevents it, the preferred master browser will always win the election. This gives an administrator the ability to configure a specific computer as the master browser.

To specify a computer as the preferred master browser, set the parameter entry for IsDomainMasterBrowser to True or Yes. Set the parameter in the following registry path:

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters

Unless the computer is configured as the preferred master browser, the parameter entry will always be False or No. There is no user interface for making these changes; the registry must be modified.


Browser System Roles

A computer running Windows NT 3.1, Windows NT Advanced Server 3.1, Windows NT Workstation 3.5 or later, Windows NT Server 3.5 or later, Windows for Workgroups 3.11, or Windows 95 can be browsers. There are five types of computers in the browser system:

  • Non-browsers
  • Potential browsers
  • Backup browsers
  • Master browsers
  • Domain master browsers

Figure 3.1 Browser and non-browser computers

Non-browser

A non-browser is a computer that has been configured not to maintain a network resource or browse list.

Potential Browser

A potential browser is a computer that is capable of a maintaining a network resource browse list and can be elected as a master browser. The potential browser computer can act as a backup browser if instructed to do so by the master browser.

Backup Browser

The backup browser receives a copy of the network-resource browse list from the master browser and distributes the list upon request to computers in the domain or workgroup. All Windows NT domain controllers are automatically configured as either master or backup browsers.

Computers running Windows NT Workstation, Windows for Workgroups, or Windows 95 can be backup browsers if there are fewer than three Windows NT Server computers performing backup-browser functions for the domain.

Backup browsers call the master browser every 15 minutes to get the latest copy of the browse list and a list of domains. Each backup browser caches these lists and returns the list of servers to any clients that send a remote NetServerEnum API call to the backup browser. If the backup browser cannot find the master browser, it forces an election of the master browser.

The data limit for the list of servers maintained on computers running a version of Windows NT prior to version 4.0, Windows for Workgroups, or Windows 95 is 64K. This limits the number of computers in a browse list for a single workgroup or domain to between 2,000 and 3,000 computers.

Master Browser

The master browser is responsible for collecting the information necessary to create and maintain the browse list. The browse list includes all servers in the master browser's domain or workgroup, and the list of all domains on the network.

Individual servers announce their presence to the master browser by sending a directed datagram called a server announcement to the domain or workgroup master browser. Computers running Windows NT Server, Windows NT Workstation, Windows for Workgroups, Windows 95, or LAN Manager send server announcements. When the master browser receives a server announcement from a computer, it adds that computer to the browse list.

When a domain spans more than one subnetwork, the master browser will do the following tasks:

  • Maintain the browse list for the portion of the domain on its subnetwork
  • Provide lists of backup browsers on the local subnetwork of a TCP/IP-based network to computers running Windows NT Server, Windows NT Workstation, and Windows for Workgroups

If a TCP/IP-based subnetwork is comprised of more than one domain, each domain has its own master browser and backup browsers. On networks using the NWLink IPX/SPX-compatible network protocols, name queries are sent across routers, ensuring that there is always only one master browser for each domain. NetBEUI Frame (NBF) is not designed for a routed network and requires a separate master browser per subnet.

When a computer starts and its MaintainServerList registry entry is set to Auto, the master browser must tell that computer whether or not to become a backup browser.

Domain Master Browser

The domain master browser is responsible for collecting announcements for the entire domain, including any network segments, and for providing a list of domain resources to master browsers. The domain master browser is always the primary domain controller (PDC) of a domain.

The PDC of a domain is given priority in browser elections to ensure that it becomes the master browser. The Windows NT Browser service running on a PDC has the special, additional role of being the domain master browser.

For a domain that uses TCP/IP and spans more than one subnetwork, each subnetwork functions as an independent browsing entity with its own master browser and backup browsers. NwLnkNb and NBF transports don't use the domain master browser role because those transports have only a single master browser for the entire network. Browsing across the wide area network (WAN) to other subnetworks requires at least one browser running Windows NT Server, Windows NT Workstation, or Windows For Workgroups 3.11b on the domain for each subnetwork. A PDC typically functions as the domain master browser on its subnetwork.

When a domain spans multiple subnetworks, the master browser of each subnetwork announces itself as the master browser to the domain master browser, using a directed MasterBrowserAnnouncement datagram. The domain master browser then sends a remote NetServerEnum API call to each master browser, to collect each subnetwork's list of servers. The domain master browser merges the server list from each subnetwork master browser with its own server list, forming the browse list for the domain. This process is repeated every 15 minutes to ensure that the domain master browser has a complete browse list of all the servers in the domain.

The master browser on each subnetwork also sends a remote NetServerEnum API call to the domain master browser to obtain the complete browse list for the domain. This browse list is available to browser clients on the subnetwork.

A single computer may play multiple browser roles. For example, the master browser may also be the domain master browser.

Note

Windows NT workgroups cannot span multiple TCP/IP subnetworks. Any Windows NT workgroup that spans subnetworks actually functions as two separate workgroups with identical names.


Browser Elections

Browser elections occur to select a new master browser under the following circumstances.

  • When a computer cannot locate a master browser
  • When a preferred master browser comes online
  • When a Windows NT domain-controller system starts

A computer initiates an election by sending a special datagram called an election datagram. All browsers can receive election datagrams. When a browser receives an election datagram, it examines that datagram's election criteria. If the browser has better election criteria than the sender of the election datagram, the browser will issue its own election datagram and enter what is called an election in progress state. If the browser does not have better election criteria than the sender of the election datagram, the browser attempts to determine which system is the new master browser.

Figure 3.2 Browser election

The election criteria for a browser is based on the browser's current role in the domain and its current state, using the hierarchy in Table 3.2.

Table 3.2 The hierarchy of criteria for a browser election

Operating System Type | 0xFF000000
Windows for Workgroups or Windows 95 | 0x01000000
Windows NT Workstation | 0x10000000
Windows NT Server | 0x20000000
Election Version | 0x00FFFF00
Per Version Criteria | 0x000000FF
PDC | 0x00000080
WINS System | 0x00000020L
Preferred Master | 0x00000008
Running Master | 0x00000004
MaintainServerList = Yes | 0x00000002
Running backup browser | 0x00000001

The browser will use all of the appropriate election criteria to determine the sending computer's election criteria.

The following criteria determine whether or not a browser has won an election.

  • If the browser's election version is greater than the sender's election version, the browser wins. If not, the browser uses the next election criteria. The election version is a constant value that identifies the version of the browser-election protocol. The election version is the revision of the browser protocol and is not related to the operating-system version.
  • If the browser's election criteria is greater than the sender's election criteria, the browser wins. If not, the browser uses the next election criteria.
  • If the browser has been running longer than the sender, the browser wins. If not, the browser uses the next election criteria.
  • If none of the criteria above have determined the election, then the server with the lexically (alphabetically, including numbers and symbols) lowest name wins. For example, a server named "A" will become master browser over a server named "X."

When a browser receives an election datagram indicating that it wins the election, the browser enters the running election state. While in this state, the browser sends out an election request after a delay, based on the browser's current role in the domain.

  • Master browsers and the primary domain controllers delay for 100 microseconds (ms).
  • Backup browsers and backup domain controllers randomly delay for 200 ms and 600 ms.
  • All other browsers randomly delay between 800 ms and 3000 ms.

This delay occurs because Windows for Workgroups browsers go "deaf" for several hundred microseconds after sending an election datagram. This delay reduces the number of election datagrams sent. A browser winning an election may receive a different election datagram, causing it to lose an election later. By having less-likely winners delay longer, the less-likely winners typically don't send election datagrams.

The browser sends up to four election datagrams. If no other browser responds with an election criteria datagram that would win the election, the computer is promoted to master browser. If the browser receives an election datagram indicating that another computer will win the election, and the computer is currently the master browser, the computer will demote itself from master browser and become a backup browser.

To force an election, the client computer will broadcast an election datagram to the domain, indicating that an election should occur. This datagram is created to prevent the client that sends the datagram from winning the election.

When an election occurs, the Browser service on the computer that forced the election will log an event in the Event Viewer System log, indicating that it forced the election. An event is logged for each protocol on which the Browser service forces an election.


Browser Announcements

The Browser service must be notified by a resource when it is available for use on the Windows NT network. When a network computer running Windows for Workgroups, Windows 95, Windows NT Workstation, or Windows NT Server starts, it sends an announcement to the Browser service that it is an available resource.

Figure 3.3 Browser announcements

Master browsers are responsible for receiving announcements from computers running any of the following software.

  • Windows NT 3.1
  • Windows NT 3.1 Advanced Server
  • Windows for Workgroups
  • Windows 95
  • Windows NT Workstation 3.5, or later
  • Windows NT Server 3.5, or later
  • LAN Manager systems

Master browsers also return lists of backup browsers to computers running any of the following software.

  • Windows NT 3.1
  • Windows NT 3.1 Advanced Server
  • Windows NT Workstation 3.5, or later
  • Windows NT Server 3.5, or later
  • Windows for Workgroups 3.11, or later
  • Windows 95 clients

When a computer starts and its MaintainServerList parameter is set to Auto, the master browser is responsible for telling the system whether or not to become a backup browser.

When a computer becomes the master browser by winning an election, and the browse list is empty, the master browser forces all systems to announce. The master browser broadcasts a RequestAnnouncement datagram. All computers that receive this datagram must answer randomly within 30 seconds. This 30-second range for response prevents the master browser from becoming overloaded and losing replies, and protects the network from being flooded with responses.

Figure 3.4 Browsing for Backup Lists

A master browser cannot be forced to rebuild the browse list for a workgroup or domain. However, shutting down and restarting a computer that is configured as the preferred master browser, or stopping and restarting the Browser service, forces the build of a new browse list. When a preferred master browser starts, it forces an election, which it will win. Because there is no browse list, it then forces all members of the domain or workgroup to announce themselves.

If a master browser receives an announcement from another computer that claims to be the master browser, the master browser will demote itself from master browser and force an election. This ensures that there is never more than one master browser in each workgroup or domain.


Non-browser Announcements

A non-browser computer periodically announces itself to the master browser by sending a directed datagram to the master browser on the network. Initially, each non-browser will announce itself every minute. The announcement interval will be extended to once every 12 minutes. The computer announces its availability in intervals of 1 minute, 2 minutes, 4 minutes, 8 minutes, 12 minutes, 12 minutes, and then announces to the master browser only every 12 minutes. If the master browser has not heard from the non-browser for three consecutive announcement periods, the master browser will remove the non-browser from the browse list.


Potential -browser Announcements

Most computers are potential browsers; that is, they are capable of becoming either backup browsers or master browsers. These computers announce themselves in the same manner as non-browsers.


Backup-browser Announcements

Backup browsers are a subset of potential browsers and announce themselves in the same manner as non-browsers. However, backup browsers participate in browser elections. Backup browsers call the master browser every 15 minutes to obtain updated network-resource browse lists and lists of workgroups and domains. The backup browser caches these lists and returns the browse list to any client that sends out a browse request by making a call, using the NetServerEnum API, to the backup browser. If the backup browser cannot find the master browser, it will force an election.

Because it can take up to 15 minutes for a backup browser to receive an updated browse list, it is possible that a computer will appear in the browse list for as long as 51 minutes after it is no longer an available resource on the network. The time period consists of 36 minutes, which is three 12-minute announcement cycles plus the 15 minutes for the backup browser to receive an updated list.


Configuring the Browser Announcement Time

You can change how often a browser client announces itself. In the registry path, under:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

add the Announce parameter with a type of REG_DWORD, and set the number of seconds that the browser should wait between announcements. For example, if the default for Announce is 12 minutes, the length of time is set to 720.

The Announce value must be changed on all computers in the workgroup or domain before the new value can be used by all computers. As you decrease this value, announcement traffic increases. Increasing the Announce value reduces the amount of announcement traffic, but will increase the length of time that a shutdown computer will appear on the browse list.


Browser Requests

The purpose of the Browser service is to make a list of network resources available to users. To use this resource list, the client computer must know which computer to contact to request a copy of the list.

Figure 3.5 Flow of the Browser Request

The request issued to obtain the list of available network resources is a NetServerEnum API call. This request is sent when net view is entered at the command prompt or when the Map Network Drive dialog box lists the network resources. The client issues the NetServerEnum API call to a backup browser.

If this is the first time that a NetServerEnum API call is issued on the client computer, the computer must first find out which computers are the backup browsers for its workgroup or domain before it can send the API call. The client does this by issuing a GetBackupList datagram to the master browser.

The master browser receives and processes the GetBackupList request. The master browser returns a list of backup browsers active within the workgroup or domain being queried. The client selects the names of three backup browsers from the list and stores these names for future use. The NetServerEnum API call is sent to a backup browser randomly chosen from the three saved names.

If the master browser for the workgroup or domain being queried cannot be found after three attempts, the client will force the election of a new master browser in the domain. The client returns an ERROR_BAD_NETPATH message to the application, indicating that the master browser could not be found.


Number of Browsers in a Domain or Workgroup

The following rules determine the number of browsers in a domain or workgroup. In this discussion, the words domain and workgroup are used interchangeably.

If there is currently a PDC in the domain, it will be the master browser for the domain.

Every BDC in the domain will be a backup browser for the domain. The only exception to this is if the BDC is needed as a master browser because the PDC has failed. In that case, the BDC will be the master browser for the domain.

If a computer's MaintainServerList registry parameter is set to Yes, this computer will be a backup browser for the domain or TCP/IP subnet.

If no backup browsers are selected for the domain based on the preceding rules, the master browser determines the number of backup browsers for the domain. If a computer's MaintainServerList registry parameter is set to Auto, the master browser will select some of those computers to act as backup browsers based on the number of computers in the domain.

Table 3.3 Number of browsers in a domain or workgroup

Number of Computers | Number of Backup Browsers | Number of Master Browsers
1 | 0 | 1
2 to 31 | 1 | 1
32 to 63 | 2 | 1

For each additional 32 computers added to the domain, another backup browser is selected for the domain.

For the TCP/IP transport, each subnet independently enforces the preceding set of rules.


Browser Shutdown or Failure

If a backup browser shuts down properly, it sends an announcement to the master browser that it is shutting down. The backup browser does this by sending an announcement that does not include the Browser service in the list of running services.

If a Master Browser shuts down gracefully, it will send a ForceElection datagram so that a new master browser can be chosen.

If a computer does not shut down properly or if it fails for any reason, it must be removed from the browse list. The Browser service handles browser failures.


Non-browser Failure

When a non-browser fails, it stops announcing itself. The configured announcement period is between 1 and 12 minutes. If the non-browser has not announced itself after three announcement periods, the master browser removes the computer from the browse list. Therefore, it can take up to 51 minutes before all browsers know of a non-browser's failure. This figure includes up to 36 minutes for the master browser to detect the failure, and 15 minutes for all of the backup browsers to retrieve the updated list from the master browser.


Backup-browser Failure

As with a non-browser failure, when a backup browser fails, it may not be removed from the master-browser list for up to 51 minutes. If a browse list cannot be obtained from the missing backup browser, the client selects another backup browser from its cached list of three backups. If all of the client's known backup browsers fail, the client attempts to get a new list of backup browsers from the master browser. If the client is unable to contact the master browser, the client forces an election.


Master-browser Failure

When a master browser fails, a backup browser detects the failure within 15 minutes and forces an election of a new master browser.

If a client performs its browse request (using the NetServerEnum API call) after a master browser fails but before a backup browser detects the failure, the client forces an election. If a master browser fails and there are no backup browsers, browsing in the workgroup or domain will not function correctly.

During the gap between the master browser's failure and the election of a new master browser, the workgroup or domain can disappear from the lists that are visible to computers in other workgroups and domains.


Domain Master-browser Failures

If the domain master browser fails, the master browser for each network segment provides a browse list, containing only the servers in the local network segment. All servers that are not on the local network segment will eventually be removed from the browse list. Users will still be able to connect to servers on the other network segments if they know the name of the server.

Because a domain master browser is also a PDC, an administrator can correct the failure by promoting a BDC to PDC. A BDC can perform most PDC network tasks, such as validating logon requests, but does not promote itself to PDC and does not become domain master browser in the event of a PDC failure.

Figure 3.6 Master browser failure


Browse Service Across Multiple Workgroups and Domains

Users need to browse multiple workgroups and domains to retrieve a list of servers within their workgroup or domain and a list of other workgroups and domains.

Figure 3.7 Browser service across multiple workgroups and domains

Upon becoming a master browser, each master browser in each workgroup and domain will broadcast a DomainAnnouncement datagram every minute for the first five minutes. After the first five minutes, the master browser will broadcast a DomainAnnouncement datagram once every 15 minutes. If a workgroup or domain has not announced itself for three announcement periods, the workgroup or domain will be removed from the list of workgroups and domains. Therefore, it is possible that a workgroup or domain will appear in the browse list 45 minutes after the workgroup or domain has failed or been shut down.

A DomainAnnouncement datagram contains the following information.

  • The name of the domain
  • The name of the master browser for that domain
  • Whether the browser computer is running Windows NT Workstation or Windows NT Server

If the browser computer is running Windows NT Server, the DomainAnnouncement datagram will also specify whether or not the browser computer is the domain PDC.


Browse Service Across a Wide Area Network (WAN)

When using domains that are split across routers, each TCP/IP network segment functions as an independent browsing entity with its own master browser and backup browsers. Therefore, browser elections occur within each network segment.

Domain master browsers are responsible for spanning the network segments to collect computer-name information, in order to maintain a domain-wide browse list of available resources. The domain master browser and cooperating master browsers on each WAN segment provide browsing of domains that exist across multiple TCP/IP network segments. The domain master browser is the PDC of a domain. The master-browser computers on the subnets can be running Windows NT Server, Windows NT Workstation, Windows for Workgroups version 3.11b, or Windows 95.

Figure 3.8 Browser service across a WAN

When a domain spans multiple network segments, the master browsers for each network segment use a directed datagram called a MasterBrowserAnnouncement datagram to announce themselves to the domain master browser. The MasterBrowserAnnouncement datagram notifies the domain master browser that the sending computer is a master browser in the same domain and that the domain master browser needs to obtain a copy of the master browser's browse list. When the domain master browser receives a MasterBrowserAnnouncement datagram, it sends a request to the network segment's master browser, which announced itself in order to collect a list of the network segment's servers.

The domain master browser then merges its own server list with the server list from the master browser that issued the announcement. This process is done every 15 minutes and guarantees that the domain master browser has a complete browse list of all the servers in the domain. When a client issues a browse request to a backup browser, the backup browser returns a list of all the servers in the domain, regardless of the network segment on which they are located.

Workgroup using Windows NT or Windows for Workgroups cannot span multiple network segments. Any workgroup of either kind that does span network segments will function as two separate workgroups with the same name.


Browse Service Across a WAN with TCP/IP

Currently, Browser-service communication relies almost entirely on broadcasts. In a WAN environment, such as TCP/IP, where domains are separated by routers, special broadcast problems can arise because broadcasts, by default, do not pass through routers. There are two issues to consider.

  • How browsers separated by a router perform browser functions
  • How local clients browse remote domains that are not on their local network segment

The following topics discuss three methods that can be used to set up WAN browsing with TCP/IP. They are presented in order of preference.

The Windows Internet Name Service (WINS)

The Windows Internet Name Service (WINS) resolves NetBIOS names to IP addresses so that datagrams can be sent to the targeted computer. Implementing WINS eliminates the need to configure the LMHOSTS file or to enable UDP port 137. Using WINS requires the following configuration.

  • WINS is configured on a computer running Windows NT Server 3.5 or later.
  • Clients are WINS-enabled.

WINS clients can be configured with Windows NT 3.5 or later, Windows 95, Windows for Workgroups 3.11b running TCP/IP-32, LAN Manager 2.2c for MS-DOS, or Microsoft Network Client 3.0 for MS-DOS. The latter two are provided on the compact discs for versions 3.5 or later of Windows NT Server.

We usually recommend that you implement WINS for name resolution and browsing support. As an alternative, it is possible to have full domain browsing by using only LMHOSTS files on all computers, but this limits browsing to the local domain. Non-WINS clients still need the LMHOSTS file to browse a WAN, even if WINS has been implemented in the domain.

Note

A client will participate in domain browsing only when that client is using a workgroup name that is equivalent to the domain name (workgroup=domain). In the case of Windows NT computers, they can also join the domain to gain this functionality, instead of participating in a workgroup.

The LMHOSTS File

NetBIOS name resolution is typically performed through broadcasts, which will resolve names only on the local network segment. To resolve names of computers located on another network segment, the LMHOSTS file (located under \<winnt_root>\System32\drivers\etc) must be configured. The LMHOSTS file must contain a NetBIOS name-to-IP address mapping for all computers that are not on the local network segment.

To implement communication between network segments and the domain master browser, the administrator must configure the LMHOSTS file with the NetBIOS names and IP addresses of all browsers. To ensure that the master browser for each network segment can access the domain's PDC, the PDC for each domain must exist in the LMHOSTS file on each master browser and have the #DOM tag.

The LMHOSTS file on each network segment's master browser should contain the following information.

  • IP address and NetBIOS name of the domain master browser
  • The domain name, preceded by the tags #PRE and #DOM, as in the following example

130.20.7.80 <Browser_name> #PRE #DOM:<domain_name>

To guarantee that the PDC can request the local browse list from the network segment's master browser, TCP/IP and all other WAN transports must cache the client's IP address.

UDP Port 137 (NetBIOS Name Service Broadcasts)

Not all WANs will have problems browsing. Some routers can be configured to forward specific types of broadcasts and filter out others.

All NetBIOS over TCP/IP (NetBT) broadcasts are sent to the UDP port 137, which is defined as the NetBT Name Service. This usage is defined by Request for Comment (RFC) 1001 and 1002. Routers normally filter out these frames because they are sent to the hardware and subnet broadcast addresses. However, some routers allow all frames sent to this particular UDP port — which is used only by NetBT—to be forwarded. As a result, the browser looks as if it is on one, big, network segment. All domains and computers within the network segments are seen by all computers, including Windows for Workgroups computers.


Windows for Workgroups and Windows 95 as Master Browsers

The Vserver.386 and Vredir files on the Windows NT Server versions 3.51 and 4.0 compact discs are different from the files of the same names on the Windows NT Server version 3.5 compact disc.

These two files have been modified so that computers running Windows for Workgroups 3.11b or Windows 95 can be master browsers for a network. This enables a computer on a network with computers running only Windows for Workgroups 3.11b and Windows 95 to browse Windows NT domains on other networks.

As the master browser for the network, a computer running Windows for Workgroups 3.11b or Windows 95 will communicate with the PDC of the domain to obtain the browse list for the entire domain.

The Windows for Workgroups 3.11b or Windows 95 master browser will function as if a Windows NT master browser were on the network. The Windows for Workgroups 3.11b or Windows 95 master browser will contact the PDC every 15 minutes to give it the local network's browse list and to obtain the domain-wide browse list.

The following conditions must exist for a computer running either Windows for Workgroups 3.11b or Windows 95 to function properly as a master browser.

  • The computer must also be running TCP/IP.
  • WINS must be used for name resolution.
  • The domain's PDC must be a WINS client.
  • The Windows for Workgroups 3.11b or Windows 95 client must be in a workgroup that has the same name as the domain, and must also be a WINS client.


Microsoft LAN Manager Interoperability

For interoperability between Windows NT Workstation or Windows NT Server and LAN Manager browsers, some configuration is required.

Selecting the Make Browser Broadcasts to LAN Manager 2.x Clients check box causes the browser to announce itself to LAN Manager 2.x computers using a LAN Manager-compatible server announcement. The default configuration is not to send announcements to LAN Manager 2.x computers.

To activate Make Browser Broadcasts to LAN Manager 2.x Clients

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Double-click Server.

5. Select the Make Browser Broadcasts to LAN Manager 2.x Clients check box, and then click OK.

To configure this option on a Windows NT Workstation, change the Lmannounce parameter entry to 1 in the registry under the following path:

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

Each computer can be configured to browse up to four other LAN Manager domains. These domains are the LAN Manager-only domains that the local computer is interested in browsing. If any other domains are configured on a domain master browser, the other domains are provided to all members of the domain.

To configure other domains, in the registry under:

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters

add a value of OtherDomains with a type of REG_MULTI_SZ, and supply the other domain names.


Browser System Components

The Browser system consists of two components, the Browser service and the datagram receiver.

The Browser service is the user-mode portion of the Browser system and is responsible for maintaining the browse list, sending the API requests, and managing the various browser roles that a computer can have.

The Browser service actually resides within the Service Controller process (Lmsvcs.exe) and can be found under \<winnt_root>\system32. The Browser service is located in the registry path under the following key.

\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser

The datagram receiver is the kernel-mode portion of the Browser system and is simply a datagram and mailslot receiver. It receives directed and broadcast datagrams that are of interest to the Windows NT Workstation and Windows NT Server services. The datagram receiver also provides kernel-level support for the NetServerEnum API, support for remote mailslot reception (second-class, datagram-based, mailslot messages), and the request-announcement services.

In Windows NT 3.5 and later, the datagram receiver is implemented in the Windows NT redirector (Rdr.sys). In Windows NT 3.1, there is a separate driver, Browser.sys, for the datagram receiver.


Monitoring Browsers

The Microsoft Windows NT Server Resource Kit 4.0 includes two utilities, Browmon.exe and Browstat.exe, that can be used to monitor the browsers within a workgroup or domain.


Browmon.exe

Browmon.exe is a graphical utility that can be used to view browsers — both the master and backups — for selected domains. It lists the browser servers for each protocol in use by computers in the domain.

You can click the Properties menu to see the servers in the browse list for the selected protocol and the domain browse list. In the Properties dialog box, click Information to open the Information dialog box, which shows the number of server announcements, domain announcements, election packets, and so forth.


Browstat.exe

Browstat.exe is a command-line utility that can be used to view the Browser servers — both the master and backups — in the specified workgroup or domain. Browstat.exe has some capabilities that Browmon.exe does not have, such as the ability to force an election and the ability to force a master browser to stop so that an election occurs.

Browstat.exe includes the following options.

Usage: BROWSTAT Command [Options | /HELP] Where <Command> is one of: ELECT ( EL) - Force election on remote domain GETBLIST ( GB) - Get backup list for domain GETMASTER ( GM) - Get remote Master Browser name (using NetBIOS) GETPDC ( GP) - Get PDC name (using NetBIOS) LISTWFW (WFW) - List WFW servers that are actually running browser STATS (STS) - Dump browser statistics STATUS (STA) - Display status about a domain TICKLE (TIC) - Force remote master to stop VIEW ( VW) - Remote NetServerEnum to a server or domain on transport


How to Find the Master Browser: Example

To find the master browser for a domain, the following command line must be used.

browstat getmaster <transport> <domain_name>

Where <transport> is one of the protocols installed on the system, in the form reported by net config rdr on the following Workstation active on line.

NwlnkNb NetBT_Lance1 NetBT_EE162 Nbf_Lance1

For example, the following command could be used to find the master browser for a domain named Seattle.

browstat getmaster NetBT_Lance1 Seattle

Note

When using Browstat.exe, you can use either the full command or the two- or three-character abbreviation, such as gm instead of getmaster.


Chapter 4 - Terra Flora: A Fictitious Case Study

The following chapter is a preliminary draft of material that will appear in expanded form in the next edition of the Windows NT Server Resource Kit. At that time, the case study will be further revised and expanded to include details about the Divisional, Department, and Desktop server services and other helpful information.

In the early days of networking, there was only one type of network and operating system. Communication was not an issue: When the computers were connected, they communicated. It was relatively slow and very expensive, but it worked.

Today, corporate computer environments are often heterogeneous, that is, they have at least two different network operating systems on their standards list that must interoperate with both newer, intranet client/server environments and legacy computers and applications.

As network administrators attempt to make these systems work together, they find that the different network operating systems do not "speak" the same standard protocols and that there may be non-standard or proprietary protocols in use in various parts of their networks. They need to discover ways to connect these networks together, enabling them to interoperate and complement each other.

To illustrate problems and solutions for interoperability, we put together a real network for a fictitious company we call "Terra Flora, Incorporated." We imagined this company to be an international corporation in the floral industry. Terra Flora will serve as an example of a company with heterogeneous networks and of how to devise and implement a plan to bring these information systems together in a way that is consistent with the company's business operations and objectives.

Terra Flora is a totally fictitious corporation. The names of companies, products, people, characters, and data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted.


Introducing Terra Flora

Terra Flora is an international corporation specializing in retail flower in the United States and Europe. The main business functions of Terra Flora are listed below.

  • Operating nurseries that grow flowers, and purchasing exotic varieties of flowers from local growers under contract
  • Manufacturing trademark "Terra Flora" brand terra cotta pots and vases
  • Distributing the grown and purchased flowers and manufactured terra cotta products to the retail stores
  • Obtaining and filling customer orders at the retail level
  • Delivering flower orders


Terra Flora Corporate History

The business originally consisted of a single retail outlet, located in Sacramento, California, that began selling flowers in 1970.

The business grew significantly, so the company purchased other retail florist shops across the United States, including major retail stores in New York City and Los Angeles. These two stores installed order desks with toll-free phone lines. Customers could place orders by phone and have their purchases delivered anywhere in the United States, with guaranteed delivery times and schedules.

The flowers originally came from a local Sacramento nursery. As the company grew, it contracted with two European nurseries, in Amsterdam, The Netherlands, and Seville, Spain, to provide exotic flower varieties. The retail company purchased all three nurseries in 1988 and set up distribution procedures, which effectively turned the nurseries into supply and distribution centers.

In early 1990, the chain incorporated and offered ownership shares on the stock market. Using the capital generated from selling stock, the corporation purchased a manufacturing plant located in Sacramento that manufactured various styles of award-winning terra cotta pots and vases. The pots and vases have become the corporation's "signature" product and are used as part of the flower arrangements sold at the retail stores.

At the same time, the company began opening retail shops in upscale malls instead of purchasing existing florists. Currently, the company continues to focus on this strategy for expanding its business.

In December 1991, the corporation renamed itself "Terra Flora Incorporated."

In 1993, Terra Flora began selling flowers internationally. The corporation formalized the setup of supply and distribution centers in Amsterdam and Seville by purchasing office space near the supply farms. Terra Flora modeled the centers on the Sacramento operation, which had changed significantly over the years. More U.S. distribution centers were purchased in Dallas, Texas and Boston, Massachusetts.


Organization of Terra Flora

Terra Flora is now organized in three major divisions: Retail Services, Supply and Manufacturing, and Nursery Products. Corporate and divisional headquarters are all located in Sacramento. Each division has business operations in North American and European locations.

  • The Retail Services division manages the operations of all Terra Flora retail stores. The division is also responsible for the regional retail-distribution service centers in Sacramento, Dallas, Boston, Seville, and Amsterdam, and for the major retail centers in Los Angeles, New York City, and London, England.
  • The Supply and Manufacturing provides the terra cotta pots. The original manufacturing plant is in Sacramento, and a remote site is in Amsterdam.
  • The Nursery Products division has remote sites in Seville and Amsterdam in addition to the Sacramento nursery.

Figure 4.1 International locations of Terra Flora division sites

Until now, each division of Terra Flora operated as a separate company, implementing policies and procedures that the divisional managers felt were necessary to perform the various business functions. The autonomy of each division was the result of rapid growth and the fact that the procedures that were in place in each division worked well enough, in spite of some inefficiencies.

Each Terra Flora division also operates separate, heterogeneous computer environments that separately track and record various business functions, including sales, ordering, accounting, inventory, and division-specific information. Information is sent to division headquarters in Sacramento, where it is consolidated. None of the networks in any of the divisions communicate with the computers in other divisions. Consolidating information for the entire company means entering the same data several times into different computer systems.

The disadvantages of the situation are clear. It is costly, and information is redundant. Management reports are prone to error because synchronization of information is difficult. The heterogeneous networks must interoperate if the Terra Flora divisions are to merge and operate as a single business unit, relying on a centralized information database.

To meet this challenge, the company hired a new Chief Information Officer, who had managed the implementation of a similar strategic plan for another corporation before joining Terra Flora. As a first step, the CIO has asked each of the divisions to submit a list of the computer hardware and operating systems for analysis, along with descriptions of the major divisional business processes. The list would indicate the computer and manual interfaces into the processes. Each division has also been asked to supply network diagrams and brief descriptions of the databases and software applications that run on each computer. Analysis will be performed on each division in an attempt to decide which computer hardware and software from each division best fits the corporate strategy.

The immediate goal is to connect and maintain the existing systems necessary to continue business operations. In the long term, Terra Flora plans to migrate the existing systems applications to less costly and lower-maintenance client/server applications. More analysis of the custom applications must be done to determine the best features of those products and to create a plan for implementing the necessary client/server applications.


Retail Services Division

Because the Retail Services division grew by purchasing other florist shops, the division acquired those shops' computer equipment and software systems as part of the purchases. That computer equipment was then incorporated into the division's network.

The Retail Services Network

The network diagram below provides a representation of the computer equipment running in the Retail Services division.

Figure 4.2 Retail Division network diagram before company-wide consolidation

The retail division was relatively slow to computerize. The division purchased the Sun server, currently named CASUN25ENT01, early in the 1980s. Custom applications were written, which are still updated and further customized as needed.

Distribution was incorporated into the Retail Services divisional operations when the distribution center in Dallas was purchased. A Banyan server was obtained as part of that purchase, which provides file and print services to the division.

Workings of the Sun Server

This server runs the Solaris SPARC version 2.5 operating system. The ORACLE database focuses on retail sales information, with emphasis on distribution and inventory information. Customized business application systems on the Sun server include an inventory-management system, accounting system, customer-ordering system, product-ordering system, point-of-sale application (including a custom exchange rate application to calculate the monetary differences in international customer orders and purchases), distribution software, and delivery-truck scheduling.

Workings of the Banyan Server

The Banyan server runs a Banyan VINES 6.22 network operating system. The server provides file and print services to the Retail Services division headquarters in Sacramento. Banyan mail messaging is provided through Beyond Mail.

Whenever Terra Flora purchased a retail store, the store was connected to the Sun server and then given access to appropriate information stored on the server. The retail stores are provided file and print services for management reports and sales tickets through printers on site in the stores.

Business Processes of the Retail Services Division

The business processes in Retail Services fall into two categories: dealings with consumers and dealings between the distribution centers and the retail stores.

Interactions with Consumers

1. The retail store receives customer orders in a number of ways:

  • A customer can walk into a retail store, place an order, and either take delivery or have the order delivered within a specified time.
  • A customer can phone or fax an order to the retail store and request delivery within a specified time.
  • A customer can phone in an order using the 1-800 phone lines. The order is forwarded to the appropriate retail store for delivery within the specified time.

2. Except for orders taken over the 1-800 lines, customer orders are entered into the system on the SCO computer, named CASC050DSK, which appears on the network diagram in the California domain at the Desktop level. This entry is made through an X/Windows front-end application. Orders that come in on the 1-800 phone line are entered on the SCO computer by the customer-service representative at the time the order is placed, while the customer is still on the phone.

3. The order data is posted to an ORACLE database running on the Sun server. This automatically triggers a division-wide examination and analysis of inventory and delivery schedules, and then triggers other business applications on other computers to perform the following functions:

  • If the customer order is placed in a retail store and the retail store can fill the order within the time frame specified by the customer, the inventory is relieved and a customer invoice is printed at the retail store on the local printer for delivery with the product.
  • If the customer order is placed in a retail store and the store cannot fill the order, the inventory of the retail stores in the area is examined. If an area retail store can fill the order, the order is forwarded to the delivery-schedule application of the area store for scheduling delivery within the customer-specified time frame. The inventory of the area store is relieved and a customer invoice prints on that store's local printer for delivery with the product.
  • If the customer order is placed in a retail store and neither the retail store or any area store can fill the order, the customer's order is placed on a product order to ensure that the order will arrive at the retail store and be delivered within the specified customer time frame.
  • If the customer order is placed over the 1-800 phone lines, the customer order is forwarded to a retail store that can fill the order within the customer's specified time frame. The inventory of the retail store is relieved and a customer invoice is printed on the local printer for delivery with the product or to give to the customer who chooses to pick up the product.

4. Standard accounting information is posted to the accounting database as a result of the customer order.

5. Automatic product orders are generated based on sales of product. The store manager reviews the order, accepts or changes the information on the order, and faxes the order to the proper distribution centers.

6. Delivery-truck schedules are produced and printed on local printers at the retail stores that are responsible for delivering customer orders.

Interactions Between Distribution Centers and Retail Stores

The Retail Services division is also responsible for the distribution of product from the distribution centers to the retail stores.

1. Each day, the ORACLE product-ordering database records the product received at the distribution center.

2. Distribution schedules are printed at corporate headquarters and the distribution sites, indicating which retail stores are to receive what products, based on the product orders submitted by the retail stores.

3. New product orders from the retail stores arrive by fax or telephone.

4. The product orders are entered into the ORACLE database on the Sun server.

5. Inventory is examined. If the products ordered are in stock, inventory is updated, product pick tickets are generated, and correct shipping labels and customs documents are printed at the proper printers in the distribution centers.

6. Accounting information in the ORACLE database is updated, as appropriate.

7. Orders for the flower products to be distributed are automatically generated and tracked in the ORACLE product-order database and then faxed or phoned to the proper nursery in the Nursery Products division or to the plant in the Supply and Manufacturing division.


Supply and Manufacturing Division

The Supply and Manufacturing division is responsible for the manufacturing of the signature terra cotta pots and other standard economy pots, as necessary. The division is also responsible for distributing the pots to the retail stores, based on stock and special orders placed by those stores.

The Supply and Manufacturing Network

The manufacturing plant was essentially an IBM shop when Terra Flora purchased it. The sale included the ES/9000, which was running various business-operations software. These software applications did not communicate with each other. The pot manufacturer had purchased an IBM AS/400 and had begun working on a plan to customize and migrate business operations from the ES/9000 to the AS/400.

Upon closer analysis, it was discovered that due to the specialized applications running on the ES/9000, such as the sophisticated money-exchange rate application, migration was not cost-effective. At that time, software was implemented on both servers to allow transfer of necessary information on a fixed schedule between the two machines.

Figure 4.3 Supply and Manufacturing Division network diagram before company-wide consolidation

Functions of the ES/9000

The ES/9000 is running Virtual Machine/Enterprise Systems Architecture (VM/ESA). All the division's accounting applications and the sophisticated money exchange application run on the ES/9000.

Functions of the AS/400

The AS/400 is currently running V2R3 operating system; the databases for business operations are written in a combination of DB2 and RPG/400. The AS/400 runs applications including inventory management and control, a distribution-scheduling system, a production system, and the order system for raw materials for the production of the terra cotta pots and other lines of product.

Supply and Manufacturing Division's Business Processes

The business processes at the Supply and Manufacturing division are described below. Each process is numbered, and the process flow is documented using numbers and arrows on the network diagram.

1. The Supply and Manufacturing division receives product orders from their customers (the retail stores and distribution centers) by phone or fax.

2. An employee inputs the orders on a Warp client through a front-end application to a DB2 product-ordering database on the AS/400.

3. Exchange-rate information is automatically posted to the accounting database on the ES/9000.

4. A product order summary is printed, and the production manager schedules the production of pots for the day, based on the product orders received.

5. The production staff makes the scheduled product.

6. The daily production is entered into the production DB2 database on the AS/400.

7. The daily production is automatically posted to the accounting database on the ES/9000.

8. The production system on the AS/400 generates recommended stock orders, based on the raw materials used for the day's production. The orders are printed for the plant manager to review and, upon approval, are faxed to the suppliers of raw materials.

9. The production system updates the DB2 retail-store-customer ordering system. This updates on-hand inventory and then automatically recommends filling the outstanding product orders from the retail stores and distribution centers, based on production and the date on which the orders were submitted.

10. The retail-store-customer ordering system automatically sends appropriate accounting information to the accounting database on the ES/9000.

11. The retail-store-customer ordering system updates the DB2 distribution database about which orders are to be filled.

12. The distribution system prints product pick tickets, shipping labels, and necessary customs papers.


Nursery Products Division

Operations at the Nursery Products division are simpler because all the customers of the Nursery Products Division are in the Retail Services division.

The Nursery Products Network

When Terra Flora purchased the Sacramento nursery, a DECaxp150 running DEC UNIX and PATHWORKS version 5.0 was included in the purchase. All the applications are UNIX and include the following programs.

  • Accounting
  • A product-order system, for contacting the proper supplier for specific flowers
  • A customer-order system, for tracking orders placed by the retail stores
  • A delivery system, for tracking shipments to the retail stores and calculating the expected delivery of the products to the retail stores

The Sacramento nursery is the only one that is computerized.

All business operations for the Nursery Products division are tracked in databases on the DECaxp150 server running DEC UNIX, which are listed below.

  • A customer-order database that lists the retail stores
  • A product-order database, from which product orders are calculated
  • Accounting
  • An order-delivery database, which prints product pick tickets for the shipping department
  • A labeling program, which prints package labels and international customs papers

The network diagram below represents the network computers used in the Nursery Products division.

Figure 4.4 Nursery Products Division network diagram before company-wide consolidation

Nursery Products Division's Business Processes

The following list describes the process for the Nursery Products division.

1. Customer orders for products are received by phone or fax from retail stores.

2. The orders are input on any NetWare client into a front-end NetWare application.

3. Throughout the day, customer orders are processed by an ORACLE database on the DEC UNIX server.

4. A summary, based on the days orders, is printed and input into the accounting database on the UNIX server.

5. The bookkeeper posts the accounting information.

6. Inventory is checked, and those customer orders that can be filled are filled; then product pick tickets are printed and given to the shipping department.

7. Orders are boxed, and shipping labels and customs documents are typed on an IBM Selectric typewriter.

8. A daily summary of customer orders is printed for the nursery manager. Based on the inventory stocking levels, the manager phones the local or international farms to order enough stock to fill the retail customer orders.

9. The nursery manager records the items ordered from suppliers in the ORACLE product order database.


Reengineering the Terra Flora Network

Having summarized the main facts about the operations, current network usage, and business processes of each division, the CIO begins an analysis of the business and technical problems at Terra Flora and to create a plan. The planning will occur in three phases: studying the current network, organizing goals into priority levels, and developing a way to integrate the networks in a service-based model.


Understanding the Current Network

To understand the existing Terra Flora network, the newly hired CIO must go through the following steps.

  • Identifying all hardware on the network, including clients, workstations, and servers. This information should be sufficiently detailed to help determine what equipment must be upgraded.
  • Identifying the geographic extent of both the local area networks (LANs) and the wide area networks (WANs), including the media used for the LAN and to create the WAN.
  • Identifying the location of the network components and operating systems.
  • Identifying bandwidth information.
  • Identifying specific user activities, the numbers of users doing those activities, and the usage patterns on the network.
  • Identifying specific tasks, such as storing files, server backups, posting data to a database, data replication, and application distribution.


Realigning and Prioritizing the Goals

The business goals can be organized into the following priority levels.

  • Business-critical goals
  • Strategic goals
  • User-benefit goals
  • Wish-list goals

Business-critical Goals

Business-critical goals are goals that are required to do business. These goals must be accomplished as quickly as possible. Terra Flora identified the following business-critical goals, to be accomplished in no more than three months.

  • To physically connect the three networks
  • To migrate to the same network protocol
  • To recognize security credentials, for authenticating network logons
  • To allow users to share appropriate files and printers
  • To integrate existing systems, for improving business processes
  • To reduce training requirements
  • To do business on the Internet

Strategic Goals

Strategic goals provide a clear benefit to the business. These goals can be accomplished within three to six months without harm or loss to the business. Terra Flora has the following strategic goals.

  • To centralize user accounts
  • To centralized network administration and backup
  • To centralized application distribution
  • To extend the Terra Flora network to all employees
  • To create central information stores and applications
  • To allow dynamic IP addressing in the network
  • To give all employees electronic mail
  • To electronically distribute corporate-wide information

User-benefit Goals

User-benefit goals provide a clear benefit to the user by enhancing productivity or increasing efficiency. These goals can be accomplished within six to twelve months without harm or loss to the business. Terra Flora has identified the following user-benefit goals.

  • Internet access for Terra Flora employees
  • Dial-up, telecommuting capabilities

Wish-list Goals

Goals on the wish list are amenities, but are not required. These goals can be accomplished at any time. Terra Flora has one item on its wish list, to integrate the DNS name space, using fully qualified domain names, such as mariag.terraflora.com.


Integrating the Networks Using a Services-based Model

The services provided on the network must be viewed independently of the divisional network structure. The integrated-network model groups the computers by the services they provide to the company rather than by division. The services can be grouped into four categories, called layers: Enterprise, Division, Department, and Desktop.

Table 4.1 Layers of the Services-based Network Model

Network Level | Services provided | Users
Enterprise | Support for the global network (such as centralized user accounts and network services) and providing master copies of common information across the organization | 40,000
Division | Centralized file, print, and application services, focusing on business operations | 100 to 1,000
Department | Local file, print, and application services | 25 to 100
Desktop | Local file and application services | 1 to 25

The new model also enables productive change in the following other areas.

  • Integration of the information staff
  • Centralization of network support
  • Budgeting and tracking capital expenditures

The next sections describe the network services at each level and show how these will help create an efficient network at Terra Flora.

Enterprise Services

Servers at this level focus on supporting the global network (such as centralized user accounts and administration) and providing the master copy of common information across the organization. Enterprise servers are directly connected to the corporate or remote backbone, are kept in protected environments in the work area of the network administrators, and usually operate at 100 MB per second (such as by FDDI, CDDI, or Fast Ethernet). An Enterprise server might provide networking services for up to 40,000 users.

Local availability of the servers can affect which services exist at which level. When remote distances separate the servers and the users, backbone traffic can make timely access to these services difficult. Communications across WANs can be slow and costly. This makes direct, corporate-wide access to Enterprise services impractical. It makes sense to set up the servers at this top (Enterprise) level to maintain and update information, which users would access at lower levels.

For example, a server can be the master distribution point for site- or corporate-licensed software, standard corporate applications, and employee information. The master source servers would store the master copy, which would be used to replicate sources and download to servers on the Division level. This ensures that they are synchronized with the master corporate copy. Since Division-level servers are local to the users in the division, this replication and synchronization reduces both the network traffic on the corporate backbone and the cost of WAN communications.

Enterprise servers can also host the master copy of the distribution packages deployed by Microsoft Systems Management Servers.

The services typically offered at this level include the following items.

  • Logon authentication

This service ensures that users can log on to the network and perform the tasks for which they have permission. NetLogon is the Windows NT service that performs this function.

  • Replicated user account database

This service allows a copy of the Directory Database (formerly called SAM) to be replicated on other servers, effectively distributing the logon authentication process. Under Windows NT Server, NetLogon performs this function.

  • Centralized network services

These services allow an administrator to configure network services that affect the entire network and to make any administrative changes from one site.

For example, a Dynamic Host Configuration Protocol (DHCP) server can be added to the network and configured to allow centrally defined global and subnet TCP/IP parameters for the entire internetwork. When a workstation computer moves between subnets, it is automatically reconfigured for TCP/IP at system startup.

  • Name resolution

This service centralizes the resolution of the unique user names and TCP/IP addresses that allow access to computer resources on the network.

For example, a server running the Windows Internet Name Service (WINS) server software would perform this function. WINS servers maintain a database that maps computer names to IP addresses, allowing users to communicate with other computers and gain all the benefits of using TCP/IP.

As another example, a DNS server also provides dynamic mapping of domain names to IP addresses and is the commonly used name-resolution service in environments running a UNIX operating system.

  • Backup

Servers at any level typically provide backup services for the next lower level of servers. Enterprise servers perform this function for the servers on the Division level, which, in turn, perform backups for the Department-level servers. Enterprise servers do not usually back up for the Department level.

  • Limited protocol service support

To reduce network traffic across the Enterprise backbone, servers at this level might support only one or two networking protocols. Frequently, the choice is the TCP/IP protocol.

  • Internet Services (using the Internet Information Server service)

These servers can be used to create web sites that the public can access for corporate information and customer-focused marketing.

  • Intranet Services (using the Internet Information Server service)

These servers store information that is to be available to all employees on the internal corporate network, but not to users outside of the company or organization. This might include corporate standards, employee benefits, corporate events, and other information, such as job listings. These Enterprise-level servers typically host references to the Division-level servers. For example, an Enterprise server might refer to a Division web site for the company's retail operations.

  • Site

These services affect organization sites but are hidden to the users. For example, the Enterprise servers can act as storage and master source for distribution of organization-supported software. The replicator service distributes the software to the Division level for distribution to the lower levels.

Division Services

This level typically contains the centralized file and print application, focusing on business operations. Division-level servers often provide networking services for up to 1,000 users, although they can be scaled to support larger numbers of users.

If the location of the division or region requires connecting over slower WAN links, then Enterprise services may be supplied at this level.

The Division level usually include the following services.

  • Heterogeneous file and print interfaces

These interfaces allow interoperability with other servers including UNIX, NetWare, LAN Server, and Banyan VINES.

  • Integration

This level may provide heterogeneous protocols, such as TCP/IP, IPX/SPX, SNA, and VINES IP, which allow integration with services offered on UNIX, NetWare, or mainframe Enterprise servers.

  • Intranet Information services (using the Internet Information Server service)

These servers provide corporate information that focuses on the division or region. For example, project plans, schedules, reviews, presentations, and background information for the division are stored here. Data sheets, product reviews, product comparisons, and product specification sheets may also be stored here for easy access and distribution to field sales and marketing personnel.

  • Backup

Servers at any level typically provide backup services for the next lower level of servers. For example, Division servers perform this function for servers on the Department level.

Department Services

Servers at this level focus on the business tasks. These servers provide local file, print, and application services. They also provide temporary file storage for workgroup projects, home directories, and scheduled-backup directories. In a typical scenario for this level, servers are organized by workgroups or departments to provide networking services for 25 to 100 users.

At the Enterprise level, a limited number of high-cost, high-performance servers address the centralized needs of the entire organization. At the Division level, less expensive servers provide adequate performance to a smaller group. At the Department level, a server may be a workstation-class machine, such as a 486 computer with 16 MB RAM running Windows NT Server.

Department-level servers typically provide the following services.

  • Departmental or branch-office projects

Information is stored about the department tasks and workgroup projects. Enterprise and Division servers can access this information to compile reports.

  • Intranet Information services (using the Internet Information Server service)

This information is specific to the Department. Status reports and the supporting information may be posted here for everyone to browse through at their convenience.

  • Internet services (using the Internet Information Server service)

At this level, project web sites may be created and posted to the Internet.

  • Backup

Servers at any level typically provide backup services for servers or computers on the next lower level. Department servers perform this function for Desktop computers.

Desktop Services

In most corporations, the desktop computer is the productivity platform, running either Windows 95 or Windows NT Workstation with various applications, such as Microsoft Office and custom programs for specific business needs. The focus here is to provide services to remote, mobile-networking, and desktop clients. The logical grouping of the desktop groups may include small departments of 5 to 20 people, or may include thousands of desktop computers. The services offered include the following functions.

  • Local, personal file storage

The Desktop provides local storage for personal files and application data for business applications.

  • Local applications

For productivity desktops, the local applications might include Microsoft Office Professional. For developer-class desktops, this might include Microsoft Visual C++® compilers and debug versions of the operation systems. For Internet Information Server service (IIS) developers, this might include IIS and SQL applications.


Creating the Information Plan

The 12-month objective at Terra Flora is to accomplish all the business-critical goals and as many as possible of the strategic goals.

Windows NT network services and some third-party services will be implemented to integrate the systems. Windows NT Workstation, Windows NT Server, or Windows 95 will be installed on any new equipment the company purchases, as appropriate to the role that the equipment will play in the Terra Flora network.

The information plan identifies the technical solutions for reaching the business goals as outlined in Table 4.2.

Table 4.2 Solutions for the Terra Flora Business Plan

Goal Priority | Business Goal | Technical Solutions for Information Plan
Business critical | Physically connect the three networks | Purchase routers and switches, as necessary to connect the network efficiently.
Business critical | Allow users to share files and printers as appropriate | Windows NT file and print (or, FPNW for NetWare clients; PCNFS for UNIX clients; Banyan File & Print for Windows NT for Banyan clients).
Business critical | Integrate all existing systems that facilitate business processes | Use SNA server to connect to the ES/9000 and AS/400. More analysis of the custom applications must be done for two reasons: to determine the best features of those products, and to create a plan for implementing the workstation and server applications necessary to effectively operate the business.
Business critical | Reduce training requirements | Provide a consistent, easy-to-use user interface for both desktop and server platforms. Allow connectivity to heterogeneous systems through a consistent interface.
Business critical | Do business on the Internet | The Terra Flora marketing department wants the corporation to create web pages for the Internet. These pages would feature images of popular floral arrangements. Customers would click an image to order it directly from the nearest retail order desk. Web pages would also list retail store locations and operating hours, the history of the company, product information, appropriate inventory data, and marketing information, such as seasonal specials. Internal departments responsible for maintaining web-page information would be given access to the pages.
Business critical | Migrate to the same network protocol | Install and configure TCP/IP on all platforms.
Business critical | Recognize security credentials and centrally authenticate network logons | Windows NT Network logon service will be used to authenticate credentials and provide single network log on.
Strategic | Centralized user accounts | Use Windows NT Server directory services to provide enterprise-wide user names and passwords. Trust relationships will be set up between domains, creating a single network logon.
Strategic | Centralized network administration and backup | Using Windows NT replication service for Enterprise-level databases, WINS, DNS, and DHCP services. For online backup, deploy Octopus for Windows NT. For the backup of data and software master copies, use Seagate Backup Exec for Windows NT.
Strategic | Extend the Terra Flora network to all employees | Use the built-in Windows NT RAS to connect mobile users. Use Windows NT Server PPTP to connect remote sites across the Internet, using a secure link. Create a secure communications link between the Seville site and headquarters in Sacramento.
Strategic | Create central information stores and applications | Analyze software applications to maintain the best ones, and program what is missing. Automate the manual tasks, as appropriate, such as the production line and distribution centers.
Strategic | Allow dynamic IP addressing in the network | Use Windows NT DHCP Server, and enable all capable DHCP clients.
Strategic | Give all employees electronic mail | Migrate to Microsoft Exchange.
Strategic | Electronically distribute corporate-wide information | Use Internet Information Server and Internet Explorer to distribute corporate-wide information.


Terra Flora Network Systems Diagram

The diagram inside the back cover of this book provides an illustration of the new network model for Terra Flora. All primary services and computers systems for Terra Flora are shown. For brevity, only a representative sample of worldwide retail operations is shown.

Naming Conventions

Each computer is labeled with a name that includes the following information.

  • The computer name for the server
  • The server IP address
  • The services running on that computer

The first line below each computer icon lists the computer name, which has 12 characters. These follow specific naming conventions, with each character representing additional information about the computer.

  • Characters 1 and 2

The first two characters indicate the domain of which the computer is a part. Terra Flora uses the following domain symbols.

  • CA, which represents the California domain
  • NE, which represents the North East domain
  • EU, which represents the Europe domain
  • Characters 3-7

The five characters following the domain symbol represent the operating system that the computer is running. Table 4.3 lists the five-character codes and the systems they represent.

Table 4.3 Codes for Operating Systems

Operating System Code | Operating System Description
NTS40 | Microsoft Windows NT Server 4.0
NTW40 | Microsoft Windows NT Workstation 4.0
BAN62 | Banyan 6.22
SUN25 | SPARC 2.5
NW410 | Novell NetWare 4.10
WPS30 | IBM OS/2 Warp Connect Server 3.0
LMN22 | Microsoft LAN Manager 2.2c
NTS35 | Microsoft Windows NT Server 3.51
NW312 | Novell NetWare 3.12
WIN31 | Microsoft Windows 3.1
WIN95 | Microsoft Windows 95
SCO50 | Santa Cruz Operations Open Server 5.0
WPD30 | IBM OS/2 Warp Desktop 3.0
MSD62 | MS-DOS 6.22
MAC70 | Macintosh Operating System 7.0
KIOSK | Santa Cruz Operations Open Desktop 5.0
CAPENT | DEC UNIX, with PATHWORKS 5.0
RAINIER | IBM AS/400
MAC 400001701100 | ES/9000, with Virtual Machine Enterprise Systems Architecture (VM\ESA)

  • Characters 8-10

These represent a three-character code for the service level.

  • ENT, which represents the Enterprise level
  • DIV, which represents the Division level
  • DPT, which represents the Department level
  • DSK, which represents the Desktop level
  • Characters 11 & 12

These characters are the identification number for the computer. A computer number can be any number between 01 and 99.

Computer Software

Various software was installed on different computers. This software will be used to provide services to the computer network. The first text line in the diagram is reserved for the computer's name, and line two is reserved for the computer's IP address. The remainder of the text indicates the software loaded on each computer. The following table lists the codes and descriptions of the software represented by the code.

Table 4.4 Codes for Software

Software Code | Software Description
IIS (Internet) | Internet Information Server for connecting to the Internet.
PPTP | Point to Point Tunneling Protocol used to create secure communications over the Internet between Seville remote site and Sacramento site.
Deployment Server | A big server owned by the IS department of Terra Flora. It is typically used for projects. For example, all the documentation and files for the current migration project are stored on this server.
IIS (Intranet) | Microsoft Internet Information Server for Intranet internal, corporate network.
F&P | File and Print software. Specific to providers installed on the network.
Banyan F & P | Banyan VINES 6.2 allows file and print sharing with Microsoft Windows NT.
Banyan Vines Mail | Messaging service compatible with the Banyan Operating System.
Member Server | A server running Windows NT 4.0 that is neither a PDC or a BDC.
Backup RAS | A Microsoft Windows NT system running more RAS, fault tolerance, and authentication services, to relieve tasks from the primary RAS Server.
SNA | Protocol software used on the network to connect to the mainframe ES/9000 and AS/400.
SMS Central Site | Microsoft Systems Management Server 1.2 Central Site.
CA PDC | The California PDC which is used to authenticate logon access to the network and network resources.
DHCP | Dynamic Host Configuration Protocol, used to dynamically lease IP addresses to computers when they change subnets.
WINS | Windows Internet Name System, used to dynamically provide name resolution from NetBIOS names to TCP/IP addresses.
DNS | Domain Name Space, used to provide name resolution from fully qualified domain names to IP addresses.
CA BDC | The California Back up Domain Controller, used to provide fault tolerance and to replicate the directory services database through which users are authenticated. Also will perform logon authentication.
RAS | Remote Access Service provides secure dial-up access to internal network.
GSNW | Gateway Services for NetWare enables NetWare clients to access files from Microsoft Windows NT.
FPNW | File and Print Services for NetWare enables NetWare clients to share files and print resources on servers running Windows NT.
IM3 | Intelligent Messaging mail service from Banyan.
Intranet Server | Internal corporate-network server used on corporate network to provide interactive information services to users through Internet protocols, such as HTTP, FTP, and Gopher.
Warp Authentication | Authentication for Warp Clients.
Lotus Notes Server | Groupware application.
Services for Macintosh | Allows Macintosh clients to authenticate to Windows NT directory services and access file and print services on Window NT Server.
ORACLE NLM | ORACLE NetWare Loadable Module.
LM 2.2 Client | LAN Manager 2.2c client software, providing network access to MS-DOS clients and MS-DOS-based Windows Operating systems. Also allows logon authentication to Microsoft Window NT Server Directory Services.
Banyan client | Client on the Banyan VINES Network.
TCP/IP-32 for WFW | 32bit Protect mode stack for Window 3.11.
Rmode NW redir | Real mode NetWare redirector allows MS-DOS and Windows clients to access resources on NetWare servers.
MS Net Client | The generic network client allows basic network access to Microsoft Windows NT Services.
Novell Net Client | Novell network redirector for accessing File and Print Services on NetWare servers.
X/Windows | Windowing environment for UNIX systems in an alternate client/server model.
Warp Connect | Network enabled Warp server.
MS-DOS 6.22 | Microsoft DOS version 6.22.
Microsoft Windows NTW | Microsoft Windows NT Workstation.
NFS Redir | Enables connectivity with a server providing access to the Network File System (NFS), typically UNIX Systems.
Extra! For NTW | Terminal-emulation application for mainframe host connectivity 3270/5250.
MPR | Multi-Protocol Routing allows IP packets to be routed across subnets.
NE BDC | North East backup domain controller used for authentication and replication of the directory database stored on the PDC.
EU BDC | Europe backup domain controller used for authentication and replication of the directory database stored on the PDC.


Legend for Terra Flora Network System Diagram

Element | Description
 | Mainframe or minicomputer Windows NT Server Non–Windows NT server Workstation Router, switch, or other network device Communication device rack Printer ISDN or POTS connection Internet or X.25 connection
Enterprise | Network service layer Enterprise, Division, Department, and Desktop define the four realms of service in the Terra Flora network management model.
California (CA) | Windows NT domains Terra Flora has three domains in the Windows NT domain structure.
172.16.16.0 | Subnet Subnets in the Terra Flora network. Terra Flora uses the subnet mask 255.255.240.0.
Ethernet 10 Mbps | Local network or WAN type Type and speed of local network media or WAN lines.


Computer Description

  • CANTS40ENT03

172.16.48.1

  • Authentication Server (PDC)

DHCP, WINS, DNS,
Microsoft SQL Server

  • IP address configuration Static IP addresses, listed. Dual-homed computers list more than one IP address. DHCP Assigned means TCP/IP configuration is controlled through a DHCP server. No IP Address means no IP address. The two routers have the following IP address configuration:

CABNR10ENT01

172.16.16.245, 172.16.23.245

172.16.48.245, 172.16.64.245

CABNR10ENT02

172.16.80.245, 172.16.96.245

172.16.112.245, 172.16.128.245, 172.16.144.245

  • Computer's primary role Primary network or business function performed by the computer.
  • Software installed Services or applications installed on the computer. For a complete list of software and the codes used on the diagram, see Chapter 4 of the Windows NT Server Networking Guide in this Resource Kit.
  • Computer name Each computer name is separated into four sections, each of which indentifies a characteristic of that computer. For example:

C A N T S 4 0 E N T 0 3

Windows NT Domain

Network service layer

Computer number

CA | California | ENT | Enterprise | These characters represent the
NE | Northeast | DIV | Division | identification number for the computer.
EU | Europe | DPT | Department | A computer number can be any number
 |  | DSK | Desktop | between 01 and 99.

Operating System

Code | Description
BAN62 | Banyan VINES 6.22
BNR10 | Bay Networks Router running GAMES 10.1
BNS00 | Bay Networks Switch
LMN22 | Microsoft LAN Manager 2.2c
MAC70 | Macintosh Desktop 7.0
MSD62 | MS-DOS 6.22
NTS35 | Microsoft Windows NT Server 3.51
NTS40 | Microsoft Windows NT Server 4.0
NTW40 | Microsoft Windows NT Workstation 4.0
NW312 | Novell NetWare 3.12
NW410 | Novell NetWare 4.10
P (CAPENT)* | DEC UNIX with PATHWORKS 5.0
RAINIER* | IBM AS/400
SCO50 | Santa Cruz Operations Open Server 5.0
SUN25 | SPARC 2.5
WIN31 | Microsoft Windows 3.1
WIN95 | Microsoft Windows 95
WPD30 | IBM OS/2 Warp Desktop 3.0
WPS30 | IBM OS/2 Warp Connect Server 3.0
400001701100* | MAC address for ES/9000 with Virtual Machine Enterprise Systems Architecture (VM\ESA)

* These computer names do not follow conventions due to technical reasons.


Chapter 5 - Network Services: Enterprise Level

The following chapter is a tested but largely unedited draft of material that will appear in expanded form in the next update of the Windows NT Server Resource Kit. At that time, the case study will be further revised and expanded to include details about the Divisional, Department, and Desktop server services and other helpful information.

Chapter 4 introduced Terra Flora, a hypothetical case study of a fictitious company and of the challenges that company faces in bringing together its diverse, previously independent networks. The purpose of the case study is to show in real-world terms how network administrators and information officers can utilize Windows NT to integrate new and legacy hardware and software in a cost-effective way. The chapter further analyzed the Terra Flora case and developed a plan for interoperability. The next step for Terra Flora is to make choices about the Windows NT Server services and to configure those services.

Services will ultimately be configured on four defined levels of usage, depending on the scope of those services within the organization. These levels are, in order of increasingly narrow scope: Enterprise, Division, Department (or Branch Office), and Desktop. This chapter will deal with server services, but only on the Enterprise level. Detailed discussions of service configurations for the other three levels are not included in this edition of the Microsoft Windows NT 4.0 Networking Guide.

Enterprise-level server services are the those provided on a large scale to the entire network. These services primarily support the network itself; they are services that support other servers and keep the corporation-wide information synchronized on all areas of the network. These services include the following:

  • Dynamic Host Configuration Protocol (DHCP)
  • Windows Internet Name Service (WINS)
  • Domain Name System (DNS)
  • Network Logon Services
  • Centralized Services
  • Replication
  • Backup
  • Point-to-Point Tunneling Protocol

This chapter will make repeated references to the Terra Flora Network Diagram, printed on the inside back cover of this book. For convenience, open the diagram now so that you can easily refer to it as you read these discussions.

Terra Flora is a totally fictitious company whose business operations and networking environment are being examined and used to demonstrate the functionality of Windows NT Server products throughout this Interoperability section. The names of companies, products, people, characters, and data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted.


Preparations for Configuring Services

Before configuring services, Terra Flora needed to set up the hardware for these services and to adopt the protocols that the networks would use to communicate among themselves and with the Internet. The new protocols must then be installed and configured.


Selecting Protocol Standards

The first decision Terra Flora needs to make is which protocol to adopt as the protocol-of-choice for their network, which protocols to retain, and which to abandon.

Terra Flora's Choice of Protocols

Terra Flora elected to use Transmission Control Protocol/Internet Protocol (TCP/IP) as their network protocol of choice, while retaining Systems Network Architecture (SNA) protocols for connection to the legacy systems.

Why Terra Flora Chose TCP/IP as a Primary Standard

TCP/IP is a standard set of networking protocols that govern how data passes between the networked computers. With TCP/IP, Terra Flora networks will interoperate by using the Windows NT Workstation and Windows NT Server platforms with devices that use Microsoft Windows 95, other Microsoft networking products, and non-Microsoft operating systems, such as UNIX.

Many reasons supported the Terra Flora decision to use TCP/IP as the preferred network protocol.

TCP/IP is the primary protocol of the Internet and the World Wide Web. One of the primary goals of Terra Flora is to establish a presence on the Internet, allowing customers, nurseries, retail stores, and manufacturing sites to place orders directly. Terra Flora sees this as essential to keeping Terra Flora competitive.

TCP/IP is a very clean and efficient suite of standard protocols that can be used on both local and wide-area networks (WANs) to provide communications between all the basic operating systems on the network.

TCP/IP has the advantage of already being in place in parts of the Terra Flora network. TCP/IP currently supports communications between all UNIX-based systems and the AS/400 at Terra Flora, and is running on the following equipment.

  • Computers running Windows NT Workstation and Windows NT Server
  • Computers running Windows for Workgroups
  • Computers running Windows 95
  • Computers running LAN Manager

For a detailed discussion on TCP/IP see Chapter 6, "TCP/IP Implementation Details."

Why Terra Flora Chose SNA as a Secondary Standard

SNA Protocol enables communication between the department and divisions servers and the enterprise mainframe and AS/400 legacy application services. In the near future, SNA will remain, but Terra Flora plans to review the options of moving all the SNA dependent services to TCP/IP in a cost effective manner. If this is not an option, SNA will remain on the network as the protocol to access the legacy applications.

Why Terra Flora Rejected Other Protocol Options

Three other protocols are currently in place in various parts of the Terra Flora networks. The decisions to abandon these protocols as network standards were based on the reasons given in each case, as described below.

IPX/SPX

In the past, Terra Flora used the IPX/SPX protocol only in the Nursery Products division, to support NetWare services. IPX is easy to install and is dynamic in that it requires no configuration changes for either mobile or relocated network nodes.

Despite these advantages, the expense and performance degradation anticipated under this protocol for such a large and diverse network deterred Terra Flora from establishing IPX/SPX as a protocol standard. The protocol's reliance on network-wide broadcasts make overhead unreasonably high for effective WAN implementations.

IPX/SPX protocol depends on broadcasts of Service Advertising Protocol (SAP) and Routing Information Protocol (RIP) packets for network name-resolution services built into NetWare. SAP and RIP broadcasts are updated every sixty seconds by each server and sent to the entire network. These ongoing broadcasts are negligible within a local LAN environment. However, when IPX networks are connected in an enterprise manner, SAP and RIP broadcasts can dramatically erode the available bandwidth.

For the immediate future, Terra Flora will continue to use IPX/SPX for interchange of files between NetWare and other networking clients. Within the next year, Terra Flora aims to replace all hardware that depends on the IPX/SPX protocol with hardware that utilizes TCP/IP, and to phase out the IPX/SPX protocol.

AppleTalk

AppleTalk is a Macintosh-based protocol that runs primarily in peer-to-peer situations and has very limited support on other platforms.

At Terra Flora, AppleTalk has been used locally in the Retail Services division for graphics-art communications between Macintosh computers, which store the graphic software. Due to the small number of machines, the Macintosh computers were hooked together to form a peer-to-peer network.

Under the new Terra Flora plan, Windows NT Server Services for Macintosh will be added to the departmental servers running Windows NT Server, to provide file interchange and primary support for the Macintosh computers and the rest of the network. Although the Macintosh computers don't support TCP/IP, AppleTalk is enabled on the routers, allowing the Macintosh computers to communicate with the Department-level servers running Windows NT Server Services for Macintosh.

NetBEUI

NetBEUI is a non-routed, broadcast-based protocol. The master browser on TCP/IP networks cannot see or display computers that use NetBEUI to communicate with the network in the network browser list.

NetBEUI was used as a legacy protocol for networking between Windows 3.1 and MS-DOS clients. Terra Flora has already removed NetBEUI from all bridges and routed networks. Within the next six months, the Terra Flora client computers that rely on NetBEUI will be removed from the network or upgraded to Windows 95. The plan at Terra Flora is that no NetBEUI traffic will exist on any network segment after the next six months.


Installing and Configuring TCP/IP

Protocols are selected during the installation of a Windows NT operating system. The TCP/IP protocol must be configured differently for the various clients and client services.

The Terra Flora plan is to reduce network administration and improve performance by installing DHCP, WINS, and DNS to dynamically address computers, resolve names, and easily integrate with the existing UNIX environment. The installation of DHCP for dynamic addressing will decrease administration by lowering the number of entries necessary when the computers are moved from one physical location to another. The installation of WINS and DNS to resolve names will decrease the network traffic caused by computers announcing their presence to the network.

Configuring TCP/IP Clients

Only clients running an operating system software from the list below can be configured to act as a DHCP and WINS clients.

  • Windows NT Workstation version 3.5 or higher
  • Windows NT Server version 3.5 or higher
  • Windows for Workgroups 3.11 with the Microsoft 32-bit TCP/IP VxD installed
  • Microsoft Network Client for MS-DOS with real mode TCP/IP driver; this is one of the clients included on the Windows NT Server 3.5 or higher product
  • LAN Manager 2.2x for MS-DOS, included on the Windows NT Server version 3.5 CD-ROM and in the Windows NT Server 4.0 product
  • A Windows 95 computer

The configured clients can request DHCP IP addresses from computers running Windows NT Server DHCP service to communicate on the network with other computers. Configured clients can register their NetBIOS names with computers running Windows NT Server WINS service. The names and IP addresses will be passed to other computers to permit communications between the computers on the network. The configured clients can be located by computers running Windows NT Server DNS service and, therefore, communicate with other computers on the network.

Additional information on DHCP, WINS, and DNS appears later in this chapter and in Chapter 7 "Managing Microsoft DHCP Servers"; Chapter 8, "Managing Microsoft WINS Servers"; and Chapter 9, "Managing Microsoft DNS Servers."

The ability to use Windows NT Server DHCP service to obtain an address at startup is configured on the TCP/IP Properties dialog box, as illustrated on the Microsoft TCP/IP Properties dialog box below.

To open the TCP/IP Properties dialog box

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Protocols tab.

4. In Network Protocols, click TCP/IP Protocol.

5. Click Properties.

The Microsoft TCP/IP Properties dialog box appears.

All three client services, DHCP, WINS, and DNS will be configured using this graphical interface.

Configuring the DHCP Client

A computer running Windows NT Server DHCP service can be configured to automatically provide IP addresses of the WINS and DNS servers used in the name resolution process. This removes the requirement of individually configuring each client with the WINS and DNS server IP addresses.

To configure a DHCP client

· In the IP Address tab of the Microsoft TCP/IP Properties dialog box, click Obtain an IP address from a DHCP server, and then click OK.

You must restart your computer for the new settings to take effect.

Notes

  • During the setup of Windows NT Workstation, you can elect to receive an IP address from a DHCP server. If you select Yes, then Obtain an IP address from a DHCP server is set as the default, and the procedure above is unnecessary.
  • The client computer will attempt to lease an IP address from the computer running Windows NT DHCP Server service. To obtain an address, the Scopes must be defined for the DHCP Server and addresses assigned to the Scopes for the client's subnet.

Configuring the WINS Client

A computer running Windows NT Server DHCP service can be configured to automatically provide IP addresses of the WINS and DNS servers used in the name resolution process. This removes the requirement of individually configuring each client with the WINS and DNS server IP addresses. The only requirement for the client is to click Obtain an IP address from a DHCP server in the Microsoft TCP/IP Properties dialog box.

The ability to use the Windows NT Server WINS service to resolve a client-computer request for other network computer names mapped to IP addresses is configured through TCP/IP. To do this, you need to know the following information.

  • Primary WINS Server address. This is the IP address of the WINS server that the client will register its name and IP address with.
  • Secondary WINS Server address. This is the WINS server that the client will register with and which will be used if the Primary WINS server is unavailable.

To configure a WINS client

1. In the Microsoft TCP/IP Properties dialog box, click the WINS Address tab.

2. Type the appropriate server addresses in Primary WINS and Secondary WINS.

3. Set the following options.

  • To ensure that DNS servers will also be used to resolve client requests, select the Enable DNS for Windows Resolution check box.
  • To ensure that the LMHOSTS file will be used to resolve name requests from the client if WINS should fail, select the Enable LMHOSTS Lookup check box.

4. Click OK when all settings are entered, as shown in the dialog box below.

You must restart your computer for the new settings to take effect.

Configuring the DNS Client

A computer running Windows NT Server DHCP service can be configured to automatically provide IP addresses of the WINS and DNS servers used in the name resolution process. This removes the requirement of individually configuring each client with the WINS and DNS server IP addresses. The only requirement for the client is to click Obtain an IP address from a DHCP server in the Microsoft TCP/IP Properties dialog box.

The ability to use the Windows NT Server DNS service to resolve client requests for other network computer names is configured through TCP/IP.

To configure a DNS client

1. In the Microsoft TCP/IP Properties dialog box, click the DNS tab.

2. In Host Name, type the client computer name.

3. In Domain, type the name of the authoritative domain.

4. Under Domain Service Search Order, type the IP address of the server that will be used to resolve DNS name queries, and click Add.

The TCP/IP DNS Server dialog box appears.

5. In DNS Server IP address, type the IP address of the DNS server that will be searched to resolve name-to-IP address queries, and click Add.

6. In Domain Suffix Search Order, type the domain suffix, click Add, and then click OK.

You must restart your computer for the new settings to take effect.

Notes

  • The domain name that would be entered for Terra Flora in step 3 of this procedure is Terraflora.com. For a complete discussion of domain names, see Chapter 3, "Implementation Considerations" of the Microsoft Windows NT Server 4.0 Networking Supplement.
  • DNS Service Search Order contains the IP addresses of any DNS servers on the network (whether running Windows NT Server 4.0 DNS service or not).
  • Domain Suffix Search Order indicated which subdomains will be searched to resolve the name queries.


Dynamic IP Addressing

All networked computers require both a unique name and address to communicate with any other networked computer. These addresses can be either dynamic or static.

  • Dynamic addressing automatically assigns an address to a computer when the computer is turned on or is moved to a different location (subnet) on the network.
  • Static addressing requires that an administrator configure new addresses.


Terra Flora's Choice of Addressing Services

Terra Flora has elected to use the Windows NT Dynamic Host Configuration Protocol (DHCP) to provide dynamic IP-addressing of the network computers.

Static configuration of client addresses can be expensive in terms of administrative effort and time. Currently, DHCP is the only open standard, which means it can interoperate with other operating systems. All other dynamic addressing products are proprietary.

Also, Terra Flora previously decided to standardize on the TCP/IP protocols with limited support for SNA protocol. The choice of DHCP helps keep the network administration costs down.

Other factors in the decision were Terra Flora's anticipated rate of corporate growth, the network requirements of traveling corporate personnel, and the requirements of the Internet. By setting up a dynamic system for addressing, Terra Flora can more easily accomplish its business goals in these areas.

Several tasks need to be accomplished to set up DHCP services for Terra Flora.

First, the servers that will become the DHCP servers need to be set up with static server addresses and then the DHCP Service must be installed on those servers.

Second, all the servers with DHCP enabled must be added to the DHCP Manager server list so that they can be administered.

Third, DHCP Scopes must be defined. This further involves establishing ranges of leased addresses for each subnet and configuring the optional configuration settings for those leases.

Fourth, Terra Flora will use DHCP Manager to reserve some IP addresses on the network for certain computers and devices.

Fifth, Terra Flora will configure a DHCP Relay Agent.

Administrative costs are reduced when network IP addressing tasks are performed by the servers instead of the administrative personnel; who are then free to perform other tasks. For example, the administrative task such as setup and maintenance of manual IP address tables to indicate which computer has which IP address will eliminated along with the need for administrators to travel to the physical location of computers to input or change the IP addresses.

Windows NT Server 4.0 supports DHCP to provide dynamic network addressing to clients. Currently it is the only open standard which can interoperate with other operating systems other products are proprietary.


Configuring DHCP

Procedures Used to Set Up DHCP

Computers running Windows NT Server are already placed throughout the Terra Flora network. On the Terra Flora network diagram, servers operating the DHCP service have been located in all three domains. In the California domain, CANTS40ENT03 is designated as a DHCP server. In the Northeast domain, NENTS40ENT01 plays that role, and in the Europe domain, it is EUNTS40ENT01. The DHCP service is part of the Windows NT Server product, and enabling the service is simple to do.

Configuring Static Server Addresses

A client computer obtains an address from a computer running the DHCP service when the client computer starts up. This depends on the client being able to locate the server responsible for leasing it an IP address. Because of this, the IP address of the server must not change; that is, the server running the DHCP service must have a static (unchanging) IP address.

To configure a static server address

1. In the Microsoft TCP/IP Properties dialog box, click the IP Address tab.

2. In Adapter, select the network adapter for which you wish to specify an IP address (if necessary), and then click OK.

3. Click Specify an IP address.

The settings in your dialog box will be similar to the following:

You must restart the server for these settings to take effect.

The option selected in the diagram is Specify an IP address. The administrator assigns a static IP Address, Subnet Mask, and Default Gateway address for the DHCP server.

Note If the administrator specified an IP address and IP address information during the setup of Windows NT Server, the above step can be skipped.

Installing the DHCP Service on the Windows NT Server

DHCP can be installed as part of Setup. If DHCP is not installed as part of Setup, it must be configured on at least one network computer running Windows NT Server.

To install the DHCP server service on a computer running Windows NT Server

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Click Add.

The Select Network Services dialog box appears.

5. In Network Service, click Microsoft DHCP Server.

6. Click OK if loading from the network.

Or, click Have Disk to load the software from disks or a CD-ROM.

7. Type the full path to the Windows NT Server DHCP files, and then click OK.

You must restart the server for the changes to take effect.

Note

You must be logged on as a member of the Administrators group to install the DHCP service.

Accessing the DHCP Manager

The addition of the DHCP service places DHCP Manager on the Administrative Tools menu. Once the installation is complete on the computer running Windows NT Server, use DHCP Manager to complete the configuration of the DHCP server.

To access DHCP Manager

Click Start, point to Programs, point to Administrative Tools, and click DHCP Manager.

Adding Servers to the Server List

Using the DHCP Manager, the administrators at Terra Flora can configure, set up and maintain all the computers running Windows NT Server with the DHCP Server service enabled from a single computer or from any computer.

The DHCP Manager contains a list of the servers that it can administer. Initially, this list is empty. Until servers are added to the server list, the options provided with DHCP are not available. Even the first computer running Windows NT Server on which you install DHCP must be added to the server list before it can be administered. DHCP Manager.

To add a DHCP server to the Server List

1. On the Server menu of DHCP Manager, click Add.

The Add DHCP Server to Server List dialog box appears.

2. In DHCP Server, type the IP address of the DHCP server to be added to the list, and then click OK.

3. Repeat steps 1 and 2, if necessary, to add all the network computers running Windows NT Server with DHCP service enabled.

Note

You cannot administer network servers running other dynamic addressing programs from a computer running Windows NT Server with DHCP service enabled.

Managing DHCP Scopes

On any given network, for clients to obtain dynamic IP addresses, there must be at least one computer running Windows NT Server DHCP service. Once the DHCP Server service is installed on a computer running Windows NT Server, and the Windows NT server is added to the server list, a DHCP scope must be created.

A DHCP scope consists of a pool of IP addresses on a given subnet, such as 223.223.223.1 to 223.223.223.200, that the DHCP Server can lease to DHCP Clients.

At Terra Flora, each computer running Windows NT Server DHCP service will store at least one scope containing the ranges of IP addresses that the Windows NT Server DHCP service can lease to requesting clients. Each scope will contain a unique pool of addresses from which to assign IP addresses.

Refer to the Terra Flora diagram. On the California domain PDC, a scope will be named CAPDCDHCP and will contain its own unique pool of IP addresses that will be assigned as clients start up. The scope on the BDC will be named CABDCDHCP and will also have a unique pool of addresses.

When the computer running Windows NT Server DHCP Service receives a request from a DHCP enabled client for an IP address, the DHCP server will select an available IP address from its pool of IP addresses and offer it to the DHCP client, along with other configuration information that can be displayed using various DOS commands.

The computers running Windows NT Server DHCP service will not only provide Terra Flora with the ability to dynamically configure clients IP addresses, but DHCP will, as part of the service it provides, record that address as leased to the client, eliminating the need for manual tracking of IP addresses. The DHCP leasing policy can be fully configured by administrators, eliminating any need for manual intervention.

The Windows NT Server DHCP service lease mechanism provides the following benefits:

  • No need for user configuration.

Users no longer need to acquire an IP address from an administrator to properly install and configure TCP/IP. When a client is configured to use automatic DHCP, it will automatically lease an IP address from a DHCP Server at start up.

  • No more configuration errors.

The Windows NT Server DHCP Service supplies all of the necessary configuration information to all of the DHCP-enabled clients and servers. As long as the DHCP Server maintains the correct configuration information, none of the clients or servers will ever be incorrectly configured. At Terra Flora, the difficulty of tracing network problems that resulted from incorrectly configured workstations and servers will be a thing of the past.

  • Very little administrative overhead.

Administrators define a pool of IP addresses that the Windows NT DHCP Service will lease to the DHCP clients. Administrators no longer need to keep track of which IP address are in use and which IP addresses are available.

  • No need to reconfigure clients or servers that change subnets.

When the client computer changes subnets and starts up on its new subnet, it will lease an IP address from a Windows NT Server running the DHCP Service that is appropriate for the subnet on which it is now located.

  • DHCP client configurations automatically updated during the renewal process.

For example, if you change a DNS server address, it gets distributed to the network client dynamically.

Note

DHCP clients will cache their old IP addresses and will request the old IP addresses from the DHCP server if it is available. In most cases, the DHCP server will have the address available, as it assigns new addresses before scavenging old addresses.

A scope includes the following:

  • A range of IP addresses that can be leased by DHCP clients, referred to as a pool of IP addresses or an IP address pool. Each DHCP scope will have a unique pool of IP addresses, which it can lease to DHCP clients. The IP addresses in the pool will not exist in a scope stored on any other network computer running Windows NT Server DHCP service.
  • A valid Subnet Mask for the pool of IP addresses.
  • Any IP addresses in the IP address pool range that need to be excluded so that they will not be leased to DHCP clients, such as the IP addresses of the other DHCP servers on the network, WINS and DNS servers, subnet addresses, router IP addresses, or any range that will be used on the network by devices requiring static IP addresses.
  • The duration of the IP address lease, which defaults to three days.

The maximum lease duration can be set to either 'Unlimited' or up to 999 days, 23 hours, and 59 minutes. For details on what happens when a lease expires, see Chapter 7, "Managing Microsoft DHCP Servers."

The default length of an IP address lease can be configured to a longer or shorter amount of time by an administrator.

Based on the number of available IP addresses in the DHCP scopes, how many of the scope's IP addresses will typically be in use by DHCP clients, and the frequency with which the DHCP clients will be rebooting or changing subnets, the lease duration for a DHCP Lease duration at Terra Flora will be configured at 7 days. This will provide a good balance between having too many addresses leased out to computers that are no longer on the network, and the renewal network traffic.

At Terra Flora, the guidelines for determining the appropriate lease duration were:

  • Increasing the Lease Duration

Terra Flora had to consider the number of IP addresses available in each DHCP scope. If there would be a large number of IP addresses available in the DHCP scope and relatively few DHCP clients, the lease duration should likely be increased in length. Increasing the lease duration would reduce the frequency that the DHCP clients will query the DHCP Server to renew their leases and therefore somewhat reduce network traffic.

  • Reducing the Lease Duration

If there was to be a limited number of IP addresses available in the DHCP scope, most of which will be in use at any given time, it would be desirable to reduce the lease duration. In addition, if DHCP clients on a given network would frequently be changing subnets and therefore requiring a different IP address, it would be beneficial to reduce the lease duration, especially if there are a limited number of IP addresses available. Reducing the lease duration would require DHCP clients to renew their leases more frequently, but would also ensure that any unused IP addresses in the pool are seen as available to lease by the DHCP server as soon as possible.

  • The name of the scope, which is a maximum of 128 characters, and a descriptive comment about the DHCP Scope.

At Terra Flora, the descriptive comment will be the name of the Domain on which the DHCP server resides.

The creation of DHCP servers scopes is performed from the DHCP Manager

To create a scope

1. Open DHCP Manager and double-click the DHCP server you want to manage.

2. On the Scope menu, click Create.

3. Under IP Address Pool, enter the server's beginning IP address in Start Address.

4. In End Address, enter the last IP address.

5. To add exclusion ranges, type a range in Exclusion Range, and click Add; then repeat for as many ranges as you want to set.

6. To remove exclusion ranges, click the range in Excluded Address, and then click Remove.

7. Under Lease Duration, click Limited To and enter the amount of time that the lease will last.

8. In Name, type the name of the scope.

9. If appropriate, type remarks in Comment, and then click OK.

Terra Flora will configure a scope named "California" for the California Domain on the PDC. The Lease Duration at Terra Flora will be defined at seven days.

Note Once the administrative scope has been created, it must be activated before the DHCP Server will lease any IP addresses from the DHCP scope's IP address pool.

A DHCP scope is activated and deactivated from the DHCP Manager Scope menu. In DHCP Manager, active scopes will be preceded by a light bulb icon that looks as it is turned on and deactivated scopes will be preceded by a gray light bulb that looks as if it is turned off.

Once a DHCP scope has been created any of the scope's settings, such as the range of the IP address pool, it can be modified from the Scope Properties menu.

Reserving IP addresses

The DHCP Manager allows the reservation of a specific IP address for a computer. At Terra Flora, the plan is to reserve DHCP IP addresses on the network in the scope for the following devices and computers:

  • Domain controllers (since the network also uses LMHOSTS files that define IP addresses for domain controllers).
  • Clients that use IP addresses assigned by another TCP/IP configuration method, such as UNIX DNS and netware clients.
  • Any DNS Servers on the network, whether running Windows NT Server 4.0 DNS service or not.
  • Any Windows NT Server with WINS enabled.
  • Any Routers used to direct network traffic between subnets.
  • Any DHCP servers.

The IP address for the DHCP servers were assigned during the Windows NT Server Setup. The addresses assigned to the DHCP servers will now be reserved for those servers.

The administrator will reserve IP addresses using Add Reservations on the DHCP Manager Scope menu. When the computer client requests an IP address from the DHCP Server, the DHCP Server will always return the reserved IP address.

Note

The static addresses placed in Add Reservations will always override any configuration options specified using DHCP Manager.

To reserve a client address in DHCP:

1. In DHCP Manager, double-click the DHCP server you want to manage.

2. Click the scope in which you want to add reservations.

3. On the Scope menu, click Add Reservations.

Two important entries in the dialog box are:

  • Unique Identifier

The unique identifier is the media access control (MAC) address for the DHCP client and can be obtained by typing the following command at the command prompt on the client computer for which the address will be reserved:

  • IPCONFIG -ALL.
  • Press enter.
  • The MAC address is the address labeled as the Physical Address.
  • Client Name

This entry should be the computer name of the DHCP client. The name is used only for identification purposes. This entry is not available when adding reservations for MS-DOS–based DHCP clients.

Notes It is critical that Unique Identifier entry be correct because the MAC address is sent as part of the DHCP client's request for an IP address to the DHCP Server. If this value is not correct, no match is found on the DHCP server, which means the DHCP Server will assign the client any available IP address instead of the reserved IP address.

On Windows 95 clients, you must run the program Winipcfg.exe to view the MAC or physical address.

Configuring DHCP Options

At a minimum, a DHCP server must provide the DHCP client with the following information:

  • A valid IP address to lease (configured when the DHCP Scope is created).
  • A Subnet Mask (configured when the DHCP Scope is created).
  • A Default Gateway, which defaults to an IP address of 0.0.0.0 if not configured.

These items are referred to as configuration parameters. There are about 60 other predefined DHCP configuration parameters, called options, that an administrator can configure through the DHCP Manager for one or all scopes on a DHCP server. For a complete listing of the options and their meanings, see Chapter 7, "Managing Microsoft DHCP Servers"

There are four methods that can be used to set the DHCP Options:

  • Global

When you set a global DHCP option, the option takes affect for all DHCP scopes defined on the selected DHCP server. Global DHCP options appear in the DHCP Manager with a globe icon proceeding them.

  • Scope

Setting a scope DHCP option will set the option only for the selected scope on the Options Scope menu. DHCP options configured for a scope are displayed with a series of computer icons proceeding them in DHCP Manager.

  • Default

Setting a default DHCP option modifies the default value for one of the DHCP Options. When a default value is set, the default value becomes the default that was set during administration rather than the DHCP default that was set during installation of DHCP.

  • Client

This method can be used to configure one or more of the DHCP options for a specific DHCP client. DHCP options can be set for a client only if the DHCP client has a reserved IP address. The only way to see if a DHCP option is set for a DHCP client is to view the properties of an active client lease on the Scope Active Leases menu and then clicking Options.

Configuring a Global, Scope, or Default DHCP Option

Configure a Global, Scope, or Default DHCP Option on the DHCP Options menu by clicking Global, Scope, or Default.

If Scope or Global is selected, the following dialog box appears, indicating which menu option was selected by printing the title of the menu option in the title bar.

To configure DHCP options globally or by scope

1. In DHCP Manager, double-click the DHCP server you want to manage.

2. Click the scope for which you want to configure DHCP Options.

3. On the DHCP Options menu, click Global to change options globally.

Or, click Scope, to change options by scopes.

4. Click Edit Array.

Enter the changes that you want for DHCP options.

Using the dialog box, the administrator can change or add a new DHCP option to the list and configure it with the proper settings.

To configure Default DHCP Options

1. If necessary, click the DHCP Standard Options default as the value in Option Class.

2. In Option Name, click Change to change the default.

Or, click New to create a new default.

3. When the fields that need to be changed appear, enter the appropriate settings, and then click OK.

Configuring DHCP Options for a Particular Client

Configuring client options can be performed only if the IP address for the client has been reserved. Configuring client options is performed using a different graphical interface than was used to configure the Global, Scope or Default options.

For details about reserving addresses, see "Reserving IP addresses," earlier in this chapter.

To configure DHCP options for a particular client

1. Click the server where the reserved client's IP address resides for which you want to enable options.

2. Click the scope that contains the client reservation.

3. On the Scope menu, click Active Leases.

4. Click the client that you want to configure.

5. Click Properties.

6. Click Options.

The DHCP Options: Reservations dialog box appears.

7. In Unused Options, click the option you want to add for the client, and then click Add.

8. To change or enter a value for the option, click it in Active Options, and then click Value.

9. Enter the appropriate value, and click OK.

For a complete description of the options available, see Chapter 7, "Managing Microsoft DHCP Servers."

Precedence of DHCP Options

If a DHCP option is set for more than one level, such as for both global and scope, precedence is in the following order:

  • Client overrides both scope and global.
  • Scope overrides global.
  • If there is no client or scope setting for a DHCP option, then the global setting has precedence.
Benefits of DHCP Options

These include:

  • Centrally administered network settings
  • Dynamic updates
  • No need for manual entry on every client
Commonly Configured DHCP Options

Some of the DHCP options administrators typically configure are:

  • 003 Router

The Router parameter requires the IP addresses for one or more routers and is the equivalent of the Default Gateway entry in the TCP/IP configuration dialog box.

  • 006 DNS Servers

The Domain Name Server parameter requires the IP addresses for one or more DNS servers.

  • 015 Domain Name

This option is used to specify DNS domain names to be used for host name resolution.

  • 044 WINS/NBNS Servers

The WINS/NBNS (NetBIOS Name Servers) Servers parameters requires IP addresses for one or more WINS/NBNS servers.

  • 046 WINS/NBT node type

This DHCP option can be used to configure the method that the DHCP client will use to resolve computer (NetBIOS) names: 0x1 (b-node), 0x2 (p-node), 0x4 (m-node), or 0x8 (h-node).

Note

A computer running Windows NT Server DHCP service can be configured to automatically provide IP addresses of the WINS and DNS servers used in the name resolution process. This removes the requirement of individually configuring each client with the WINS and DNS server IP addresses. The only requirement for the client is to click Obtain an IP address from a DHCP server on the Microsoft TCP/IP Properties dialog box.

Configuring a DHCP Relay Agent

Computers running Windows NT Server DHCP service have the ability to use the bootP relay service which enables clients on one subnet to access a DHCP server on another subnet. Refer to the Terra Flora network diagram. In the Terra Flora California domain, all the servers running Windows NT Server DHCP service are located on the Enterprise level.

There are three subnets in the California domain, and only one subnet contains the servers running Windows NT Server DHCP service. The two subnets that do not contain computers running Windows NT Server DHCP service have a computer running Windows NT Workstation or Windows NT Server that acts as DHCP relay or bootP relay agent. The DHCP bootP relay agents are named CANTS40DIV03 and CANTS40DPT02.

When a dynamic client computer on the subnet where the bootP relay agent resides requests an IP address, the request is forwarded to the subnet's bootP relay agent. The bootP relay agent, in turn, is configured to forward the request directly to the correct computer running Windows NT Server DHCP service. The computer running Windows NT Server DHCP service returns an IP address directly to the requesting client.

For a detailed discussion on the bootP relay agents, see Chapter 7, "Managing Microsoft DHCP Servers."

Configuration of the DHCP bootP relay agent is a two-step process. The first step is to install the DHCP Relay Agent Service on the computer that will act as a bootP relay agent. The DHCP Relay Agent Service is a Windows NT Server service. The bootP agents can then be configured, using the Microsoft TCP/IP Protocol Properties dialog box, with the IP address of the computer running Windows NT Server DHCP, so the agent will know where to forward requests from clients for available IP addresses. Installing the service and configuring the agents are both performed using Network in Control Panel.

To install the DHCP Relay Agent Service

1. In the Network dialog box, click the Services tab.

2. Click Add.

3. Under Network Service, click DHCP Relay Agent, and then click Have Disk if loading the software from disks or a CD-ROM.

Or, click OK if loading from the network.

4. In the message that appears, type the full path to the Windows NT Server DHCP files, and click OK.

The DHCP service is installed.

5. Click Close.

Configuration and binding information is checked.

You must shut down and restart the computer before the new settings will take effect

Addition of the TCP/IP address of the computers running Windows NT Server DHCP service to the bootP relay agents is performed in the TCP/IP Properties dialog box.

To add an IP address to the bootP relay agent:

1. In the Network dialog box, click the Protocols tab.

2. Click TCP/IP Protocol, and then click Properties.

3. Click the DHCP Relay tab.

4. Check that the Seconds threshold and Maximum hops settings are set at 4.

5. Under DHCP Servers, type the IP address of the server that will provide the IP addresses to the subnet's requesting clients.

6. Click Add, and then click OK.


Name Resolution Using WINS and DNS

Due to the heterogeneity of the network at Terra Flora, administrators have decided to implement two Windows NT Server services to manage all name resolution issues. Windows Internet Name Service (WINS) and Domain Name System (DNS).

Terra Flora is interoperating several heterogeneous networks. To communicate, each computer needs a unique computer address and name. There are two types of names and both types exist on one or more of the small Terra Flora networks being merged into one large network. Windows NT network applications use a naming convention known as NetBIOS. In general, NetBIOS computer names consist of a single part.

In contrast, TCP/IP components rely on the DNS naming convention. DNS computer names consist of two parts: a computer name and a domain name, which combine to form the fully qualified domain name (FQDN).

NetBIOS computer names can be made compatible with DNS computer names, making interoperation possible between the two. Windows NT combines the NetBIOS computer name with the DNS domain name to form the FQDN.

Note

Under Windows NT Server, the DNS host name defaults to the same name as the NetBIOS computer name. You can change this if you need separate names.


The Decision to Use WINS

As with dynamic addressing of computers, dynamic name registration and resolution of computers and associated addresses will reduce administrative costs at Terra Flora. If administrative tasks can automatically be performed by the computers running Windows NT Server with WINS enabled, administrators are free to perform other network administrative tasks.

A WINS server maintains a dynamic database that maps the NetBIOS computer names of WINS clients to their IP addresses. Both a computer name and IP address are necessary for network clients to communicate effectively on the enterprise network. At Terra Flora, clients are configured as both DHCP- and WINS-enabled.

The primary purpose of WINS is to respond to network clients that are trying to locate a computer on the network by using its' NetBIOS name. The WINS server responds to the network client with the IP address of the desired computer, thus enabling the client computer to connect to the desired computer via a TCP/IP session. To enable this functionality, the WINS clients register their NetBIOS names with the WINS server. The registered name is stored in a database on the server on a dynamic basis so the name can be reused later if the client stops using it.

A WINS client is responsible for maintaining the lease on its registered name and informing the WINS server periodically that it is still present on the network. When it shuts down, it also notifies the WINS server that the name is being released.

Terra Flora administrators decided to use WINS for the following reasons:

  • Dynamic database maintenance will support computer name registration and name resolution. WINS provides dynamic name services, and it offers a NetBIOS name space, making it much more flexible than DNS for name resolution. The WINS and DNS servers will be integrated to serve all name resolution needs at Terra Flora.
  • WINS centralizes management of the computer-name database and the database replication policies, which will alleviate the need for managing LMHOSTS files.
  • Windows NT Server has been chosen as the integration tool to interoperate the heterogeneous networks at Terra Flora. Implementation of WINS will reduce the IP broadcast traffic while allowing client computers to easily locate remote systems across local or wide area networks.


Installing and Configuring WINS

A WINS server is a computer running Windows NT Server using the Microsoft TCP/IP protocol and the WINS server software. WINS servers maintain a database that maps computer names to IP addresses, allowing users to easily communicate with other computers while gaining all of the benefits of using TCP/IP.

For a complete discussion of the WINS service, see Chapter 8, "Managing Microsoft WINS Servers."

Installing WINS Servers

Installing a WINS server is part of the process of installing Microsoft TCP/IP in Windows NT Server. The following instructions assume you have already installed the Windows NT Server operating system on the computer.

You must be logged on as a member of the Administrators group to install WINS.

To install a WINS server

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Click Server, and then click Add.

5. In the Select Network Service dialog box, click Windows Internet Name Service.

6. Click Have Disk if you are loading the software from disks or a CD-ROM.

Or, click OK if loading from the network.

7. In the Windows NT Setup dialog box, type the full path to the Windows NT Server WINS files, and then click Continue.

You must shut down and restart the computer before the new settings will take effect. The WINS Manager then appears on the Administrative Tools (Common) menu on the desktop.

Managing WINS Servers

The addition of the WINS service places the WINS Manager on the Administrative Tools (Common) menu. Once the installation is complete on the computer running Windows NT Server, use WINS Manager to complete the configuration of WINS.

To start WINS Manager

  • Click Start, point to Programs, point to Administrative Tools (Common), and click WINS Manager.

Adding WINS Servers

Before you can administer and manage WINS servers, you must add the WINS servers to the Server List using the WINS Manager graphical interface. At Terra Flora, all computers running Windows NT Server WINS service will be added to the WINS Server List. Until the WINS servers are added to the list, no WINS features are available. Once the servers are added to the list, administration of any computer running Windows NT Server WINS Service can take place from any other computer running Windows NT Server WINS Manager.

To Add a WINS server to the Server List

1. On the WINS Manager Server menu, click Add.

The Add WINS Server to Server List dialog box appears.

2. In WINS Server, type the IP address of the DHCP server to be added to the list, and then click OK.

Once a WINS Server is added to the list, configuration of the server can take place.

Configuring WINS Servers

Terra Flora will configure multiple WINS servers to increase the availability and balance the load among servers. To configure a WINS server, you must be a member of the administrators group of that server.

To configure a WINS server

1. In WINS Manager, click the server you want to configure.

2. On the Server menu, click Configuration.

The WINS Server Configuration dialog box appears.

3. Select the configuration options you want.

  • To specify how often a WINS client will renew its name registration with the WINS Server, type a value in Renewal Interval.
  • To specify the interval between when an entry in the WINS database is marked as released (no longer registered) and when it is marked as extinct, type a value in Extinction Interval.
  • To specify the interval between when an entry is marked extinct and when the entry is scavenged (removed) from the WINS database, type a value in Extinction Timeout.
  • To specify when the WINS server will verify that old names it does not own (those replicated from other WINS servers) are still active, type a value in Verify Interval.
  • To specify pull parameters, select the Initial Replication check box under Pull.
  • To specify the number of times that the WINS server will attempt to contact a replication partner for pulling new WINS database entries, type a value in Retry Count.
  • To have the WINS server notify its replication partners of the status of its WINS database when the system is initialized, select the Initial Replication check box under Push Parameters.
  • To notify the replication partners of the WINS server when a name registration changes the WINS database status, select the Replicate on Address Change check box.

4. Click Advanced to configure other options.

  • To specify logging of database changes to Jet.log, select the Logging Enabled check box.
  • To log events in detail, select the Log Detailed Events check box.
  • To replicate only WINS push or pull partners, select the Replicate Only With Partners check box.
  • To automatically back up the database when WINS Manager stops, select the Backup On Termination check box.

The database backup path must have a directory specified.

  • To treat static unique and static multihomed records in the database as dynamic when they conflict with a new registration or replica, select the Migrate On/Off check box.

This means that if they are no longer valid, they will be overwritten by the new registration or replica. By default, this option is not checked.

  • To set the highest version ID number for the database, enter that number in Starting Version Count.
  • To specify the directory where the WINS database backups will be stored, type the path in Database Backup Path.

5. When you have completed all changes in the WINS Server Configuration dialog box, click OK.

Notes

  • Specify the %systemroot%\system32\wins directory. A subdirectory for the backup will be added to WINS directory.
  • Logging events in detail requires considerable system resources and should be turned off if you are tuning for performance.
  • If the Replicate Only With Partners check box is not selected, an administrator can ask a WINS server to pull or push from or to a non-listed WINS server partner. By default, this option is checked.
  • Usually, you will not need to change the value in Starting Version Count unless the database becomes corrupted and needs to start fresh. In such a case, set this value to a number higher than appears as the version number counter for this WINS server on all the remote partners that earlier replicated the local WINS server's records. WINS may adjust the value you specify to a higher one to ensure that database records are quickly replicated to other WINS servers.
  • If you specify a backup path, WINS automatically performs a full backup of its database to this directory every 24 hours. WINS uses this directory to perform an automatic restoration of the database in the event that the database is found to be corrupted when WINS is started. Do not specify a network directory.

Configuring Replication Partners

All of the WINS servers on a network can be configured to communicate with each other so that a name registered with one WINS server will eventually be known by all WINS servers. In addition to registration of all names on the network with all WINS servers, all WINS servers will eventually be notified when a name is released. Replication is carried out among replication partners, rather than by each server replicating to all other servers. Each WINS server must be configured with at least one other WINS server as its replication partner.

In Terra Flora's main California Domain, one WINS server will be designated as the central server, and all other WINS servers will be configured as both push and pull partners of this central server. A pull partner is a WINS server that pulls in replications of database entries from its partner by requesting and then accepting the replications. A push partner is a WINS server that sends update notification messages to its partner when its WINS database has changed. This configuration ensures that the WINS database on each server contains names addresses for every network computer.

The Terra Flora network diagram of the California domain shows only two of the WINS servers. At Terra Flora, WINS will be enabled on several computers running Windows NT at the Enterprise level. All of these computers running Windows NT Server WINS server will be configured as push and pull partners of each other.

The PDC will act as the central server. It will push changes made to its database to the next server in the line, which then pulls the changes from the PDC. This will continue down the line, with the server last on the line pushing back to the central server, which will pull in changes from the last server on the line. This ensures that all the databases on all WINS servers are replicated and up-to-date.

Additionally, the administrator can perform a replication immediately or at a specified time.

To add a replication partner to a WINS server

1. On the WINS Manager Server menu, click Replication Partners.

The Replication Partners dialog box appears, showing all replication partners of the WINS server.

2. Click Add.

3. Type the IP address of the WINS server that is to be added as a push or pull partner.

The added server can be configured as either a push or pull partner to the WINS server. The replication partner will automatically be added as both a push and pull partner of the server that is being configured. This can be changed.

To configure replication partners for a WINS server

1. In WINS Server in the Replication Partners dialog box, click the server you want to configure.

2. Under Replication Options, select the Push Partner check box, the Pull Partner check box, or both, to indicate the appropriate replication partnership.

3. Under Replication Options, select the Configure check box for each of the appropriate settings.

The Push Partners Properties or Pull Partners Properties dialog box appears.

To define pull partner properties

1. In Start Time on the Pull Partner Properties dialog box, type a number to indicate when replication should begin, using any separator (such as AM or PM) for hours, minutes, and seconds.

2. In Replication Interval, type a time in hours, minutes, and seconds to indicate how often replications will occur.

Or, to use values specified in the Preferences dialog box, click Set Default Values.

3. Click OK.

The AM and PM designators are part of your time setting in International (in Control Panel).

To define push partner properties

1. In Update Count on the Push Partner Properties dialog box, type the number of additions and updates that can be made to records in the database before replication must take place.

The minimum value is 20; replications that have been pulled in from partners do not count as insertions or updates in this context.

2. Click OK.

If you decide later to reset the values specified in the Preferences dialog box, you can reopen the Push Partner Properties dialog box and click Set Default Values.

Triggering Replication Between Partners

You can also immediately replicate the database between the partners, rather than waiting for the start time or replication interval specified in the Preferences dialog box. For details, see "Setting Preferences for WINS Manager" later in this chapter.

You probably want replication to begin immediately after you make a series of changes, such as entering a range of static address mappings.

To trigger replication

1. On the Server menu of WINS Manager, click Replication Partners.

2. Click the WINS servers to which you want to send a replication trigger.

Or, if you want the selected WINS server to propagate the trigger to all its pull partners, select the Push With Propagation check box.

3. Under Send Replication Trigger Now, click Push or Pull, depending on which partners you want to trigger.

If Push With Propagation is not selected, the selected WINS server does not send the trigger to its other partners.

If Push With Propagation is selected, the selected WINS server sends a propagate push trigger to its pull partners after it has pulled in the latest information from the source WINS server. If it does not need to pull in any replicas because it has the same or more up-to-date replicas than the source WINS server, it does not propagate the trigger to its pull partners.

To start replication immediately

  • In the Replication Partners dialog box, click Replicate Now.

Adding Static Mappings

Static mappings are permanent lists of computer name-to-IP address mappings. In the table, the administrator indicates the computer name and matches the IP address the computer. When a network client sends a name request to the WINS server, the WINS server will always respond with the name entered by the administrator. At Terra Flora, all DNS servers, DHCP servers and other WINS servers will be statically added to all WINS servers.

Note

If DHCP is also used on the network, a reserved (or static) IP address will override any WINS server settings. Static mappings should not be assigned to WINS-enabled client computers.

You can add static mappings to the WINS database for specific IP addresses using two methods:

  • Typing static mappings in a dialog box.
  • Importing files that contain static mappings.

To type static mappings in a dialog box

1. On the Mappings menu, click Static Mappings.

2. Click Add Mappings.

3. In Name, type the computer name of the system for which you are adding a static mapping.

WINS Manager automatically adds the two backslashes (\\), which normally proceed the entry of a computer name.

4. In IP Address, type the address for the computer.

5. In Type, click to indicate whether this entry is a unique name or a group with a special name, and then click Add.

The mapping entry is immediately added to the database, and the check boxes are cleared so that you can add another static mapping entry.

The settings available under Type include the following:

  • Unique is a unique name in the WINS database that permits only one address per name. The unique name is the WINS client's computer name.
  • Group indicates a normal group for which the IP addresses of the individual clients are not stored. A normal group is the name to which broadcasts are sent and is the domain name used for browsing purposes. A normal group name has Ox1E as its 16th byte, which appears as a [1Eh] at the end of the name in Mappings, View Database option in WINS Manager. A normal group name does not have an IP address associated with it and can be valid on multiple networks and registered with multiple WINS Servers. When a WINS server receives a request for the group name, the WINS server returns the limited broadcast address 255.255.255.255, which the WINS client will then use to broadcast to the network. For a description of the 16th byte fields, see Appendix G, "NetBIOS Names."
  • Internet Group is a group that contains the IP addresses for up to 25 primary and backup domain controllers for the domain. An Internet group has a 0X1C as its 16th byte, which appears as a [1Ch] at the end of the name in Mappings, View Database option in WINS Manager. The Internet group name is another instance of the domain name being registered; however, this instance is used for the domain controllers in the domain to communicate with each other.
  • Multihomed is similar to a unique name in that it is the WINS client's computer name; however, it can have up to 25 addresses and is for use by multihomed systems. A multihomed system is a system with more than one network interface and more than one IP address.

If Internet Group or Multihomed is selected under Type, the dialog box shows additional controls for adding multiple addresses. Click the down arrow (button) to move the address you type into the list of addresses for the group. Use the up-arrow button to change the order of a selected address in the list.

Entries for static mappings of unique and special group names can be imported from any file with the same format as the LMHOSTS file, which is described in Chapter 10 "Using LMHOSTS Files." Scope names and keywords other than #DOM are ignored. Static Mapping for normal group and multihomed names can be added only by typing entries in the Add Static Mappings dialog box.

Note

For Internet group names defined in this dialog box (that is, added statically), make sure that the primary domain controller (PDC) for that domain is defined in the group if the PDC is running Windows NT Advanced Server version 3.1.

To import a file containing static mapping entries

1. In the Static Mappings dialog box, click Import Mappings.

2. In the Select Static Mapping File dialog box, enter the name of the file containing the names to be mapped.

The specified file is read, and then a static mapping is created for each computer name and address. If the #DOM keyword is included for any record, an Internet group is created (if it is not already present), and the address is added to that group.

For more information on managing Static Mappings, see Chapter 8, "Managing Microsoft WINS Servers."

Setting Preferences for WINS Manager

Several options can be configured to administer WINS servers. The control preferences are on the Options menu.

To set preferences for WINS Manager

  1. On the Options menu, click Preferences.

  1. In the Preferences dialog box, specify the settings you want to change.
    • To indicate how you want address information to be displayed throughout WINS Manager, click Computer Name Only, IP Address Only, or one of the ordered combinations: Computer Name (IP Address) or IP Address (Computer Name.)
    • To automatically refresh the statistics in the WINS Manager window, select the Auto Refresh check box under Server Statistics, and then enter a number in Interval (seconds) to specify the time between refresh actions.
    • To have computer names to adhere to the LAN Manager naming convention, select the LAN Manager-Compatible check box.

      This check box should be selected unless your network accepts NetBIOS name from other sources.

    • To have the system query the listed servers each time the system starts to find out if each server is available, select the Validate Cache Of "Known" WINS Servers At Startup Time check box.
    • To have a warning message appear each time you delete a static mapping or the cached name of a WINS server, select the Confirm Deletion Of Static Mappings And Cached WINS Servers check box.
    • To specify the default for replication start time for new pull partners, type a time in Start Time, and then specify values in Replication Interval to indicate how often data replicas will be exchanged between the partners.
    • To specify the default number of local registrations and changes that can occur before this server (as a push partner) sends a replication trigger, enter a number in Update Count under New Push Partner Default Configuration.

      The minimum value is 20.

  2. Click OK.

WINS Manager also automatically refreshes the statistical display each time an action is initiated while you are working in WINS Manager.

LAN Manager computer names are limited to 15 characters, as compared to the 16-character NetBIOS names used by some other sources, such as Lotus Notes. In LAN Manager names, the 16th byte is used to indicate whether the device is a server, workstation, messenger, and so on. When this option is selected, WINS adds and imports static mappings with 0, 0x03, and 0x20 as the 16th byte.

All Windows – based networking, including Windows NT, follows the LAN Manager convention.

The replication interval should be equal to or less than the lowest refresh time interval that is set on any of the replicating WINS servers. The minimum value for the replication interval is 40 minutes.


The Decision to Integrate DNS with WINS

DNS is not dynamic, which means that administrative overhead is increased in a network like Terra Flora with the use of DNS. Administrators must update DNS computer files whenever a computer moves or a new computer is added to the network.

WINS was created to ease this type of administrative burden. Coupling DNS with WINS capitalizes on the strengths of each to provide a form of dynamic DNS. Windows NT 4.0 Server DNS Service provides a WINS lookup feature. If the name cannot be resolved using DNS, the name request is forwarded to WINS for resolution. It is this form of an integrated, dynamic, name-resolution feature that contributed to the decision at Terra Flora to migrate most of their DNS information and application to computers running Windows NT Server with the DNS service enabled. Terra Flora will use both DNS and WINS to resolve names.

It is clear to the CIO that the WINS Lookup feature provided as part of the Windows NT Server DNS service would help cut administrative costs by eliminating some of the manual name and address tracking administrative tasks associated with the current network DNS systems.

A key feature of the DNS service in Windows NT Server 4.0 is a graphical interface from which the database files can be managed. Use of this graphical tool should eliminate some of the error associated with making changes directly to a zone database file using an file editor.

Note

This form of dynamic name resolution is only available on networks with computers running Windows NT Server with DNS and WINS enabled.

For a complete discussion of DNS and WINS integration, see Chapter 3, "Implementation Considerations" in the Microsoft Windows NT Server 4.0 Networking Supplement.

Implementation Plan for DNS

DNS is in use on many of the heterogeneous networks at Terra Flora. The plan to implement Windows NT Server DNS service was quite involved due to the fact that DNS is running without problems on the majority of the small, heterogeneous networks. However, the benefit of reduced administrative cost, combined with an integrated solution for the heterogeneous network was a compelling benefit to use Windows NT Server WINS and DNS services.

Before the merger of the heterogeneous networks, Terra Flora had four DNS zones. Terraflora.com was registered with Internet Network Information Center and operated as the authoritative domain. Three other zones were created on DNS servers, one for each of the company divisions, which were Nursery. Terraflora.com; Retail. Terraflora.com, and Supply.Terraflora.com.

The plan at Terra Flora includes replacing two of the three division's DNS systems with computers running Windows NT Server 4.0 DNS service. These two division are Supply.Terraflora.com and Nursery. Terraflora.com

The Sun server in the Retail Services division \\CASWN25ENT01 currently runs the key mission critical corporate application systems of Terra Flora. The plan for the current DNS system in the Retail. Terraflora.com zone is to incorporate a server running Windows NT Server 4.0 DNS service as a secondary server and track the performance of the server.

Then the Retail.Terraflora.com zone will be split. The new zone will be called NT.Retail.Terraflora.com and will consist of only computers running Windows NT Server 4.0 DNS service and no other DNS service. The servers will also be running WINS and DHCP and have the WINS Lookup feature enabled. The plan will be to eventually migrate all of the DNS functionality in the Retail Services division to Windows NT Server 4.0.

Note

Domain: There are several meanings associated with Domain. In the DNS world a domain is the name and address of every machine associated with a group. Windows NT Server domains are defined as the logical grouping of network servers and other computers that share a common security and user account information. For this discussion, domains will be divided into two terms: DNS Domains and Windows NT Server Domains.

Replacing the Nursery and Supply Divisions DNS Systems

The plan at Terra Flora is to replace the DNS servers storing the zone information and files of Nursery.Terraflora.com and Supply.Terraflora.com with the Windows NT Server DNS service. To do this, the following steps must be performed:

  • Windows NT Server 4.0 DNS service will be installed on primary and secondary servers running Windows NT Server DNS service in each zone. The graphical DNS manager tool is available on the Administrative Tools menu as a result of the installation of Windows NT 4.0 DNS Service.
  • All the servers running Windows NT Server 4.0 with the DNS service enabled will be added to the server list using the graphical interface tool called DNS Manager. In this way, Terra Flora can administer all the computers running Windows NT Server 4.0 DNS service from any computer running Windows NT Server DNS service by using the DNS Manager graphical interface.
  • The zone, boot and cache files for Nursery.Terraflora.com and Supply.Terraflora.com will be moved to the appropriate computer running Windows NT Server 4.0 with the DNS service enabled. The boot file will be changed to indicate the new information such as names and IP addresses of the zones.
  • The database resource records will be changed to reflect these changes such as where zone files are located, the location of primary and secondary databases and static information about other DNS servers that are not running the Windows NT Server 4.0 DNS service.
  • The static resource records of the servers which are not Windows NT Server 4.0 DNS servers will be added or updated as necessary to ensure that all DNS servers are checked for name resolution.
  • The servers running Windows NT Server 4.0 DNS service will be enabled to participate in WINS Lookup.
Integrating the Retail DNS System with Windows NT Server DNS Service

For Retail.Terraflora.com, the plan is different. A server running Windows NT Server 4.0 DNS Service will be added as a secondary server to the existing DNS Zone which is installed on a computer not running Windows NT Server. The performance of Windows NT will be measured.

A key feature of the Windows NT Server 4.0 DNS is the WINS Lookup feature. The Retail.Terraflora.com zone will be split. A new subzone called NT.RetaiI.Terraflora.com will be set up on computers running Windows NT Server DNS service. The servers in the new subzone will be WINS lookup enabled. Migration to the servers running Windows NT Server DNS service will take place over the next several months. As applications requiring DNS services are changed, the DNS services will be moved to the servers running Windows NT Server 4.0 DNS. The following steps will be followed:

  • Windows NT Server 4.0 DNS Service will be installed on all servers in the new split zone which will be created as NT.Retail.Terraflora.com.
  • Using the graphical tool, all the Windows NT Server 4.0 DNS servers will be added to the Windows NT Server 4.0 DNS system, allowing administration from any server running Windows NT Server 4.0 DNS service.
  • The new NT.Retail.Terraflora.com subzone will be configured as a primary and secondary zone. The secondary zone is a replicated copy of the primary subzone database.
  • NS and A resource records will be added to the NT.Retail.Terraflora.com Windows NT Server 4.0 DNS database pointing to the Terraflora.com Windows NT Server 4.0 DNS database for name resolution.
  • NS records will be added to the Terraflora.com Windows NT Server 4.0 DNS database pointing to the NT.Retail.Terraflora.com Windows NT Server 4.0 DNS database for name resolution.
  • Static NS and A records will be added to the zone file for NT.Retail.Terraflora.com for all DNS servers that are running an operating system other than Windows NT Server 4.0 and for all workstations that are not Windows NT, Windows 95, Windows for Workgroups, and LanMan 2.x.
  • All Windows NT Server 4.0 DNS servers will be WINS enabled.


Installing DNS Service

DNS is one of the Windows NT Server services. The instructions below assume you have already installed the Windows NT Server operating system. Terra Flora will install the DNS service on all computers running Windows NT Server service that will provide DNS services.

To install the DNS service

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Click Server, and then click Add.

5. In the Network Services dialog box, click Microsoft DNS Server, and then click Have Disk if loading the software from disks or a CD.

Or, select OK if loading from the network.

6. In the Windows NT Setup dialog box, type the full path to the Windows NT Server DNS files, and then click OK.

7. In the Network Settings Change dialog box, click Yes to restart the computer and complete the DNS installation.

Note You must be logged on as a member of the Administrators group to install a DNS server.


Managing DNS Servers

Once a Windows NT Server DNS server is installed, DNS Manager is added to the Administrative Menu. Using DNS Manager, the administrator can add servers running Windows NT Server 4.0 DNS service to the server list. Once added, the administrator can view and change parameters of any of the Windows NT Server 4.0 DNS servers in the list.

To open the DNS Manager

· Click Start, point to Programs, point to Administrative Tools, and click DNS Manager.

The Domain Name Service Manager window appears.

Add All Windows NT DNS Servers to the Server List

All of the servers running Windows NT Server 4.0 DNS service on the network can be administered and managed from any single computer running Windows NT Server DNS service, through the DNS Manager interface. To do this, the administrators at Terra Flora will add the servers to the server list using the DNS Manager interface. DNS features will not be available on any of the computers running Windows NT until the server is added to the server list.

To add a DNS server

  1. In Domain Name Service Manager, click Server List.
  2. On the DNS menu, click New Server.

The Add DNS Server dialog box appears.

  1. In DNS Server, type the IP address of the DNS server to be added to the server list, and then click OK.

The server appears in the server list in Domain Name Service Manager.

Copy the Files

Three of the four existing zones will be moved to servers running Windows NT Server 4.0 DNS service.

The administers at Terra Flora will remove the appropriate zone, boot and cache files from the system servers which currently store the zones of Terraflora.com, Nursery.Terraflora.com and Supply.Terraflora.com. The files will then be placed in the SystemRoot\System32\DNS directory of the proper new server running Windows NT Server 4.0 DNS service which will, from that point forward, store the zone information.

The Terra Flora administrator will use the editor that they are familiar with to change the information about the zones in the boot file as appropriate.

Once the files are in the proper directory, the zone's structure can be viewed using the DNS Manager graphical interface. The administrators will be able to view the structure of the Nursery.Terraflora.Com and Supply.Terraflora.Com and Terraflora.Com zones.

Creating the New Zone

A zone is the administrative tool for information about the DNS domains. At Terra Flora, Terraflora.Com is the main authoritative DNS domain and the root zone. Three additional zones called Nursery.Terraflora.Com, Supply.Terraflora.Com and Retail.Terraflora.Com exist at Terra Flora. At Terra Flora, three of the zones have been moved to computers running Windows NT DNS Service. See the previous section "Copy the Files" for details.

Because of the mission critical nature of the applications in the retail division, the Retail.Terraflora.Com zone will be maintained. A fifth zone will be created to split the Retail.Terraflora.Com zone. This fifth zone will include only servers running Windows NT Server 4.0 DNS server. The zone will be set up as both primary and secondary in order for replication of the resource record database to take place. Two servers will store the zone information, one will store the primary zone information and one will store the secondary zone information.

To add the primary NT.Retail.Terraflora.Com zone

1. In Domain Name Service Manager, click the server for which you will be creating the zone.

2. On the DNS menu, click New Zone.

The Create new zone for IP address of the server selected dialog box appears.

3. Click Primary.

4. Click Next.

5. In Zone Name, type the name of the root domain within the zone.

6. If necessary, type the name of the database file in which you want the DNS resource records to be stored in Zone File.

7. Click Next.

8. Click Finish.

An SOA (Start of Authority) record is created in the database file entered in step 7. The SOA record indicates the Name Server which is the best source of information for supplying name resolution data.

NT.Retail.Terraflora.Com will also be set up as a secondary zone and the server assigned will be different than the one assigned for the Primary zone. If the server that stores the primary zone goes down, the server storing the secondary zone will be used for name resolution.

Selecting Primary as a zone type indicates that the zone does not obtain it's resource records from any other zone, the DNS Administrators are required to add, delete and modify all necessary resource records to the primary zone files.

The root domain is a DNS domain with multiple sections, each with a maximum of 63 characters and separated by a period (.). The zone name must be unique. The zone name will be NT.Retail.Terraflora.Com.

The default name of the Zone File will be the same name as entered in the Zone Name field.

To add the secondary NT.Retail.Terraflora.Com zone

1. In Domain Name Service Manager, click the server for which you will be creating the secondary zone.

2. On the DNS menu, click New Zone.

The Create new zone for IP address of the server selected dialog box appears.

3. Click Secondary as the Zone Type.

4. In Zone, type the name of the zone.

5. In Server, type the name of the server on which the primary zone information is stored, and then click Next.

The secondary zone name appears in Zone Name.

6. In Zone File, type the name of the secondary database file you want the DNS resource records to be stored in, and then click Next.

7. Click Add, and enter the IP address of the IP Master, which is the server on which the primary zone information is stored.

8. Click Next.

9. When a message appears, confirming that all the information for the new zone has been entered, click Finish.

Selecting Secondary as the zone type indicates that the zone obtains its resource records from the primary zone. This means that the DNS Administrators are required to add, delete, and modify all resource records in the primary zone and not this secondary zone.

At Terra Flora, the zone name will be NT.Retail.Terraflora.Com, matching the primary name. The name should always be the primary zone name. When the secondary server starts, a query will be sent to the server specified as the IP Master for the zone file with the same primary name.

The default name in Zone File will be the name you entered in Zone Name.

Each secondary zone must have at least one IP master. You can add more than one IP master and move them in the list using the Move Up and Move Down buttons.

Adding and Changing Database Resource Records

During the process of creating the new NT.Retail.Terraflora.Com zone, Terra Flora specified the database file name and database server which would store the zone's database information. Resource records need to be added to the zone's database file that will indicate how computer names will be resolved.

Terra Flora has configured the DNS system so that when a client requests an IP address from the DNS server, the server on which the zone file for Terraflora.Com resides is examined first. If the name cannot be resolved within the Terraflora.Com file, the request is then forwarded to the servers on which the zone files for Retail.Terraflora.Com, Nursery.Terraflora.Com, and Supply.Terraflora.Com reside.

The resource records implementing this lookup already exist in all zones, except for the new NT.Retail.Terraflora.Com zone which was just created. New resource records must be put in the two zones Terraflora.Com and NT.Retail.Terraflora.Com.

Additionally, the resource records that exist in Nursery.Terraflora.Com and Supply.Terraflora.Com must be changed to reflect the information about the new server that now stores the zone files for Nursery.Terraflora.Com and Supply.Terraflora.Com.

The resource records that will be added to or changed for each of the zones are described below:

  • Terraflora.Com

An A (Address) record will be added supplying the host name and host address of NT.Retail.Terraflora.Com, which will indicate to other DNS servers and to the primary server storing the Terraflora.Com zone database file to search the NT.Retail.Terraflora.Com zone database file to resolve the clients name requests.

An NS (Name Server) record will be added supplying the DNS Name Server name for the NT.Retail.Terraflora.Com zone, which will indicate to other DNS servers and to the server storing the Terraflora.Com zone database file to search the zone database file of NT.Retail.Terraflora.Com to resolve the request.

The NS (Name Server) records will be changed to indicate the new DNS Name Server information for the Nursery.Terraflora.Com and Supply.Terraflora.Com zones.

Other records can be added as necessary by the Terra Flora administrators, but these records are key in resolving name requests.

  • NT.Retail.Terraflora.Com

An A (Address) record will be added supplying the host name and host address of NT.Retail.Terraflora.Com to indicate to other DNS servers that the information stored in the NT.Retail.Terraflora.Com database should be examined for name resolution.

An NS (Name Server) record will be added supplying the DNS Name Server name for the NT.Retail.Terraflora.Com zone to indicate to other DNS servers that the information stored in the NT.Retail.Terraflora.Com database should be examined for name resolution.

  • Supply.Terraflora.Com and Nursery.Terraflora.Com

The NS (Name Server) records will be changed supplying the new DNS Name Server name for the Supply.Terraflora.Com and Nursery.Terraflora.Com zone to indicate to other DNS servers that the information stored in the two zones should be examined for name resolution.

Other records can be added as necessary by the Terra Flora administrators, but these records are key in the continued use of DNS at Terra Flora.

To add a database resource record

1. In Domain Name Service Manager, click the zone for which you will be creating the new record.

2. On the DNS menu, click New Record.

The New Resource Record dialog box appears.

In Record Type, click the record you want to add.

The dialog box changes, depending on which type of record you selected. For example, the For Domain name that is the zone name appears when you specify an NS record.

4. Under Value, type the necessary information, such as the Name Server DNS Name for NS records, which specifies the server name that will be used to resolve name requests.

5. Click OK.

To change a database resource record

1. In Domain Name Service Manager, click the server that stores the zone with which you want to work.

2. Click the zone that contains the record you want to change.

3. In Record for zone name, click the record type you want to change.

4. Double-click the record to be changed.

The dialog box changes, according to the kind of information required. For example, the Terra Flora administrator would type the name of the server which will now store the zone information for Nursery.Terraflora.Com in Name Server DNS Name.

5. To change another database resource record, repeat these steps.

For example, at Terra Flora, the administrator would repeat this procedure for Supply.Terraflora.Com.

6. When finished making changes, click OK.

At Terra Flora, the database resource records will need to be reviewed and changed as necessary.

In the case of Terraflora.Com, the administrator will be changing the NS record for Nursery.Terraflora.Com and Supply.Terraflora.Com. Consequently, the administer would complete the procedure for one record to step 5 and then repeat the procedure for the other record.

Static DNS Server Resource Records

At Terra Flora, there are DNS Servers that are not running Windows NT Server 4.0 in the Retail.Terraflora.Com zone that will be added to the zone files residing on the servers running Windows NT Server 4.0 DNS service. The static entry of the DNS servers ensures that all DNS servers will be searched in an attempt to map name and IP addresses. An A (Address) and NS (Name Server) resource record will be added to each zone for each DNS server that is to participate in name resolution.

WINS Lookup

When a server running Windows NT Server 4.0 DNS Service receives a DNS request to resolve a specified DNS name to an IP address, it will search its A (Address) resource records until it finds one whose DNS name matches the one specified in the request. It then returns the IP address stored in that A (Address) resource record to the requesting computer.

If the server cannot locate an A (Address) resource record for the requested DNS name, and if Use Wins Resolution is enabled, the DNS server will extract the host name, which is the text of the name, on the left hand side of the name, up to the first period, and send a request to a the specified WINS server asking it to map the host to an IP address. If the name was registered with WINS, WINS will return the associated IP address to the DNS server and the DNS server will return it in response to the original DNS request.

Any number of WINS servers can be specified for fault tolerance purposes. The server running Windows NT Server DNS service will try to locate the name by searching the WINS servers in the order listed.

To enable WINS Lookup

1. In Domain Name Service Manager, click the zone for which you will be enabling WINS Lookup.

2. On the DNS menu, click Properties.

3. In the Zone Properties dialog box, click the WINS Lookup tab.

4. Select the Use WINS Resolution check box.

5. Under WINS Servers, type the WINS Server IP address that will be used for resolution.

6. Click Add.

You can repeat the procedure to add as many WINS servers for resolution as needed.


Integrating DHCP, WINS, and DNS in Heterogeneous Networks

Terra Flora has a difficult mix of disparate network operating systems, supporting multiple protocols, and different services with various administration tools. Most of them can support the TCP/IP protocol, and many of them can be dynamically configured with their IP address via the Dynamic Host Configuration Protocol, or DHCP.

However, there are legacy UNIX servers, and other network devices that use static IP addresses, and use the Domain Name Space (DNS) services to provide hostname-to-IP-address resolution. Therefore, they need to have a DNS servers in the environment as well.

The long range goals at Terra are to be able to handle an expanding network, and reduce costs. In addition, the types of network clients are changing, with portable and fully mobile networking requirements that break the previous networking models, and exceed the capabilities of the existing administrative mechanisms.

With that understanding, it becomes clear that Terra Flora needs to deploy DHCP services in their network environment to address the dynamic nature of the network clients and reduce the administrative costs of assigning and updating the host table information on the DNS servers. As DHCP only provides the dynamic IP address leasing, WINS services must also be deployed to provide the name resolution for these dynamic network clients. However, due to the presence and limitations of the existing legacy systems in the network, Terra Flora must continue to support DNS as well.

In order to meet the objectives, Terra Flora will deploy DHCP, WINS, and DNS services in their network environment. However, this does not mean that these technologies are islands unto themselves, where clients or servers using DNS can only access machines in the traditional DNS host tables, or where DHCP and WINS clients can only access computers similarly configured.

Windows NT Server 4.0 includes integrated name resolution server components, which allows both DNS and WINS-based clients to resolve names from both types of clients, while minimizing the impact on the existing network infrastructure.

Using Windows NT Server 4.0 and integrating WINS, DNS and DHCP, the process of name and IP resolution becomes basically dynamic. A computer running Windows NT 4.0 will have a NetBIOS name. If a Windows NT, Windows 95 or Windows for Workgroups client sends a request for the IP Address location of a computer AshleyJ.Terraflora.com, and both computers are DHCP, WINS and DNS configured, the process of mapping the IP Address to the NetBIOS computer name of Ashleyj is as follows:

  • A DHCP, WINS and DNS client computer requests the IP address of the NetBIOS named computer Ashleyj.
  • The computer Ashleyj receives an IP address when it first starts up from DHCP.
  • The IP address is registered with the WINS server, mapping the name Ashleyj to the IP address.
  • The DNS server is able to resolve the Terraflora.Com portion of the name as a zone known to the WINS server.
  • In configuring the Windows NT Server 4.0 DNS server, WINS servers were specified and associated to the zones. The NetBIOS portion of the name, which is the text up to the first period '.', will be sent by the server running Windows NT Server 4.0 DNS Service to the specified WINS servers.
  • The WINS servers will be examined for the friendly name Ashleyj and the IP address. This information is sent back to the server running Windows NT Server 4.0 DNS service and then forwarded to the original requesting computer.


Network Logon Services

At Terra Flora, the logon services provided by the Windows NT operating system were selected to provide centralized network logon. This decision was made because Windows NT Server is the only product that provides the capability to log onto all the heterogeneous networks at Terra Flora. The Windows NT Server product provides users with the capability to sign onto all appropriate network resources using a single user account and password.

Note

Password synchronization between network operating system platforms is not automatic for all platforms, but is a future technology for Windows NT Server (ODSI).


The Decision to Centralize Logon Services

Modern network server operating systems track user accounts in a secure and replicated database called a directory. The operating system services that facilitate the use of this database are called Directory Services. A domain is the administrative unit of Windows NT Server Directory Services. Within a domain, an administrator creates one user account for each user which includes user information, group memberships and security policy information.

Refer to the Terra Flora network diagram. At Terra Flora, three domains have been set up. They are the California Domain, the North East Domain and the Europe Domain.

Within each domain, domain controllers manage all aspects of user-domain interactions. Domain computers are computers running Windows NT Server that share one directory database to store security and user account information for the entire domain. Domain controllers use the information in the directory database to authenticate users logging on to domain accounts. Trust relationships are then set up between the domains to allow users in one domain to logon automatically to another domain. For details on how to manage the user work environment and domains, see Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User Group Accounts" and Chapter 3, "Managing User Work Environments."

Currently, each of the heterogeneous networks in Terra Flora has its own security system through which the user signs onto the system and is authenticated to use the resources for which permissions are granted. One of the major complaints of network users is that they have to use multiple user accounts and passwords to sign onto different networks. Additionally, because there was no communications between networks, the users are required to log off one network to log onto another network.

At Terra Flora, the following steps have already been completed:

  • PDC and BDCs for each Windows NT administrative domain have been properly configured. For details, see Start Here Installation and Basics Microsoft Windows NT Server, Version 4.0 and Microsoft Windows NT Server Concepts and Planning.
  • The networks have been physically connected.
  • User have been granted proper permissions and network access to all required network resources. For details on how to manage the user work environment and domains, see Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User Group Accounts" and Chapter 3, "Managing User Work Environments."

Following the steps in the remainder of the chapter will provide the user with the ability to logon onto the network from any computer in the network and, if the accounts, passwords and permissions have been granted on all network platforms, will provide access to all the user's required network resources.

For the user, the single network logon will provide transparent, seamless access to the network resources. For example, a NetWare user will logon as usual to the NetWare network and be authenticated to the Windows NT network at the same time. It will just happen and the user will not know that a different network has been accessed. An additional benefit to the user is the ability to sign onto all appropriate network resources from any computer on the network.

For Terra Flora, this consistent interface helps to easily integrate the business processes available through applications stored on servers on different networks, reduces training and reduces support costs as it all appears to the user as the same network system, and reduces the administration costs associated with setting up and maintaining separate logon accounts and passwords on each separate network.

The following sections include information on installing and configuring network logon services to allow authentication of:

  • UNIX Clients to Windows NT Servers
  • Windows NT Clients to UNIX Servers
  • Windows NT Clients to NetWare Servers
  • NetWare Clients to Windows NT Servers
  • Windows NT Clients to Banyan Servers
  • Windows 3.1 Clients to Windows NT Servers
  • MS-DOS Clients to Windows NT Servers
  • Windows for Workgroups Clients to Windows NT Servers
  • Windows 95 Clients to Windows NT Servers
  • Macintosh Clients to Windows NT Servers


UNIX Clients Authenticating to Windows NT Servers

The UNIX operating systems support the Network File System (NFS). Terra Flora's Retail Services division uses as its primary divisional server a Sun server running the Solaris UNIX operating system. User names and passwords for authentication to the UNIX server are stored on the UNIX server, named CASUN25ENT01, (refer to the Terra Flora diagram) on the /etc directory in the Passwd file. At Terra Flora, a third party product by Intergraph called DiskShare will be installed on servers running Windows NT Server to allow UNIX clients access to Windows NT Servers.

Once Intergraph DiskShare is installed and configured, the existing UNIX /etc/Passwd file will be imported to the WINNT\System32\Drivers\Etc directory. Intergraph DiskShare provides a graphical interface through which the administrators can edit the password file. DiskShare provides a way to map UNIX names and passwords to the Windows NT user accounts and passwords so that UNIX users can have the same permissions as the Windows NT users to which they are mapped. Once the mapping is complete, users signing on to the Windows NT network will be simultaneously authenticated to the UNIX network.

Installing Intergraph DiskShare

Documentation is provided with the product. For installation instructions, see the Intergraph DiskShare Quick Start Guide. Additional information is provided in online Help files.

See the documentation accompanying the product for details on the various options provided.

Editing the Password File

The Passwd file is where the UNIX authentication information is stored. Using the graphical interface, administrators can add, change or delete the User Name, the User ID (UID), the user's group ID (GID) and the password.

The first step is for the administrator to copy the Passwd file from the /etc directory on the UNIX server to the WINNT\System32\Drivers\Etc directory on the computer running Windows NT Server. Once the file is in the right directory on the computer Windows NT server, it can be accessed by DiskShare to allow the necessary administration.

To access the Password File Editor

1. Click Start, point to Programs, and click DiskShare Server.

2. On the Server menu, click Password File Editor.

The Password File Editor dialog box appears.

3. In Password File Entries, click the user you want to change or delete.

4. Type the appropriate information for the user name, user UID, user GID, and password in the spaces provided, and then do one of the following:

  • To add the user, click Add.
  • To enter changes for the user, click Change.
  • To delete the user, click Delete.


Mapping UNIX Passwords to Windows NT User Accounts

At Terra Flora, all user accounts, passwords and permissions have been set up on the computers running Windows NT Server. For details see, Microsoft Windows NT Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

Additionally, the UNIX /etc/Passwd file has been copied to the proper Windows NT directory WINNT\System32\Drivers\Etc, which makes it accessible to the graphical interface supplied in Integraph's DiskShare. The entries in the UNIX password file will be mapped or matched to user accounts created in Windows NT domains.

Mapping the UNIX user accounts and passwords to a Windows NT User account grants the UNIX user the same rights and permissions to the Windows NT server as the Windows NT user to whose account the UNIX account is mapped.

Note

If the name and password are exactly the same in the UNIX /etc/Passwd file as that stored in the Windows NT Directory Database, mapping is automatic.

Without mappings, server resource access will default to whatever privileges are given to the Everyone user trying to access the group. See your UNIX documentation for more details on UNIX privileges.

To administer UNIX-to-NT user mappings

1. Open the NFS Administrator.

2. Click Mappings.

In the User Mappings dialog box, the users that are currently mapped are listed in NFS Mapped Users.

3. In Network Users, click the UNIX user to be mapped to the Windows NT user.

4. In NT Users, click the Windows NT user to which you want the UNIX Network user mapped.

5. Click Add.

The mapping appears in NFS Mapped Users.

Additional information that appears in the NFS Administrator window includes:

  • Network Users, which list user names and user IDs (UIDs) in the format: network user name:UID. This information comes from the UNIX-style password file.
  • NT Users, which lists Windows NT user accounts that are local to the domain controller of the specified NT domain.
  • List Names From Domain, which lists all NT domains to which the local machine has access. It includes the local machine name, the primary domain, and any domains that trust the primary domain.

Note

Changes made in this dialog box do not take effect until you click OK, to write the new information to the registry.

Online Help is part of the DiskShare product and explains mapping, such as how to map Windows NT User Groups to UNIX Groups and perform reverse mappings. These sections focus on administrative tasks specific to the Intergraph PC-NFS and DiskShare products.

Note

Sharing and unsharing of NFS directories and files requires the same user permissions required by Windows NT Server and LAN Manager. The local user account must be logged on as a member of the Administrators, Server Operators, or Power Users groups.

Sharing NFS Server Resources

Two separate and complimentary mechanisms govern file access through the NFS server. The first is the NFS administrator's ability to control both which server resources are made available as network resources and what access clients within the network will have to the data. The second is the security administration performed by the underlying server file system itself. Effective access permission granted to any user is the more restrictive of these two mechanisms.

Share permissions are the first line of defense for the NFS server. Using share permissions, an administrator can control which network NFS client nodes have read and/or write access to NFS Shared resources. Four levels of access are available depending on the type of object selected, as follows:

  • No Access

This prevents all mount or connection requests for the share except for those individual client nodes or client groups that have a type of access specified.

  • Read-Only

The client is allowed to mount and read the shared resource, but cannot alter it.

  • Read-Write

The client may mount, read and write the shared resource.

  • Root

The client may mount, read, write, and perform "superuser" type operations on the file system assuming the requesting User ID is correct for the operation, and that is maps to the Administrator privilege. This access level can only be assigned to individual client nodes or client groups.

To determine if sufficient permission is available for the NFS request, the Global Permission is checked first. If this is not sufficient, an individual client's permission entry is checked. If no individual client permissions are present, then permission is given based on client group access.

File permissions within NFS are very much like those in a UNIX system. Under UNIX, every file belongs to a single user and group; the user must be a member of the group that owns the file. More precisely, a file has a single user ID and a single group ID. Because several different user accounts can have the same user ID, and several groups the same group ID, it may be ambiguous to speak of a particular user or group. The following criteria, in order of decreasing precedence, govern access to files:

  • Access granted to the owner of the file, a user with the same effective user ID as the file owner ID.
  • Access granted to members of the group to which the file belongs, users can belong to several groups simultaneously.
  • Access to granted to all others, such as those who do not own the file and are not members of the group to which the file belongs.

Each permission category controls three modes of access:

  • Read, which is the ability to open the file for read access and examine its contents without altering it in any way.
  • Write, which is the ability to open the file with write access and update its contents.
  • Execute, which is the ability to load the file into the system and run it. For directory files, execute access is interpreted as search permission.
Understanding the Security Descriptor

Intergraph DiskShare uses the Windows NT security descriptor when implementing NFS access permissions. The security descriptor is the structure that governs security within Windows NT. The security descriptor contains the following components:

  • File owner.
  • File group.
  • System Access Control List (SACL). The SACL is used for auditing and does not affect file permissions.
  • Discretionary Access Control List (DACL).

The following is an example of a security descriptor:

Owner: | spike |
Group: | UtilGroup |
DACL: | spike | Read (R)
UtilGroup |  | Read (RX)
Everyone |  | Read (RX)

In this example, the file owner is spike, the file group is UtilGroup, and the DACL shows the permissions given to spike, UtilGroup, and Everyone.

Within the security descriptor, the file owner and file group are pointers to Security Identifiers (SIDs). The SID can be thought of as the internal representation for an individual user or group. The primary reason for using SIDs is to distinguish between accounts across different domains that may share the same account name. Even though the names are the same, they represent different accounts and can thus be given different access rights to the same file.

Understanding the DACL

The Discretionary Access Control List (DACL) within the security descriptor provides the core of Windows NT security. The DACL is a list of entries that grants or denies certain rights to specific users or groups. A list entry is called an Access Control Entry (ACE). Each ACE consists of the following:

  • A Security Identifier (SID) to identify a particular user or group.
  • An access list specifying the rights allowed or denied for the user or group.

The following is an example of a DACL:

DACL: | mrjones | Full Control (All)
ToolGroup |  | Read (RX)
Everyone |  | Read (RX)

In this DACL, mrjones has read, write, and execute access to the file; members of the group ToolGroup have read and execute access, and members of the group Everyone (all other users) have read and execute access.

The following rules govern access to a file:

  • If no DACL is present, everyone is granted full access.
  • If a DACL is present, but contains no entries, everyone is denied any access.
  • The file owner always has the ability to change the DACL.
Reverse Mapping Permissions

The function of Intergraph DiskShare is to translate between a security descriptor on the computer running Windows NT Server and Intergraph DiskShare and a (UID, GID, mode) triplet on the NFS client.

Intergraph DiskShare controls permission translation with reverse mapping. Intergraph DiskShare's NFS Administrator program allows the DiskShare administrator to specify a mapping between NFS User and Group IDs and their corresponding Windows NT users and groups.

  • A given UID can be mapped to any Windows NT user.

Because multiple UIDs can be mapped to the same Windows NT user, one of the mappings will be marked as the default mapping. The default mapping is the UID to be returned when the mapped Windows NT user is found to be the file owner.

If the given UID is not mapped, the ANONYMOUS LOGON account will be used. This can have some undesirable results, so we recommend that all UIDs be mapped to a valid Windows NT account.

  • A given GID can be mapped to any Windows NT group.

Note If the given GID is not mapped, no group will be assigned, and no group entry will be placed in the DACL.

You can use the reverse mapping feature when mapping from NFS to Windows NT, or from Windows NT to NFS.

Sharing Files and Directories on a NFS Server

Once the DiskShare product is installed, the ability to share the NFS server files and directories and grant permissions to the users is provided through the computer running Windows NT Server.

To share files and directories on a NFS Server

1. Click Start, and then click Run.

2. In Open, type winfile, and then click OK.

3. On the Disk menu, click Share as.

4. Click NFS, and then click OK.

5. In the New NFS Share dialog box, type the path of the file you want to share.

6. Click Permissions.

The NFS Share Permissions dialog box appears.

7. Enter the settings you want for Anonymous UID and Type of Access, and then click Add.

8. Under Names in the Add Clients and Client Groups dialog box, click the user to be granted access.

9. In Type of Access, click the setting you want, and then click OK.

UNIX Client Sign On

Once the above steps are performed, the UNIX client is mapped with the proper permissions to the computer running Windows NT Server. When the UNIX client signs onto the server, authentication is provided via pcnfsd on the UNIX server to Windows NT User Account.

From the UNIX client, create a local directory as a mount point. Then mount the exported directory to a local directory.


Windows NT Clients Authenticating to UNIX Servers

At Terra Flora, a third party product called Intergraph PC-NFS for Windows NT will be installed on all computers running Windows NT Workstations and client computers running Windows NT that need access to UNIX servers. When the Windows NT client computer starts, a login screen will display. The user logs into the NFS authenticating server and can access the resources for which permissions have been granted.

A new product called Intergraph DiskAccess will replace the product Intergraph PC-NFS for Windows NT. It is scheduled to ship 30 days after the Windows NT Server 4.0 product ships. The current product of Intergraph PC-NFS for Windows NT can be used with server versions of the Windows NT product which proceeded the 4.0 version, and operates fine with version 4.0. The major difference between Intergraph's DiskAccess and PC-NFS will be changes to the graphical interface.

The users at Terra Flora have been granted permissions and the user accounts and passwords have been entered in the /etc/Passwd file of the authenticating UNIX server.

Installing Intergraph PC-NFS for Windows NT

Intergraph PC-NFS for Windows NT is to be installed on the computers running Windows NT Workstation and Windows NT Server, which will require client access to UNIX servers. For instructions on installing Intergraph PC-NFS for Windows NT, see the documentation provided with the product titled PC-NFS for Windows NT Quick Start Guide. Once installed, the product provides File Manager functions, a Control Panel-based configuration program and various utility programs.

Configuring PC-NFS

Configuration of the product can be performed to customize PC-NFS to fit your network environment.

To start PC-NFS Config

1. Click Start, point to Settings and click Control Panel.

2. Double-click PC-NFS Config.

See online Help for details about using PC-FNS Config.

Logging onto a UNIX Server Using PC-NFS

Once the above steps are complete, computers running Windows NT Workstation and Server that will require client access to UNIX servers can logon to Windows NT and be authenticated to the UNIX servers in the same step. When a user logs into the system and starts a Windows NT session, by default the PC-NFS Login dialog box appears to indicate that PC-NFS software is running.

Authentication establishes UNIX-style user and group permissions for UNIX clients on the network and is necessary if the NFS server restricts entry by user name. You do not have to use the PC-NFS Login dialog box to log in to the server before connecting to network-based NFS resources. However, if you do not do so, you may find that an NFS server restricts or denies access to some or all of its resources.

To log on as a Windows NT client to a UNIX server

1. Click Start, point to Programs, point to PC-NFS for Windows NT, and then click PC-NFS Login.

2. In PCNFSD, type the name of the NFS authenticating server.

This can be any computer running NFS, such as a UNIX server for which the user has permissions.

3. In Username, type your user name for login purposes.

4. In Password, type your password.

5. Click Log In.

Mounting Remote Resources

To mount or connect to a resource, use the Windows NT Explorer. Remote NFS resources mounted through PC-NFS software appear as virtual disk drives on your computer and display as network drives in Windows NT Explorer.

To Mount Remote Resources

1. Click Start, point to Programs, and then click Windows NT Explorer.

2. On the Tools menu, click Map Network Drive.

The Map Network Drive dialog box appears.

3. In Drive, click the drive you want to use.

4. In Path, type the path to the remote device to which you want to attach.

5. To map to another network drive using a different user account or group account ID, enter than information in Connect As.

6. Click OK.


Windows NT Clients Authenticating to NetWare Servers

On Terra Flora's network, there are existing installations of Novell NetWare, which are primarily used for file and print services. User accounts and privileges are stored in the NetWare Bindery, which is Novell's equivalent of the Windows NT directory. Access is validated based on user accounts and passwords in a Windows NT domain via the directory database, or on a Novell NetWare server via the bindery.

Novell uses the IPX/SPX protocol as their primary network protocol. In order for Windows NT Workstations or Windows NT Servers to communicate with the NetWare services, Microsoft developed NWLINK, an IPX/SPX-compatible protocol. NWLINK is the fundamental building block for the NetWare-compatible services on the Windows NT platform, and by itself, NWLINK does provide connectivity for database access to databases running as NetWare Loadable Modules on NetWare servers. So, for example, a Visual Basic application running on Windows NT Workstation can access an Oracle database running on a NetWare server, through ODBC and the NWLINK components.

Client Service for NetWare (CSNW)

The Client Service for NetWare installed on a computer running Windows NT Workstation provides basic file and print connectivity for that client to a NetWare 3.x server, or a NetWare 4.x server which includes the functionality of CSNW on the server platform. A different service, Gateway Service for NetWare (GSNW), provides access for computers running Windows NT Server to NetWare Servers.

To add CSNW

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Click Add.

5. Click Client Services for NetWare, and click OK.

6. Type the path to the CSNW files, and click Continue.

7. In the Client Services for NetWare Dialog box, type the name of the NetWare Server that will be used for authentication, click OK, and then click Close.

You must restart the computer to complete the installation. Click Yes and the computer will restart to complete the process.

Configuration of CSNW is necessary for the Windows NT Client to be able to connect to the NetWare server. A preferred server is selected when the CSNW service is added to the computer running Windows NT Workstation. In addition, as a result of adding CSNW, a CSNW icon is added to the Control Panel.

To activate and configure CSNW

1. Click Start, point to Settings, and click Control Panel.

2. Double-click CSNW.

3. In the Current Preferred Server dialog box, select a server, if necessary, and then click OK.

The Preferred Server setting performs the Attach command to the NetWare server and thus provides authentication to the NetWare server providing that the user and privileges have been added to the NetWare Bindery on the server that the user is trying to access.

Gateway Service for NetWare (GSNW)

The Gateway Service for NetWare (GSNW) provides computers running Windows NT Server all support necessary to connect to NetWare servers, plus the additional capability to re-share the network connections from a NetWare server. The service allows the computers running Windows NT Server to access the NetWare servers as if they were just another client and, in addition, allows the network clients to access files on a NetWare server without having to have a NetWare client redirector on an IPX/SPX protocol stack loaded.

Gateway Service for NetWare depends on and works with two other NetWare compatibility features of Windows NT Server; the NWLink protocol, and NWLink NetBIOS. NWLink is an implementation of the internetworking packet exchange (IPX) and sequenced packet exchange (SPX) transport protocols used by the NetWare network. NWLink NetBIOS is a Microsoft-enhanced implementation of Novell NetBIOS, and transmits Novell NetBIOS packets between a NetWare server running Novell NetBIOS and a Windows NT computer, or between two Windows NT computers. The Microsoft implementations of the IPX, SPX, and Novell NetBIOS compatible protocols can seamlessly coexist with other protocols on the same network adapter card.

The computer running Windows NT Server establishes a network connection to the NetWare server, similar to any network client connection.

Gateway Service for NetWare is installed from the Windows NT Server CD-ROM.

Note

Before you install the Gateway Service, you must remove any existing NetWare redirectors, such as NetWare Services for Windows NT from Novell, and then restart your computer.

To remove existing NetWare redirector installations

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services Tab.

4. Click the existing NetWare redirector software, and click Remove.

5. When prompted to confirm your choice, click Yes.

You must restart your computer to complete the removal process.

You are now ready to install the Gateway Service on a computer running Windows NT Server. You must be logged on as a member of the Administrators group for the local computer to install and configure the Gateway Service for your Windows NT computer. When you install the Gateway Service on a computer running Windows NT Server, the NWLink transport protocol is also installed if it is not already on your computer.

Activating a Gateway

Before enabling a gateway on a computer running Windows NT Server:

  • A user account must be set up on the NetWare network with the necessary rights for the resources you want to access.
  • The NetWare server must have a group named NTGATEWAY with the necessary rights for the resources you want to access.
  • The NetWare user account you use must be a member of the NTGATEWAY group.

By controlling membership in the NTGATEWAY group, the administrator can control which Windows NT Server computers can be gateways to the NetWare server, and what kind of access to what files each user account has.

The administrator has total control over whether the gateway allows access to files and print queues on the NetWare server. With a gateway, the network administrator can control access to NetWare network resources either over the gateway or directly on the NetWare network:

  • On the Windows NT Server computer acting as a gateway, the administrator can restrict access by limiting which network users or groups have access to gateway shares. Using multiple share restrictions through a gateway, the Windows NT administrator can control which network users and groups can access files through the gateway.
  • Using NTGATEWAY special gateway group created on the NetWare file, the administrator can set trustee rights on the directories and files to which users and groups are allowed access through the gateway. There is no auditing of gateway access.

To make a NetWare server available to a gateway account

1. Use the NetWare syscon utility to create the NTGATEWAY group account on the NetWare file server.

2. Use syscon to create a NetWare user account with the same name and password the user will use to log on from the Windows NT Server computer.

3. Add the gateway account to the NTGATEWAY group.

4. Establish trustee rights for the NTGATEWAY group.

For detailed information on the syscon utility and NetWare user accounts and trustee rights, see your NetWare documentation.

If you want to control user access, you can set permissions for the share when you create it, or later if your needs change.

Install Gateway Services for NetWare

Once the user gateway and information is added to the NetWare server, you are ready to install GSNW on the computer running Windows NT Server.

To install GSNW

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Click Server, and then click Add.

5. Click Gateway Services for NetWare, and click OK.

6. Type the path to the source files, and click Continue.

7. In the Gateway Services for NetWare dialog box, enter the name of the NetWare server to which the computer running Windows NT Server will connect.

8. Click Gateway.

9. Select the Enable Gateway check box.

10. Type the NetWare user account created to logon to the NetWare server from a computer running Windows NT Server, and click Add.

11. In the New Share dialog box. type the Share name of the gateway on the NetWare server.

12. Type the full path to the new share on the NetWare server.

13. Type an entry in Comment, if you want one.

14. Enter a letter for the drive on which the new share will reside.

15. If necessary, enter a value to limit the number of users.

16. Click OK.

The GSNW option is added to Control Panel and is used to activate the gateway.

Limitations of the Gateway Service for NetWare

GSNW is not designed to be a high bandwidth, user intensive, high performance gateway. It is designed to meet the needs of the customers who desire to have casual access to files that exist on a NetWare server, from a Windows Networking, or remote client.

Accessing Shared Resources on the NetWare Server

To access shared resources on a NetWare server, use the Map Network Driver option in the Explorer. You can map to both print and file servers. Again, this assumes that the proper privileges are assigned to the user when the connection is attempted.

To access shared resources

1. Click Start, point to Programs, and click Windows NT Explorer.

2. On the Tools menu, click Map Network Drive.

3. In Drive, confirm that the drive displayed is the one that is mapped to the server you want to access.

4. In Path, type the path to the resource to which you are trying to connect.

5. To connect to the specified drive on start up, select the Reconnect at Logon check box.

6. Click OK.

Commands to View and Find NetWare Servers

From the command line you can view your existing network connections, and their network providers.

To view network connections

1. Click Start, point to Programs, and click Command Prompt.

2. Type Net Use, and press enter.

You can also browse the network to specifically find NetWare servers.

To browse for NetWare Servers

1. Click Start, point to Programs, and click Command Prompt.

2. Type Network:NW, and press enter.

Windows NT Client Logon to NetWare

Logging onto the NetWare network is accomplished through Windows NT. When the user starts a computer running Windows NT Server or Workstation and the steps outlined above are complete, the Begin Logon dialog box appears. The user then supplies the alt+ctrl+del key sequence and the Logon Information dialog box appears. When the user provides the logon information, the user is authenticated to the Windows NT network. At the same time, the user is authenticated to the NetWare network and has access to all NetWare resources for which they have been granted permissions.


NetWare Clients Authenticating to Windows NT Servers

At Terra Flora, the NetWare clients are, in most cases, configured with only the NetWare client software, including the IPX/SPX stack, and the NCP protocol. For many reasons, including limited conventional memory, or other incompatibilities, the users simply cannot run multiple protocol stacks on their client machines.

It is easy to justify a business case for connecting the NetWare clients to the Windows NT Servers. This connection would allow the computers running Windows NT Server to absorb the additional file and print load on the network and save Terra Flora the expense of investing in additional NetWare systems.

In the past, Terra Flora has been reluctant to take this step because completing the connection of the NetWare clients to computers running Windows NT Server would have required adding SMB networking support to and changing the configuration on each NetWare client, which just did not make cost-effective sense.

Now using the File and Print Services for NetWare, network clients can directly access information on a Windows NT Server without changing any of the client-side software or configuration information.

The File and Print Services for NetWare uses an NCP-compatible protocol to support file and print services to NetWare clients, using either the NETX or VLM redirectors. To the NetWare client, the Windows NT Server looks like a NetWare 3.12 server, providing both file and print resources via the same dialogs as the NetWare servers themselves.

To install FPNW on a computer running Windows NT Server

1. Click Start, point to Programs, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Click Have Disk, and then type the path to the FPNW files, which are shipped on disks or a CD-ROM as part of a separate Microsoft product called Services for NetWare.

5. Click OK.

6. In the Select OEM Option dialog box, click File and Print Services for NetWare, and then click OK.

7. In the Install File and Print Services for NetWare dialog box, type the location for the SYSVOL directory that will be the equivalent of the NetWare SYS: volume in Directory for SYS Volume.

8. In Server Name, type the computer name that the NetWare client computers will use to access the server.

9. Type a password for the Supervisor's account in Supervisor Account, and then type the same password in Password and Confirm Password.

10. In Tuning, click an option for tuning server performance.

11. If you are installing File and Print Services for NetWare on a domain controller, enter a password for the FPNW Service Account when prompted.

You must restart the computer to complete the installation. The FPNW icon will then appear in Control Panel; a check box and NW Compat option are added to the New User dialog box for User Manager for Domains.

The network administrator can then select the Maintain NetWare Compatible Login check box to allow the user to log on to File and Print Services for NetWare.

Notes

  • In step 7 of the procedure above, it is recommended that you specify a directory on an NTFS partition to be the equivalent of the NetWare SYS: volume. If you specify a directory on a non-NTFS partition, you lose the security features that NTFS provides and will not be able to set or enforce file or directory security settings. SYS is the volume that is traditionally created.
  • In step 8, above, the Server Name must be typed in all capital letters. The default is the server's computer name with "FPNW" appended, but can be any NetWare-compatible name that does not conflict with any other NetWare server names.
  • In step 9, above, the password can be as many as 14 characters, and is case-sensitive.
  • If you install File and Print Services for NetWare on multiple domain controllers in a domain, you must specify the same password for this account on each domain controller on which you install the utility.

Security access to FPNW on the Windows NT server is specified in the user's User Account. For information on setting up User Accounts, see Concepts and Planning.

NetWare Client Logon to Windows NT

Logging onto the Windows NT network is accomplished through NetWare. When the user starts the NetWare client, the user provides the necessary information to log onto the NetWare network. At the same time that the user is authenticated to the NetWare network, the user is also authenticated to the Windows NT network and has access to all Windows NT resources for which they have been granted permissions.


Windows NT Clients Authenticating to Banyan Servers

Windows NT Clients can authenticate to Banyan servers using the Banyan Enterprise Client for Windows NT version 5.56. The Windows NT clients will be able to access file and print resources on Vines server using this product.

Installing Banyan Enterprise Client for Windows NT

Banyan provides a product called Banyan Enterprise Client for Windows NT which enables the computers running Windows NT server or workstation to connect as clients to the Banyan servers.

At Terra Flora, user accounts and passwords are set up on the Banyan server that match the user accounts and passwords set up in the Directory Services of Windows NT.

To install Banyan Enterprise Client for Windows NT

1. Click Start, point to Programs, and click Windows NT Explorer.

2. Select the letter of the drive that contains the setup files.

3. Double-click Setup.exe.

4. In the Network Communications dialog box, select the Enable IP Encapsulation check box, and then click Advanced.

5. In the VINES Workstation Configuration dialog box, select the settings you want, if necessary, and then click Continue.

6. In the VINES Desktop Configuration dialog box, select the options shown in the following illustration.

7. Select the Create VINES Program group named check box and enter the name of the VINES program as you want it to appear under Programs on the Start menu.

8. Select the Change AUTOEXEC.NT check box to load the TSR, and then click OK.

9. In the Configure Network Computer Name dialog box, type the name of the computer on which you are installing Banyan Enterprise Client for Windows NT, and then click Continue.

You must restart the computer to complete the procedure.

Notes

  • You are not required to use Log In Search, but if the groups are set up on the Banyan server, you can use this feature. The groups specified in the Search List will be searched to see if the user that is attempting to log in is a member of that group and what the permissions are associated with the user. You can specify up to three groups. When the user attempts to log on, the first group is checked, if no information about the user is located, the second group is checked. If no information about the user is found, the third group is checked. If no user information is found, the log in attempt fails.
  • The Load Banyan VINES Workstation during system start check box must be selected if the computer running Windows NT is to authenticate to the Banyan server automatically during logon.
  • The Use Windows NT Logon for VINES (common login) option creates a common login for both Windows NT and Banyan VINES. This requires that the user account and password on both machines be the same.
  • You can specify the log in attempt seconds before the result is a time out failure.
  • Step 10, above, allows MS-DOS applications to recognize the Banyan connections. This is required since most administrative applications running on the Banyan server are MS-DOS based.
  • In step 11, above, the Name must be included in a group in Street Talk on the Banyan server. You can indicate any name that is included in the group but the default will be the name of computer on which you are installing the product.

If the Banyan Enterprise Client for Windows NT is configured as described, login will take place when the Windows NT client starts up. When the user logs into the Windows NT network, authentication to the Banyan server also occurs.

If you elect not to configure automatic log in to the Banyan server because use is infrequent, the users can sign onto the Banyan server from the Windows NT Start menu.

To log into the Banyan server

1. Click Start, point to Programs, and click VINES (the program group name will appear as entered in the Vines Workstation Configuration dialog box).

2. Double-click Login.

3. In the VINES Login dialog box, type the user's account name and password that is configured on the Banyan server, and then click OK.

The VINES Login Status dialog box appears. Once this dialog box is closed, the Windows NT Start menu dialog box appears.


Banyan Clients Authenticating to Windows NT Servers

Banyan Systems Inc. has announced their StreetTalk Access for Windows NT which allows Banyan clients to directly access file and print resources on Windows NT servers. For more information, please contact Banyan Systems Inc. at http://www.banyan.com.


Windows 3.1 Clients Authenticating to Windows NT Servers

In order for a Windows 3.1 client to connect to a network, network software such as LAN Manager or Microsoft Networking Clients must be installed and configured. See the user documentation accompanying the LAN Manager or Microsoft Networks product for installation instructions. At Terra Flora, LAN Manager 2.2c is the product that will be installed to allow the Windows 3.1 clients to access the network.

Once LAN Manager is installed, the Config.sys and Windows\system.ini files will be updated and the network will start up automatically when the client running Windows 3.1 is started.

In addition, for a user to log onto a computer running Windows NT Server the user's account with necessary permissions must exist on the computer running Windows NT Server. For information on creating the user account and assigning permissions to access resources, see Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

Once LAN Manager is installed, the LAN Manager Logon will display every time the Windows 3.1 client starts up.

If a User Account and permissions have been set up on the Windows NT Server, the user is authenticated to the Windows NT network. To access the file and print servers, the user supplies the network path and connects to the required Windows NT resources.

To connect to Windows NT resources

1. On Program Manager, click LAN MAN.

2. Click Net Admin.

3. Double-click Network.

The Drives - Network Connections dialog box appears.

4. Select the Drive Letter for the connection.

5. In Path, type the path to the Windows NT Resources to which you want to connect.

6. To connect to the Windows NT Resources each time the computer starts up, select the Reconnect at Startup check box.

7. Click Connect.

Note

The user can connect to the network using File Manager. On the Disk menu, click Connect Network Drive and enter the path of the network resource to which you want to connect.


MS-DOS Clients Authenticating to Windows NT Servers

In order for a DOS client to connect to a network, network software such as LAN Manager or Microsoft Networks must be installed and configured. See the user documentation accompanying the selected product for installation. At Terra Flora, LAN Manager 2.2c is the product that will be installed to allow the MS-DOS clients to access the Windows NT network.

Once LAN Manager is installed, the Autoexec file is changed and the network will start up automatically when the client running DOS is started.

In addition, for a user to log onto a computer running Windows NT Server the user's account with necessary permissions must exist on the computer running Windows NT Server. For information on creating the user account and assigning permissions to access resources, see Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

When the network starts, the user types the Net Use command at the prompt and supplies the server name and share to which they want to connect. In the example below, the user wants to connect to payroll share on the Supply and Manufacturing payroll department server. At the prompt, the user would type:

Net Use * \\CAWPS30DPT01\Payroll

When enter is pressed, an available drive letter is assigned and connection to the server is completed.


Windows For Workgroups Clients Authenticating to Windows NT Servers

At Terra Flora, the clients running Windows for Workgroups are already configured and working together in workgroups. The workgroups are defined by task. For example, one of the payroll workgroups consists of all those responsible for entering hours worked into the payroll system. Since all the computers running Windows for Workgroups are already connected as workgroups, it is a simple configuration task to the computers to access other network computers running Windows NT Server.

Before the users of the computer running Windows for Workgroups can logon to the computer running Windows NT Server, the user's accounts and passwords must be set up and proper permissions assigned to the user on the Windows NT Server. For details, see Microsoft Windows NT Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

To make sure TCP/IP is enabled

1. On the Program Manager, double-click Network.

2. Double-click Network Setup.

3. In the Network Setup dialog box, make sure that Microsoft TCP/IP-32 3.11b is one of the drivers selected, and then click OK.

If the driver is not selected or is not available, see your Windows For Workgroups documentation for instructions on how to select the driver.

Note The driver is located on the NT Server CD and can be selected from the \Clients\TCP32WFW directory.

At Terra Flora, the Windows for Workgroups client will log on onto the computer running Windows NT Server. In order to accomplish this task, the computer running Windows for Workgroups needs to be properly configured.

To configure the computer running Windows for Workgroups to join the Windows NT domain

1. On the Program Manager, double-click Main.

2. Double-click Control Panel.

3. Double-click Network.

4. In the Microsoft Windows Network dialog box, make sure the computer name appears in Computer Name.

5. In Workgroup, click the domain the user will log on to.

6. In Default Logon Name, type the user account, as set up on the Computer running Windows NT Server.

7. Click Startup, and then specify settings in the Startup Settings dialog box for how logon will occur when you start the computer running Windows for Workgroups.

8. Under Options for Enterprise Networking, select Log On to Windows NT or LAN Manager Domain.

9. Make sure the setting for Domain Name is correct, and then click Set Password.

10. In the Change Domain Password dialog box, make sure the information displayed is correct, or change the password, and then click OK.

The password must match the user account information set up on the computer running Windows NT Server.

When the user starts up the computer, the Welcome to Windows for Workgroups dialog box appears.

If the Logon Name is correct, the user types the password, clicks OK, and is authenticated to the Windows NT Network. The information can be changed.


Windows 95 Clients Authenticating to Windows NT servers

At Terra Flora, Windows 95 clients have been configured and are in use throughout the Terra Flora Network. Configuration of each Windows 95 client is required for the client to access the Windows NT Domain.

During Windows 95 setup, information is supplied which will be reviewed during the configuration process. Additional information will be configured about the Windows NT Domain and the Windows NT client.

Prior to configuring the Windows 95 clients, the Terra Flora administrators set up user accounts on the Windows NT servers, granting the proper permissions to each user that will access the computers running Windows NT Server. For details, see Microsoft Windows NT Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

To configure the Windows 95 client requiring access to a computer running Windows NT Server

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. In the Network dialog box, click the Configuration tab, which displays information that was input during the setup of Windows 95.

4. Click Client for Microsoft Networks, and then click Properties. The dialog box appears.

5. Enter settings in the Client for Microsoft Networks Properties dialog box, as illustrated below, substituting the name of your Windows NT domain in Windows NT domain, and then click OK.

6. Click TCP/IP and the installed net card, and then click Properties.

7. Verify that the IP address information is correct.

8. Verify the information contained on the other TCP/IP tabs: DNS Configuration, WINS Configuration, Gateway, Bindings, and Advanced, and then click OK.

Refer to the Windows 95 Resource Kit for more information about these options, if necessary.

9. In the Network Dialog box click the Identification tab.

10. Type the name of the computer, the NT domain name, and a description of the client, and then click OK.

You must restart the computer for the changes to take effect.

When the client starts Windows 95, the Enter Network Password dialog box appears. To log on to the network, the user enters the User Name and Password that match the ones set up for the user on the computer running Windows NT Server.


Macintosh Clients Authenticating to Windows NT Servers

Microsoft Windows NT Server Services for Macintosh is a thoroughly integrated component of Microsoft Windows NT Server, making it possible for computers running Windows NT Server and Apple Macintosh clients to share files and printers.

With Services for Macintosh, Macintoshes need only the Macintosh operating system software to function as clients; no additional software is required. You can, however, set up the optional user authentication module, which is software that provides a secure logon to the Windows NT Server.

For complete information on planning and setting up the Macintosh network, see the Microsoft Windows NT Server 4.0 Networking Supplement.

Installing Services for Macintosh

Terra Flora is using Macintosh clients to produce some of the necessary graphical marketing materials. At Terra Flora, they will enable Services for Macintosh on the computers running Windows NT Server using the Network icon in the Control Panel and the Windows NT Server distribution disk.

When Services for Macintosh are installed, the AppleTalk Protocol, File Server for Macintosh, and Print Server for Macintosh are automatically started, or enabled. An explanation of these services is provided in the Microsoft Windows NT Server 4.0 Networking Supplement, Chapter 15, "Introduction to Services for Macintosh."

In addition, setting up Services for Macintosh creates an icon in Control Panel, which gives the administrator the same server administration capabilities as the MacFile menu, excluding volume management, for the local computer.

To set up Services for Macintosh

Services for Macintosh are loaded through the Network Icon on the Control Panel from the CD ROM accompanying the Windows NT Server product.

1. On the Control Panel, click the Network icon.

2. Click the Services tab.

3. Click Add.

4. On Network Service, click to Services for Macintosh, and click OK.

5. Type the full path of the Services for Macintosh, and click Continue.

6. In the AppleTalk Protocol Configuration dialog box, enter the changes you want, such as selecting a new zone, a different network, or enabling AppleTalk routing.

For details about this configuration, see, Microsoft Windows NT Server 4.0 Networking Supplement, Chapter 16, "How Services for Macintosh Works," Chapter 18, "Setting Up Services for Macintosh" and Chapter 21, "Working with Macintosh-Accessible Volumes." Choose OK or Cancel if you don't want to change the configuration.

The computer must be restarted for the changes to take effect.

Authentication Services for Macintosh Client Software

Microsoft authentication is an extension to AppleShare, which provides a more secure logon session to a computer running Windows NT Server. It encrypts passwords and stores them on the computer running Windows NT Server. Administrators can either set up or instruct Macintosh users to set up the authentication file on their Macintoshes via the network.

With Microsoft authentication, users can also specify a domain when they log on or change their passwords. So if there are multiple domains on the network, the user's account domain will be used.

Note

Because the Apple System software up to version 7.1 does not fully support custom user authentication modules, Microsoft encourages the installation of Microsoft Authentication (MS UAM) only if increased security is necessary on the network computers running Windows NT Server.

A user authentication module (UAM) is a software program that prompts users for an account name and password before they log on to a server. Apple's Chooser has a standard UAM built in, which uses the clear-text password method of security. Microsoft Authentication offers an additional level of security because it encrypts, or scrambles, a password so it cannot be monitored when it is sent over the network. At Terra Flora, the administrators have determined that encryption is an important security measure, and will require use of Microsoft Authentication when the user logs on to the computer running Windows NT Server.

To gain access to the authentication files

1. On the Macintosh Apple menu, click Chooser.

The Chooser dialog box appears.

2. Click the AppleShare icon, and then click the AppleTalk zone in which the computer running Windows NT Server resides.

3. Click the name of the Windows NT Server, and then click OK.

A sign-in dialog box appears.

4. Click Registered User or Guest, as appropriate, and then click OK.

A server dialog box appears.

5. Click Microsoft UAM Volume, and then click OK.

To install the authentication files on the Macintosh client

1. From the Macintosh Desktop, double-click the Microsoft UAM Volume.

The Microsoft UAM Volume window appears.

2. Drag the AppleShare Folder to the System Folder on your hard disk.

Note If the Macintosh client already has an AppleShare Folder in the System Folder, you will see a message that asks whether you want to overwrite the folder. You should not overwrite it because it may contain other UAMs, such as the NetWare UAM. If you want to maintain the files in the original AppleShare Folder, simply open the AppleShare Folder in the Microsoft UAM Volume, and drop the MS UAM file into your existing AppleShare Folder in your System Folder.

Configuring Services for Macintosh

Apple Talk Protocol is a stack of protocols that Services for Macintosh uses to route information and configure zones. It works behind the scenes to ensure that computers on the network can talk to one another. The Apple Talk Protocol is configured accessing Services for Macintosh located under the Network option of the Control Panel.

To configure Services for Macintosh

1. In Control Panel, click Network.

2. In the Services tab, select Services For Macintosh and click Properties.

The Microsoft AppleTalk Protocol Properties dialog box appears.

3. Select a default network from a list of adapter cards bound to the AppleTalk Protocol.

For details, see the Microsoft Windows NT Server Networking Supplement, Chapter 19, "Configuring Services for Macintosh."

How Files Are Shared

With Services for Macintosh, Macintosh users can easily share files stored on the computer running Windows NT Server. On a computer running Services for Macintosh, files are stored in shared directories or in Macintosh volumes.

With Services for Macintosh, Macintosh users cannot automatically gain access to all shares. To make a directory, and consequently its subdirectories, which may or may not be shared on the Windows NT system network, available to Macintosh users, the administrator must designate the directory as a Macintosh-accessible volume. For details, see the Microsoft Windows NT Server 4.0 Networking Supplement, Chapter 21, "Working with Macintosh-Accessible Volumes."

Creating Volumes

All Macintosh-accessible volumes must be created on an NTFS partition. Similar to creating a share (shared directory) for PC users, you can designate a directory as a Macintosh-accessible volume. If the directory is to be accessed by PC clients as well as Macintosh clients, make sure you share the directory using the Share As command on the Disk menu and designate it as a Macintosh-accessible.

Note You cannot give a directory Macintosh-accessible volume status if it is a subdirectory of another directory that has Macintosh-accessible volume status. For specifics, see Microsoft Windows NT Server Networking Supplement, Chapter 21, "Working with Macintosh-Accessible Volumes."

You can designate a directory as a Macintosh-accessible volume using the Create Volume command on the MacFile menu. From the Create Volume dialog box, you can create the volume by accepting the default settings, or may customize by changing the options.

To create a Macintosh-accessible volume

1. In File Manager, select the directory that you want to designate as a Macintosh-accessible volume.

2. On the MacFile menu, click Create Volume.

3. Type a name in Volume Name, which will be the name Macintosh users will see when they log on.

4. To accept the default options (listed below in Table 5.1), click OK.

Or, go to step 5.

5. Enter the settings you want to change from the default settings.

Refer to Table 5.2, below, for descriptions of the options.

6. Click Permissions to set directory permissions for Macintosh users, and then click OK.

The Macintosh-accessible volume automatically inherits the permissions of the corresponding directory, although you may change these. See Setting Permissions for Volumes and Folders later in this section.

Table 5.1. The default settings for the Create Volume dialog box

Option | Default Setting
Volume name | Same as the directory name. The character limit is 27.
Path | Same as the directory path.
Password/Confirm Password | No password.
This volume is read-only | This option is Off.
Guests can use this volume | This option is On (Yes).
User Limit | Unlimited.
User Permissions | Current directory permissions.

Table 5.2 Alternate settings for the Create Volume dialog box

Option | Description
Password | Enter the password for this volume. When Macintosh users try to mount this volume, they will be asked for this password.
Confirm Password | Confirm the password just entered.
This volume is read-only | This volume and all of its contents have read-only access. This option supersedes all directory permissions set with the Permission button. In other words, if you give this volume read-only access, the permissions of directories with less restrictive access will not be honored.
Guests can use this volume | Guests can have access to this volume. If not selected, guests do not have access.
User Limit | Number of clients that can simultaneously mount the volume on the respective desktops. Select Unlimited or Allow and specify the number of users.
Permissions | Set access permissions on this volume. See Setting Permissions for Volumes and Folders later in this section.

Creating Folders in a Volume

You can create subdirectories for a Macintosh-accessible volume from the computer running Windows NT Server or folders from the Macintosh clients. In either case, the procedure for creating the directories or folders is no different than it is for creating other directories or folders on the respective systems.

On the computer running Windows NT Server, the folders appear in the File Manager's directory tree as subdirectories of the directory. To create another subdirectory, you select the directory in which it will appear and choose Create Directory from the File menu.

On the Macintosh, you create folders using the New Folder command on the File menu. You can view and use the folders in the Macintosh-accessible volume just organized by Name, Date, Icon, Size, and so forth.

Note

You cannot designate the subdirectory or folder as another Macintosh-accessible volume when the directory is already designated as a Macintosh-accessible volume.

Network Security

Services for Macintosh translates user identification, authentication (passwords), and permissions so that the security of the server is maintained regardless of the type of client used.

Services for Macintosh uses the same user accounts database as Windows NT Server. Therefore, if you already have Windows NT Server accounts created for the people who will be using Macintoshes on the network, you don't need to create additional accounts.

One aspect of Windows NT Server user accounts, the user's primary group, applies only to Services for Macintosh. The user's primary group is the group the user works with most, and it should be the group with which the user has the most resource needs in common. When a user creates a folder on a server, the user becomes the owner. The owner's primary group is set as the group associated with the folder. The administrator or owner can change the group associated with the folder.

Passwords

Macintosh users are logged on to a computer running Windows NT Server in one of three possible scenarios:

  • Guest Logons

Using Services for Macintosh, you can set up guest logons, which allow users without accounts to log on to the server using a Macintosh. You can specify what access to resources guest logon users have; administrators typically grant guest users fewer permissions than users who have accounts on the server. If the guest logon option is enabled, the server always approves the logon request without requiring a password. For information on setting up Guest Logons, see the Microsoft Windows NT Server Concepts and Planning Guide.

  • Cleartext Passwords

Cleartext password protection is part of the AppleShare client software on Macintoshes. It provides less security than encrypted password protection because the passwords are sent over computer lines and can be detected by "sniffers," which are network monitors that can look for passwords. Moreover, the AppleShare passwords can be no longer than eight characters. This method of protection is offered for Macintosh users who use the standard AppleShare client software or System 7 File Sharing.

  • Encrypted Passwords

An encrypted, or encoded, password is more secure than the cleartext password type of security. Windows NT Server encodes passwords and stores them so that they cannot be directly stolen from the client itself. Encrypted passwords can be as long as 14 characters. Services for Macintosh offers encrypted passwords to Macintosh clients.

For more information about security, see Windows NT Server Services for Macintosh, Microsoft Windows NT Server 4.0 Networking Supplement and the Windows NT Server System Guide.

Volume Passwords

Services for Macintosh provides an extra level of security through Macintosh-accessible volume passwords. A volume password is a password you assign to a Macintosh-accessible volume when configuring it. Any Macintosh user who wants to use the volume must type the volume password. Volume passwords are case-sensitive. Volume passwords are optional; when you create a new Macintosh-accessible volume, the default is to have no volume password.

Note

Because of a constraint with the System 6 and 7 Finder, you cannot automatically mount a volume with a volume password at startup or by double-clicking an alias. You also cannot automatically mount a volume if the user originally connected to the volume with Microsoft Authentication.

Permissions

Access to network files and directories is controlled with permissions. With the Windows NT security system, you specify which users can use which shares, directories, and files, and how they can use those files. The Macintosh-style permissions differ in that they can be set for folders (directories) only—not files.

The Windows NT Server Administrator account always has full permissions on Services for Macintosh volumes.

Macintosh users set Macintosh-style permissions on the folders they create. In Windows NT, new files and new subdirectories inherit permissions from the directory in which they are created.

Macintosh files effectively inherit the permissions set on folders. Even though the Macintosh doesn't have file permissions, any Windows NT permission specified for a file will be recognized by the File Server for Macintosh, even though the Macintosh user won't see any indication in the Finder that these permissions exist. The Macintosh has the following four types of permissions for a folder:

  • See Files, which lets a user see what files are in the folder and read those files
  • See Folders, which lets a user see what folders are contained in the folder
  • Make Changes, which lets a user modify the contents of files in the folder, rename files, move files, create new files, and delete existing files
  • Cannot Move, Rename, or Delete, which prohibits these actions on a folder

The Macintosh security scheme is based on the idea that every folder on a server falls into one of three types: private information, accessible only by a single person, the owner of the folder; group information, accessible by a single workgroup; and public information, accessible by everyone.

For example, there can be a folder containing information that all members of a certain group should see, but that only one person can change. The person allowed to change the information should be the owner of the folder and should have See Files, See Folders, and Make Changes permissions. The workgroup that uses the folder should be the group associated with the folder and should have only See Files and See Folders permissions. Because no one else needs to see the folder's contents, the Everyone category should not be selected.

Although a folder's owner will often be a member of the group associated with the folder, this is not required.

With both Macintosh-style and Windows NT Server-style permissions, users' access to folders can be defined differently for each directory and subdirectory within a directory tree. For example, you could give a user See Files, See Folders, and Make Changes permissions for one folder, only the See Files permission for a subfolder of that folder, and no permissions at all for another subfolder.

The Macintosh does not support file-level permissions. When a file has file-level permissions, those permissions apply to Macintosh users only if the permissions are more restrictive than those assigned for the directory that contains the file.

Setting Permissions for Volumes and Folders

You control who can use Macintosh-accessible volumes by setting permissions. Permissions also control what kind of access is granted to users. For example, permissions dictate which users can make changes to a folder, and which ones can read the content of the folder but not alter it.

To set Macintosh-style permissions on a Macintosh-accessible volume or folder

1. In File Manager, click the directory you've designated as a Macintosh-accessible volume or a subdirectory that represents a folder in the volume.

2. On the MacFile menu, click Permissions.

3. Select or click to clear the See Files, See Folders, and Make Changes check boxes, as appropriate, for Owner, Primary Group, and Everyone.

Refer to Table 5.3, below, to help you decide which permissions to set.

Table 5.3 Options for Permissions

Permission | Description
See Files | Allows the owner, primary group, or everyone to see and open files in this folder.
See Folders | Allows the owner, primary group, or everyone to see and open folders in this folder.
Make changes | Allows the owner, primary group, or everyone to add or delete files and folders, and save changes to files in this folder.

4. To copy the permissions you set to all folders within this volume or folder, select the Replace permissions on subdirectories check box.

5. To prevent Macintosh users from moving, renaming, or deleting the volume or folder, select the Cannot move, rename, or delete check box.

Printing

When you set up a printer on the AppleTalk network to be used with Services for Macintosh, you can specify whether Services for Macintosh will capture the printer. This means that the printer will not accept print jobs from any source other than the print server, thus giving Windows NT Server administrators complete control over the printer.

In general, it is best to always capture a printer, unless a source other than the print server prints jobs on the printer. If a printer won't be used by anything other than Windows NT Server, Microsoft recommends that you capture it. Doing so ensures that users don't accidentally bypass the print server and send print jobs directly to the printer or reset the printer, which may cause spooler problems.

If a printer is not captured and both Windows NT Server and another source send jobs to the printer, no jobs will be interrupted; however, while the printer is printing a job from one source, it will appear busy to the other sources.

For information about how to capture AppleTalk printers, see the Networking Supplement.

Before setting up printers, it's important to understand the distinction between a printing device and a printer that you create using the Add Printer wizard.

  • A printing device is the hardware that actually does the printing, such as a Hewlett-Packard LaserJet.
  • A printer you create using Windows NT Server is a software interface between the document and the printing device. You create a printer using the Add Printer wizard, and each printer sends jobs to the printing device, according to the specified priority—for example, on a first-come, first-served basis.

These concepts and others are explained more fully in the Windows NT Server Concepts and Planning Guide and the Windows NT Server Services for Macintosh.

When Services for Macintosh (SFM) is set up, several AppleTalk services are integrated into Windows NT Server. The print server, called Print Server for Macintosh, is integrated into the Windows NT Server Printers folder. The print server makes printers connected to the computer running Windows NT Server available to Macintosh clients, and it makes AppleTalk PostScript printers (with LaserWriter drivers) available to PC clients.

When the print server receives print jobs from the print server, it sends them to a spooler, which is a portion of the hard disk. The spooler then sends the print job to the specified printing device—for example, to a printing device on the AppleTalk network. This enables Macintosh users, as well as PC users, to submit print jobs and continue working on their computers without waiting for the print job to complete.

The print server also translates all incoming PostScript files if the print request is to a non-PostScript printer attached to the computer running Windows NT Server. So, a Macintosh client (but not a Windows NT client) can send a PostScript job to any Windows NT Server printer.

Note

This implementation of Postscript RIP for SFM supports 300 dpi and Postscript level 1.

Stopping and Restarting the Print Server

When you set up SFM, all services are automatically started, including the print server. You might want to stop and restart the print server if, for example, you must remove a printing device. You stop and restart the Print Server for Macintosh using the Services icon in Control Panel.

To stop and restart Print Server for Macintosh

1. In Control Panel, click Services.

2. In Service, click Print Server For Macintosh.

3. Click Stop or Start, as appropriate, and then click.

4. To change options at startup, click Startup.

5. Click Close.

Creating a Printer on a Computer Running Windows NT Server

After you have physically attached a printing device to a computer running Windows NT Server (either directly or on a network), use the Add Printer wizard to create a printer that represents it. You can create more than one printer representing the same printing device.

For example, if you have a printing device in your office but also share it with others over the network, you might want to create two printers representing the printing device. You can create a printer for yourself that is not shared over the network and a second printer that is shared. Then it's easy to control the use of the shared printer. You can set permissions on the shared printer, ensuring that only members of your department can print to it. Or you can set a low priority for it, ensuring that documents you send to the printer will always print before documents sent by those who share it.

Another common example is to create a printer that spools to a printing device at night and another printer that spools to the same printing device during the day.

To create a printer, you must be logged on with sufficient permissions. Administrators, Server Operators, and Print Operators can create printers.

To create a printer

1. Click Start, point to Settings, and then click Printers.

2. In the Printers dialog box, click Add Printer.

3. Follow the Add Printer wizard to choose the printer ports, printer driver, and printer name. You can also set printer properties, such as location and scheduling information.

See the online Help during setup for more information.

Note

The printer name can be up to 32 characters in length. This name will appear in the title bar of the printer window. By default, it is the name that network users (except MS-DOS users) will see when you share the printer.

Choose the Share this printer option during setup. In the Share Name box, specify the printer name that you want MS-DOS clients to see.

When you are selecting a destination, if the printing device is physically connected to the Windows NT Server computer, then select the appropriate port. If the printing device is on the network, click Add Port. Choose AppleTalk Printing Devices from the Printer Ports dialog box and click OK. From the Available AppleTalk Printing Devices dialog box, select a zone and a printer, and click OK.

Setting Up a User Account for Macintosh Print Jobs

After setting up Services for Macintosh, you should create an account that will be used by all Macintosh clients when printing jobs to captured AppleTalk printing devices or to other devices on the computer running Windows NT Server. You should also configure Print Server for Macintosh to use this account.

After it is created, the user account (for example, MACUSERS) appears in the list of names that appears when you choose Permissions from the Security menu in Print Manager. You can give specific rights to this user account, just as you would any user account, including Print and No Access.

For more information about permissions, see Networking Supplement, Chapter 22, "Managing the File Server." For information on creating a user account and more specific information for configuring it to run with a service (such as Print Server for Macintosh), see the Windows NT Server Concepts and Planning Guide.

To configure the Print Server for Macintosh service to use a user account

1. In Control Panel, double-click Services.

2. Click Print Server For Macintosh.

3. Click Startup.

4. In the Print Server For Macintosh dialog box, click This Account and type the user account.

5. To require Macintosh users of the computer running Windows NT Server to use a password , type a password in Password and in Confirm Password.

6. Click OK.

Enabling Clients to Use Printers on the AppleTalk Network

With SFM, both PC and Macintosh clients can send print jobs to printing devices or spoolers on the AppleTalk network.

The printing device must appear as a LaserWriter in the Chooser, and there must be a Windows NT print driver for the printing device.

Macintosh clients use printers just as they normally do—through the Chooser. If an AppleTalk printer has been set up through Print Manager, it can be captured so that Macintosh clients cannot access it directly. This causes Macintosh print jobs go through the computer running Windows NT Server and be spooled along with print jobs from PC clients.

You can disable the capture setting. Doing so enables any Macintosh client to print to an AppleTalk printer directly. There are a few problems with this scenario, the most important being that the jobs will not be under the administrator's control.

To release or recapture an AppleTalk printing device

1. In Printers, select an AppleTalk printing device.

2. On the File menu, click Properties.

3. Click the Ports tab, and then click Configure Port.

A dialog box appears, asking if you want to capture this AppleTalk printing device.

4. Click Yes to capture it.

– Or –

Click No to release it.

5. Click OK.

When an AppleTalk printer is released, any Macintosh user on the AppleTalk network can use the device directly.

A printing device on AppleTalk can be captured when SFM is set up and a printer is created for it. It must remain captured so that all Macintosh clients send print jobs through the computer running Windows NT Server. If a printing device has been released for some reason, you can recapture it.

You can select another spooler instead of an actual device. Use this type of configuration with caution. It is possible to create an endless loop of print spooling with this method.


Centralized Services

At Terra Flora, the goal of centralizing administrative services was achieved with the installation of Windows NT Server as the common platform from which to interoperate their heterogeneous networks. Use of the Windows NT network operating system has provided Terra Flora with the ability to administer all clients and servers running operating systems other than Windows NT from one client computer. Several sessions can be started on any computer running Windows NT Server or Workstation so the administrator can view and monitor all network computers.

Though there are some limitations to the extent of administrative functionality, Windows NT Server was the most flexible and functional solution to the challenges presented to Terra Flora's plan to centrally administer the different network operating systems.


The Decision to Centralize Administrative Tasks

To Terra Flora, one of the major benefits of installing and configuring Windows NT Server services is the ability to administer all clients and servers on the network from a central point, regardless of the geographic location of the computer or which operating system is running.

Additionally, all the servers can be administrated on one client running Windows NT Workstation or Server because the computer will support the running of multiple sessions.

Most of the administration of all network servers will be performed by the network administration staff located in Sacramento, California. The administration may not be performed on a single computer, but the ability to do so provides greater flexibility to the network administrators. Occasionally, the administrators will want to sign onto machines while visiting remote sites and administer computers located at corporate headquarters or at the remote sites. At some remote sites administration may be localized to reduce excessive wide area network (WAN) traffic.

The administrative tasks necessary to manage the clients and servers are the same regardless of the operating system that is being run on the computer. For example, administrators set up and maintain user accounts and grant permissions to users or groups of users on Windows NT Servers as well as on UNIX and NetWare servers. Administrative tools are supplied with each operating system and the idea of interoperability includes the ability to sign onto any computer in the network and run any administrative tools on any network computer. Windows NT provides this capability.

This ability will reduce the administrative costs associated with managing a network the size of Terra Flora's. This eliminates the need for administrators to be located at remote sites, the need for administrators to travel to remote sites to perform routine administrative tasks and eliminates some of the wide area network (WAN) traffic that would occur administering files remotely.

The following table provides examples of which administrative tools are provided by which operating systems to remotely administer the servers at Terra Flora. This section will focus on the ability to connect to the administrative tool from Windows NT. The details of how to use each of the administrative tools is provided in the documentation accompanying the operating system.

Operating System | Administrative Tools (not all-inclusive) | Use of the Tool
UNIX | FTP | Allows users to connect to the UNIX remote hosts (computers) to transfer files such as /etc/passwrd, /etc/hosts, etc.
 | Telnet | In many UNIX-oriented environments, administrative functions are performed via a remote console command-line interface, known as Telnet. Telnet is a simple UNIX remote command line window to the remote host server. Windows NT Workstation and Windows NT Server have a graphical Telnet application in the Program Manager's Accessories group.
 | X/Windows | Provides access to graphical programs running on UNIX servers. The XWindows client acts as a UNIX display server. The Windows NT client can run both character bit DOS applications and XWindows graphical interface applications.
NetWare | Syscon | The primary NetWare administration tool used to set up and maintain user accounts, policies and resource permissions.
 | RConsole | Provides remote connection of a network client to the NetWare network as a remote system console.
 | PConsole | Provides the tools necessary to manage print servers.
Banyan | Manage.com | Provides a menu from which Banyan administrators can choose the administration tool with which they want to work.
 | Mservice.com | Allows the user to add services with which they will administrate Banyan servers to a menu to select from and run.
 | Muser.com | Allows administration of Banyan user accounts.
Windows NT | User Manager | Allows the management of user and group accounts which grant access to the Windows NT network resources.
 | Server Manager | Server Manager is used to manage Windows NT domains and computers.
 | Internet Homepage | The Catapult server provides centralized access to the Internet and acts as an Internet proxy server.


UNIX Administration

Two additional services need to be added to the computers running Windows NT Workstation or Server in order to use computers running Windows NT Workstation or Server to administer UNIX servers, FTP and Telnet.

File Transfer Protocol

File Transfer Protocol (FTP) allows users to connect to the remote computers to transfer files. What this means to the administrator is that, for example, files stored on a remote UNIX computer can be transferred to a local Windows NT computer, administrative changes can be made to the files, and the files transferred back to the remote computer for continued storage.

FTP is widely used on the Internet for transferring files. Terra Flora is anticipating that over time, this file download process will be hidden by world wide web (WWW) browsers that will perform the transfer operations in the background as required by the applications.

FTP Server

FTP Server capabilities are built into Windows NT Server. This provides capabilities for UNIX clients or windows sockets-based UNIX oriented applications to perform file transfer. Files can be transferred to the UNIX server for administration or transferred from a UNIX server for administration.

Note

One of the limitations of the FTP server is that the password to the FTP server is sent over the wire in clear text, meaning that the password is not encrypted or otherwise protected on the network. Any person on the network with a network sniffer can capture the password packets and know the password for the specified user.

Due to the clear-text password limitation, most FTP servers are configured to only allow anonymous connections. Anonymous is a specific user name which is used for non-secure sessions. Anonymous is used to prevent anyone from accidentally using a valid user name and password to gain server access. Once the user is connected to the server using the anonymous user name and password, the user is prompted for their domain name service (DNS) name as the password, such as johndoe@terraflora.com to provide an audit of the user's access and hits on specific files stored on the FTP server.

Installing FTP Server

FTP Server is installed when you install the Internet Information Server. Once the FTP server is installed, there is a graphical interface that provides the connection to the server that stores the files you want to transfer.

To install the FTP Server service

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Services tab.

4. Click Add.

5. In the Select Network Service dialog box, click Microsoft Internet Information Server 2.0 (IIS).

6. Click Have Disk, and enter the path to the Windows NT CD-ROM or disks that contain the services.

7. Click OK.

8. If you are not using IIS and are installing it only to access FTP, click to clear the following check boxes in the Microsoft Internet Information Server 2.0 Setup dialog box:

Internet Information Service

World Wide Web Services

Gopher Service

9. Click OK.

Transferring Files Using FTP

This example illustrates how files would be transferred from a UNIX server using FTP. The files would be transferred to a Windows NT Server and the administrator could make changes to the files and transfer the files back to the UNIX server on which they are normally stored. The administrators at Terra Flora use FTP to transfer remote server files on a regular basis to avoid editing the files remotely over the WAN. At Terra Flora, the UNIX server is named CAPWKSENT01. Using the procedure below, FTP will be used to transfer the files from the UNIX server to the Windows NT Server.

To transfer files from the Terra Flora UNIX server, the administrator will

1. Click Start, point to Programs, and click Command Prompt.

2. Type FTP and the host name or IP address of the server from which files will be transferred.

3. If you are using FTP to access an UNIX server, you must provide the UNIX user-account and password information, as shown in the following illustration.

Once you connect to the UNIX server, you can use standard FTP commands, such as Get and Put, to transfer files, as if you were running FTP on the UNIX server.

Telnet Client

At Terra Flora as in many UNIX environments, administrative functions are often performed on a remote console, which is a control client computer through which a user communicates with a server. The administrator uses a command-line interface available on the client, known as Telnet, which is a simple UNIX remote command line window to access the remote server. Windows NT Workstation and Windows NT Server provide a graphical Telnet application. The application allows the computer running Windows NT Workstation or Windows NT Server to connect to the UNIX server and use the Telnet commands to administer the server. The computer running Windows NT Server or Workstation connects to the UNIX server as just another remote client.

Note

Windows NT does allow administrative commands to be issued through the command-line interface, however, it is not the preferred method of administration.

Windows NT Server does not contain a Telnet server, but Telnet servers are available as shareware on the Internet.

The Telnet client service is installed as part of the installation TCP/IP services on of either computers running Windows NT Workstation or Server.

To run the Telnet service on the computer running Windows NT Workstation or Server

1. Click Start, point to Programs, point to Accessories, and then click Telnet.

2. On the Connect menu, click Remote System.

3. In Host Name, type the name of the UNIX computer on which the files you want to administer are stored.

4. Click Connect.

5. If the client is not already connected to the UNIX server, type the user-account and password-login information required to access the UNIX server when prompted.

Once logged onto the UNIX server, you can administer the UNIX files stored on the server.

For UNIX clients to communicate with Windows NT Servers, Integraph's DiskShare product was installed on the computers running Windows NT Server. Once installed, the UNIX clients were able connect to the Windows NT server, once a user account had been set up and proper permissions on the Windows NT server granted to the user of the UNIX client. For details, see "UNIX Clients Authenticating to Windows NT Servers," earlier in this chapter. The UNIX client can then administer the Windows NT Servers.

Access to the UNIX servers by Windows NT clients can now be performed because Integraph's PC-NFS was installed on the Windows NT client computers. Again, since proper permissions have been granted to the user on the UNIX server, the Windows NT client can administer the UNIX servers. For complete instructions on the installation, configuration and use of Integraph PC-NFS and DiskShare, see the earlier topics in this chapter, "UNIX Clients Authenticating to Windows NT Servers" and "Windows NT Clients Authenticating to UNIX Servers."

Once the connection is made between the computers running UNIX and Windows NT, administration can be performed using the additional services of FTP and Telnet as described above.

X/Windows Support

Client/server graphical application support for UNIX-based applications has evolved around the X/Windows interface. The X/Windows application programming interfaces (APIs) help to span the different variations of UNIX implementation in various networking environments by providing a common application interface programming model for applications.

In the popular PC-based computing circles, a client computer refers to the end-node machines sitting on the desktops, while the server computer is a powerful processing "workhorse" computer which makes resources available to a large number of clients.

In X/Windows, and UNIX, terminology, the X/Windows server is really the X/Windows display server which provides the services to display the graphical interface application to the user and resides on the desktop machines. The X/Windows client is the is the processing engine for the X/Windows application. For those readers familiar with the PC-based nomenclature, simply reverse the typical definitions when thinking about the X/Windows environment.

X/Windows is different than typical PC-based client server models. In X/Windows, the server application executes the instructions on the network server known as the X/Client. The network server executes the applications, and sends the commands to draw the appropriate graphical images on the screen. The user mouse clicks and keyboard commands are sent across the network to the X/Client application, and are processed remotely. In essence, X/Windows applications that are viewed on the desktop are actually running on the remote network server, and the graphical information, as well as the user input are relayed across the network to the display client.

Applications written to the common X/Windows specifications will run on many different versions of UNIX, however, some of their version-specific functionality may not be available on all platforms.

X/Windows Server

Terra Flora, with its mixed networking environment, has made use of the traditional UNIX computing model which is a workstation computer (server) running a version of UINX connected to a mainframe or minicomputer (client) for, as an example, statistical sales analysis.

However, as the PC-based computing environment has spanned the enterprise, the ease of use and powerful graphical productivity applications have moved into sales and accounting areas by necessity to communicate with the rest of the corporation, as well as provide a common platform for document creation, charting, and integrated analysis.

At Terra Flora, this has also led to the dual-computer desktops in many work areas. One workstation running UNIX with X/Windows applications for statistical sales analysis work, and another desktop running the Windows interface for document creation, charting and integrated analysis presented in graphical format. The problem with this solution is that it is expensive, both in hardware costs and administration. Additionally, it is difficult to get information from one system to another. There is a solution for this problem, X/Windows servers for Windows NT.

In the previous section, an example was presented illustrating how a computer running Windows NT Server or Workstation can become a remote console to administer files on, for example, a UNIX server. The interface presented to the client computer is a character mode interface. There is no access to the graphical applications on the UNIX server.

At Terra Flora, an X/Windows product from Hummingbird Communications, Ltd called eXceed, version 5, will be installed on all computers running Windows NT Workstation or Server that will act as remotes consoles connecting to the UNIX servers. By installing the X/Windows product, the client will be able to access a DOS character mode interface and access the graphical interface applications.

To install X/Windows

1. Click Start, and then click Run.

2. Follow instructions provided in the Exceed 5 documentation about the information to be entered on the command line and other installation details.

Below are samples of the graphical interface demo files loaded on all UNIX servers. The demo files are all loaded on a single Windows NT computer to illustrate the ability to use both graphical applications and character bit applications.

The first shot is the graphical application called Xeyes.

The second screen shot is of the UNIX graphical application called Xclock.

The third screen shot is of the graphical application called calculator.

As demonstrated in the screen shot below, the Windows NT client can be used to run multiple sessions. Any variety of the graphical applications can be run from a single station. On a single workstation, both Windows-based applications and X/Windows applications are accessible, and information interchange is relatively easy. The cost reduction is significant, as Windows NT Workstations are typically less expensive than UNIX workstations, plus the second desktop machine is no longer required.


NetWare Administration

NetWare servers cannot be administered directly. Instead a NetWare client acts as the system console and controls the administration of the NetWare server. A computer running Windows NT Server with the Gateway Services for NetWare (GSNW) enabled or a computer running Windows NT Workstation with the Client Services for NetWare (CSNW) enabled, can act as a NetWare client and connect to the NetWare Environment.

For complete instructions on installing and configuring CSNW and GSNW, see the earlier topics in this chapter, "Windows NT Clients Authenticating to NetWare Servers" and "NetWare Clients Authenticating to Windows NT Servers."

NetWare Administration Using a Windows NT Computer

At Terra Flora, CSNW or GSNW has been installed on all computers running Windows NT Workstation or Server that are going to function as NetWare clients to administrate NetWare servers. For a detailed explanation of CSNW and GSNW, installation and configuration instructions, see the earlier topics in this chapter, "Client Service for NetWare" and "Gateway Service for NetWare."

Now that the two systems can interoperate, any computer running Windows NT can act as a system console and run the NetWare Administration utilities, examples of which would be Syscon, PConsole and RConsole. For details on the use and operation of the NetWare Administration utilities, see the NetWare documentation.

Access to the NetWare environment as a NetWare client is accomplished through Windows NT using either the CSNW or GSNW service. When the computer running Windows NT Server or workstation with either the CSNW or GSNW service installed starts up, the Begin Logon dialog box appears. The user then logs into the Windows NT Network as normal, supplying the user account and password for Windows NT set up by the administrator. If the CSNW or GSNW service is correctly configured, the user is authenticated not only to the Windows NT network, but to the NetWare network at the same time.

Access to Syscon, RConsole and PConsole is accomplished on the Windows NT client as if the Windows NT client were a NetWare client. In a NetWare environment, the primary administration tool called System Console (Syscon) is used to set up user accounts, define policies, and grant user access permissions to the NetWare network.

The screen shot of Syscon below was captured on a computer running Windows NT Workstation or Windows NT Server connecting as a NetWare client to the NetWare environment.

RConsole provides a remote view of the NetWare system console. The console functions can be performed on the remote console. The screen shot of RConsole below was captured on a computer running Windows NT Workstation or Windows NT Server connecting as a NetWare client to the NetWare environment.

PConsole provides the administrator with the tools necessary to manage print servers. The screen shot of PConsole below was captured on a computer running Windows NT Workstation or Windows NT Server connecting as a NetWare client to the NetWare environment.

Multiple sessions of the administration tools can be run on a single Windows NT client. The information about each of the servers to which the client is connected will be displayed in a separate window on the client. This is a major benefit of using computers running Windows NT. The result is the ability to monitor all of the NetWare servers from one system console, which is not possible on computers running other operating systems such as MS-DOS.

To connect to additional NetWare servers

  1. Click Start, point to Programs, and click Windows NT Explorer.
  2. On the Tools menu, click Map Network Drive.
  3. In Drive, enter a drive letter, if necessary.
  4. In Path, type the path to the NetWare server.
  5. To connect to the NetWare server using another user account and password, type the information in Connect As (optional).
  6. Click OK.

Note

Although Windows NT Workstation and Windows NT Server versions 4.0 support connections to NetWare Directory Services (NDS), they do not support administration of NDS trees at this time.

The screen shot below displays multiple sessions of the administration tools running on one Windows NT client.

Administrating Windows NT Servers Using NetWare Clients

For a NetWare client to access and administer a Windows NT Server, File and Print Services for NetWare must be installed on the computer running Windows NT Server. Once FPNW is installed and configured, a NetWare client can sign onto the computer running Windows NT Server and perform administration tasks. For instructions on installing and configuring FPNW, see "NetWare Clients Authenticating to Windows NT Servers," earlier in this chapter. For details on the use of the administration tools, see online Help.


Banyan Administration

As part of the Terra Flora strategy to provide centralized network services, Terra Flora has installed Banyan Enterprise Client for Windows NT on all computers running Windows NT Server or Workstation that will be required to function as Banyan clients. Banyan servers cannot be directly administered. Instead as with NetWare and UNIX, server administration is performed on clients functioning as system consoles.

Installation of the Banyan Enterprise client for Windows NT allows the computer running Windows NT Server or Workstation to connect to the Banyan network as a system console. The system console has access to the administration tools on the Banyan server that allow the management of user accounts and other networking services.

When a computer running Windows NT Server or Workstation that will function as a Banyan client starts, the user supplies the same user account and password normally used to log on to Windows NT and is authenticated to the Windows NT network.

Logon to the Banyan server may be configured as automatic, which means that the configuration of the Banyan Enterprise client for Windows NT is set up so that authentication to the Banyan server is accomplished when the user supplies their user account and password for logging onto the Windows NT network. For information on installation and configuration of Banyan Enterprise Client for Windows NT on the on computers running Windows NT Server and Workstation, the section titled, "Windows NT Clients Authenticating to Banyan Servers," earlier in this chapter.

During Banyan logon, the redirector will map the system files volume to the default Z drive. The user can then select the administration tools they want to work with from drive Z.

From the DOS prompt, type Manage.com. Press enter. The Manage.com menu appears. From the menu, the user selects the type of administration that they want to do. See your Banyan documentation for details on the administration utilities available on the Manage.com menu. The screen shot of Manage.com below was captured on a computer running Windows NT Server connecting as a Banyan client to the Banyan server.

The first two menu options are the ones that we will focus on for the remainder of this section. Services (Mservice) allows the Banyan Administrator to administer the server using various services that can be specified on the menu. See your Banyan documentation for details on the use of Services options.

Services can be accessed in two ways.

  • At the DOS prompt, after connecting to the Banyan Server from a computer running Windows NT Workstation or Server, type Mservice.com and press enter.
  • Additionally, as is illustrated in this example, you can select option 1 Services on the Manage.com menu.

The screen shot of MService below was captured on a computer running Windows NT connecting as a Banyan client to the Banyan server.

Option 2 on the Manage.com menu allows the user to administer user accounts on the Banyan server. For detailed instructions on how to use the User option, see your Banyan documentation.

There are two ways to access Users:

  • At the DOS prompt, after connecting to the Banyan Server from a computer running Windows NT Workstation or Server, type Mservice.com and press enter.
  • Additionally, as is illustrated in this example, you can select option 1 Services on the Manage.com menu.

The screen shot of MUser below was captured on a computer running Windows NT connecting as a Banyan client to the Banyan environment.

Multiple sessions of the administration tools can be run on a single computer running Windows NT Workstation or Server acting as a client connected to a Banyan client. The information about each of the servers to which the client is connected will be displayed in a separate window on the client. This is a major benefit of using computers running Windows NT. The result is the ability to monitor all of the Banyan servers from one computer running Windows NT Workstation or Server acting as a system console. This feature also exists in a limited fashion on computers running Windows 95, but is not a feature that is available on computers running other operating systems such as MS-DOS.

The screen shot below displays multiple sessions of the administration tools running on one Windows NT client.


Windows NT Connectivity and Administration

Computers running Windows NT Workstation or Windows NT Server can be administered from any other computer running Windows NT Server or Workstation. Additionally, most computers operating in a heterogeneous network can be used to connect and in some cases administer computers running Windows NT Workstation or Windows NT Server.

  • By installing and configuring Intergraph DiskShare on the computers running Windows NT Server, UNIX clients can connect to connect to computers running Windows NT Server for access to file services.
  • By installing and configuring File and Print Services for NetWare on the computer running Windows NT Server, NetWare clients can be used to connect to computers running Windows NT Server.
  • By installing and configuring network software such as LAN Manager or Microsoft Works, Windows 3.1 clients and DOS clients can be used to connect to and administer Windows NT servers.
  • By installing and configuring Services for Macintosh, Macintosh clients can be used to connect to computers running Windows NT Server.
  • Computers running Windows for Workgroups and Windows 95 can be configured to authenticate automatically to the Windows NT network and can be used to administer the Windows NT servers.

For complete instructions on how to install and configure the software required for interoperating the different operating systems referenced above, see "Network Logon Services," earlier in this chapter.

User Manager for Domains

User Manager for Domains is used to administer user and group accounts which allow users to participate in a Windows NT domain and access the domain's resources. Additionally with User Manager for Domains, rights and permissions can be granted to the user and group accounts providing the appropriate amount of access and restrictions to network resources in the Windows NT domain.

Once a client computer accesses the Windows NT Server with the proper permissions, the client can administer the server. For complete instructions on how to install and configure the software required for interoperating the different operating systems referenced above, see "Network Logon Services," earlier in this chapter.

To run User Manager

  • Click Start, point to Programs, point to Administrative Tools (Common), and then click User Manager for Domains.

For complete instructions on the use of User Manager for Domains, see the Windows NT Server Concepts and Planning Guide, Chapter 2, "Working with User and Group Accounts." See Chapter 3, "Manager User Work Environments," for complete instructions on managing User Profiles and System Policies.

Server Manager

Client computers connected to the computer running Windows NT Server can be used to administer the computers running Windows NT Server by connecting to the servers. For complete instructions on how to install and configure the software required for interoperating the different operating systems referenced above, see "Network Logon Services," earlier in this chapter.

Server Manager is the tool used to manage domains and computers. With Server Manager you can:

  • Select a Windows NT domain, workgroup or computer for administration.
  • Manage a computer including viewing a list of connected users, viewing shared and open resources, managing services and shared directories and sending messages to connected users.
  • Manage a domain including promoting a backup domain controller to the primary domain controller (PDC), synchronizing servers with primary domain controllers and adding computers to and removing computers from the domain.

Once a client computer accesses the Windows NT Server, the client can administer the server. For complete instructions on how to install and configure the software required for interoperating the different operating systems referenced above, see "Network Logon Services," earlier in this chapter.

To run Server Manager

· Click Start, point to Programs, point to Administrative Tools (Common), and then click Server Manager.

For complete instructions on the use of Server Manager, see the Help file.

Internet Service

At Terra Flora, a server has been installed to provide a proxy agent to the Internet and prevent unauthorized access to or from the network. What happens is that network users communicate with the proxy agent server that acts as a fire wall to the network and the proxy agent server then communicates with the Internet. By the same token, users accessing the Terra Flora network from the Internet communicate with the proxy agent server acting as a fire wall and protecting the network from unauthorized access. There is no actual access to the Internet from the network and there is no access from the Internet to the network except through the proxy fire wall server, which will authenticate requested user access.

Additionally, the Internet server provides a central access point to the Internet. All users either exiting the network to the Internet or entering the network from the Internet will pass through this central server.


Replication and Backup Services

At Terra Flora, the Windows NT Replication service will be used to ensure that all crucial Enterprise level databases are replicated to other computers running Windows NT Server. These include WINS and DNS.

Terra Flora has elected to use a flexible back up strategy for the data that exists on their servers, at all levels. Third party software will be incorporated for online backups and to protect master copies of distributed databases and other software.

The business reasons for replicating and backing up the business applications and databases are fairly obvious, to protect the business critical applications and ensure that should servers fail, recovery is quick and accurate.


Terra Flora's Decisions About Replication

On servers running Windows NT Server, replication of the Enterprise databases are configured at the time that the Enterprise level service is installed. For example the WINS and DNS databases were configured to replicate on backup servers during configuration. Additionally, the primary domain controller (PDC) will replicate the directory services to the backup domain controller (BDC), ensuring fault tolerance and providing another server which can authenticate users of the Windows NT services.

DHCP is a database that is not automatically replicated. For this reason, Terra Flora will use the Replicator service, which is a service that is part of Windows NT Workstation and Server, to backup the DHCP database and files to another server, ensuring that should the primary server fail, DHCP information can be recovered and dynamic network addressing of clients and servers continue.


Terra Flora's Decisions About Backup

Terra Flora has elected to use a flexible back up strategy for the data that exists on their servers, at all levels. Regularly scheduled backup of the WINNT, data and software master copy directories will be performed using third party software which works in conjunction with Windows NT. For daily, weekly and disaster recovery, Terra Flora will use the Seagate, (formerly Arcada) BackUp Exec for Windows NT, Single Server/Enterprise Edition - Version 6 Product.

Seagate Backup Exec for Windows NT is a proven 32-bit backup that protects the entire network. With centralized administration and its exclusive ExecView monitoring console, Backup Exec provides client/server functionality for Windows NT data protection. Backup Exec supports any combination of clients on any platform, on the Windows NT network. The documentation accompanying the product will explain setup and configuration of backup service.

For online backups, Terra Flora uses Octopus for Windows NT to provide data fault tolerance and real time data protection between the Enterprise/Enterprise Remote servers and for designated data directories on the divisional/regional servers such as project directories. Online backups are backups that occur as data in a file or database is added, changed or deleted.

Octopus mirrors files and/or directories rather than disks and will be set up on the computers running Windows NT Server. Source servers are the computers where the data to be backed up resides and target servers are the computers where the mirrored data will be stored. Any changes to the source files are mirrored and sent over the network to the target computers. Documentation accompanying the Octopus product explains setup and configuration of backup services.

At the Terra Flora Enterprise/Enterprise Remote level, the computers running Windows NT Server will back up their own servers as well as back up data directories on the Division/Region servers. The Division/Region servers will backup their own servers as well as back up the data directories on the Department/Branch Office servers. The Department/Branch servers will backup their own servers and users of the Desktop workstations will be responsible for backing up the necessary information on the workstations.


Backup of the DHCP Directory and Files

Replication of the WINS and DNS databases is an automatic feature of both the Windows NT Server WINS and DNS services and is configured during the installation process of WINS and DNS. At Terra Flora, replication of these databases has been configured to replicate on different servers in the network. The DHCP service, while it does provide a backup of the database and files in the System32\DHCP\Backup directory, cannot automatically be configured to replicate to different servers. An additional step is required.

The System 32\DHCP\ Backup directory is stored on the same physical drive as the DHCP database directory. At Terra Flora, the plan is to backup the DHCP directory to a different physical device on the same computer running the Windows NT Server DHCP service and then replicate the backup to another server. This plan provides a backup DHCP database copy should either the physical drive on which the DHCP database is stored or the computer running Windows NT Server DHCP service fail. The backup plan for the DHCP servers is as follows:

1. The Registry will be edited to allow backup of the DHCP database to another physical drive on the DHCP server.

2. Additionally, each DHCP database and associated files will be replicated to an Enterprise/Enterprise level server that is not running DHCP.

3. The Replicator service will be used to back up the necessary file stored in the System32\DHCP\Backup directory to an Enterprise/Enterprise Remote server which is not running the DHCP service.

Refer to Terra Flora's network diagram, one DHCP database directory on the server named CANTS40ENT03 will be replicated to CANT40ENT01 and the other DHCP directory on the server named CANT40ENT02 will be replicated on CANT40ENT05.

Editing the Registry

At Terra Flora, the Registry Editor will be changed to ensure that backup is made to a different physical device on the DHCP server that stores the database and files.

To edit the registry

1. At the command prompt, type Regedt32, and press enter.

2. Double-click HKEY_LOCAL_MACHINE.

3. Double-click System.

4. Double-click CurrentControlSet.

5. Double-click Services.

6. Double-click DHCP Server.

7. Double-click Parameters.

8. Double-click Backup Database Path.

9. Change the first part of the line to indicate a different physical drive on the server, such asD:\System32\dhcp\backup.

The information will then be backed up to the physical drive indicated.

You can now use the Replicator Service to copy that directory to a backup server.

Managing Directory Replication

Backing up a directory to a different server is a task performed by Windows NT Server Directory Replicator service. The server on which the DHCP directory is stored will be configured as an export server. The server which will store the backup copy of the DHCP directory and files is the import server.

When you update a file in the directory tree on one server (the export server), the updated file is automatically copied to all the other computers (the import computers). Only servers running Windows NT Server can be export servers; import computers can run either Windows NT Server or Windows NT Workstation.

How Directory Replication Works

Directory replication is initiated and carried out by the Directory Replicator service. This service operates on each export server and import computer that participates in replication. The service on each computer logs on to the same user account, which you create for this purpose.

You set up an export server and import computers to send and receive updated files. An export directory on the export server contains all the directories and subdirectories of files to be replicated, and when changes are saved to files in these directories, the files automatically replace the existing files on all the import computers.

You can also specify whether to have the export server send changes out as soon as a file has changed or, to prevent exporting partially changed trees, to wait until one export subdirectory has been stable before exporting. See "Managing Exported Subdirectories," later in this chapter.

In addition, you can lock a particular export or import directory, when needed. Changes to the locked directory are not exported or imported until you unlock the directory.

On the export server, you also designate which computers or domains are to receive replicated copies of the directories this server is exporting.

An export server has a default export path:

C:\systemroot\SYSTEM32\repl\EXPort

All directories to be replicated are exported as subdirectories in the export path. Subdirectories created in the export path, and files placed in those subdirectories, are automatically exported. Export servers can replicate any number of subdirectories (limited only by available memory), with each exported subdirectory having up to 32 subdirectory levels in its tree.

An import computer has a default import path:

c:\systemroot\SYSTEM32\repl\IMPort.

Imported subdirectories and their files are automatically placed here. You do not need to create these import subdirectories. They are created automatically when replication occurs.

Replication Prerequisites

Before a computer can participate in replication, you must create a special user account. Then for each computer in a domain that will participate in replication, configure its Directory Replicator service to log on using that special account:

  • In User Manager for Domains, create a domain user account for the Directory Replicator service to use when logging on. Be sure the user account has the Password Never Expires option selected, all logon hours allowed, and membership in the domain's Backup Operators group. See online Help and Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 2, "Working with User and Group Accounts" and Chapter 3, "Managing User Work Environments" for details.
  • After the user account is created for each computer that will be configured as an export server or an import computer, use Server Manager to configure the Directory Replicator service to start up automatically and to log on under that user account. Be sure the password for that user account is typed correctly. See online Help for details.

Setting Up an Export Server

Any computer running Windows NT Server can be set up as an export server. (A computer running Windows NT Workstation cannot.)

Before you set up an export server, you must perform these tasks on the export server:

  • Assign a logon account to the Directory Replicator service of the export server.
  • Create the directories to be exported. They must be subdirectories of the replication export path (usually C:\systemroot\ SYSTEM32\REPL\EXPORT).

Use the Directory Replication dialog box to set up an export server.

Managing Exported Subdirectories

By clicking Manage under Export Directories in the Directory Replication dialog box, you can manage certain features of subdirectory replication by the export server:

  • You can lock a subdirectory to prevent it from being exported to any import computers. For example, if you know a directory will be receiving a series of changes that you do not want partially replicated, you can put one or more locks on the subdirectory in the export path. Until you remove the lock or locks, the subdirectory will not be replicated. The date and time the lock was placed is displayed so that you know how long a lock has been in force.
  • When you stabilize a subdirectory, the export server waits two minutes after changes before exporting the subdirectory. The waiting period allows time for subsequent changes to take place so that all intended changes are recorded before being replicated.
  • You specify whether the entire subtree (the export subdirectory and all of its subdirectories) or just the first-level subdirectory in the export directory path is exported.

Setting Up an Import Computer

Both Windows NT Server and Windows NT Workstation computers can be set up as import computers. A computer running Windows NT Server that is configured as an export server can also be configured as an import computer.

Before you set up an import computer, you must assign a logon account to the Directory Replicator service of the import computer.

On the import computer you do not need to create the imported subdirectories. A subdirectory is automatically created the first time it is imported.

Use the Directory Replication dialog box to set up an import computer. The Windows NT Server version of the Directory Replication dialog box is slightly different from the Windows NT Workstation version of this dialog box. The Windows NT Workstation version contains only the items related to imported directories.

Tip

You can set up a server to replicate a directory tree to itself (from its export directory to its import directory). This replication can provide a local backup of the files, or you can use the import version of these files as another source for users to access, while preserving the export version of the files as a source master.

Managing Locks and Viewing Import Subdirectory Status

You can use locks to prevent imports to subdirectories on an import computer. Import of a locked subdirectory to that import computer is prevented until the lock is removed. Locking a subdirectory on an import computer affects replication to only that computer, not to other import computers.

You can manage locks on subdirectories and also view the status of each subdirectory by clicking Manage under Import Directories in the Directory Replication dialog box.

The Status column can have one of four entries:

  • OK indicates that the subdirectory is receiving regular updates from an export server and that the imported data is identical to that exported.
  • No Master indicates that the subdirectory is not receiving updates. The export server might not be running, or a lock might be in effect on the export server.
  • No Sync indicates that although the subdirectory has received updates the data is not up-to-date. This could be due to a communications failure, open files on the import computer or export server, the import computer not having access permissions at the export server, or an export server malfunction.
  • No entry (blank) indicates that replication never occurred for that subdirectory. Replication may not be properly configured for this import computer, for the export server, or both.

The Last Update column shows the date and time of the latest change to the import subdirectory or to any of its subdirectories.


Point-to-Point Tunneling Protocol (PPTP)

With the release of Windows NT Server 4.0, the ability to communicate securely over the Internet has become a reality. At Terra Flora, this will mean that Seville, Spain will be able to communicate with corporate headquarters using the Internet. Terra Flora will install computers running Windows NT at remote sites including Seville, Spain. Seville, Spain will be configured to use PPTP through a dial up Remote Access Service (RAS) connection to the Internet Information Server (IIS) at the Enterprise level named CANTS40ENT04.


The Decision to Use PPTP

The Seville, Spain site is a Nursery growing plants for distribution to the retail stores. It has become, by necessity, a distribution site, implementing the same distribution procedures as other distribution sites. Basically, a computer running Windows NT Server will be installed at the Seville, Spain site, along with other computers running Windows NT Workstation, in order to computerize the manual processes. Computerizing the Seville, Spain site will also allow Nursery personnel to focus on tasks other than the tasks performed by the computers at other nursery and distribution sites.

Remote Access Service (RAS) has been offered with Windows NT Server since the product was introduced. A RAS server is usually connected to a PSTN, ISDN or X.25 line allowing remote users to access a various network servers. RAS now allows remote users access through the Internet by using the new Point-to-Point Tunneling Protocol (PPTP). For detailed information on RAS, see the Microsoft Windows NT Server 4.0 Networking Supplement, Chapter 5, "Understanding Remote Access Service," Chapter 6, "Installing and Configuring Remote Access Service" and Chapter 7, "RAS Security."

At Terra Flora, PPTP will be installed to enable remote users to access corporate networks securely across the Internet by dialing into an Internet Service Provider (ISP) or by connecting directly to the Internet. PPTP offers the following advantages:

  • Lower Transmission Costs

PPTP uses the Internet as a connection instead of a long-distance telephone number or 800 service. This can greatly reduce transmission costs.

  • Lower Administrative Overhead

With PPTP, network administrators centrally manage and secure their remote access networks at the RAS server. They need to manage only user accounts instead of supporting complex hardware configurations.

  • Enhanced Security

Above all, the PPTP connection over the Internet is encrypted and secure, and it works with any protocol (including, IP, IPX, and NetBEUI).

Applications for PPTP

PPTP provides a way to route Point-to-Point Protocol (PPP) packets over an IP, IPX or NetBEUI network. Since PPTP allows multiprotocol encapsulation, Terra Flora can send any type of packet over the network.

PPTP treats the existing corporate network as a PSTN, ISDN, or X.25 network. This virtual WAN is supported through public carriers, such as the Internet.

Compare PPTP to the other WAN protocols: When using PSTN, ISDN, or X.25, a remote access client establishes a PPP connection with a RAS server over a switched network. After the connection is established, PPP packets are sent over the switched connection to the RAS servers to be routed to the destination LAN.

In contrast, when using PPTP instead of a switched connection to send packets over the WAN, a transport protocol such as TCP/IP is used to send the PPP packets to the RAS server over the virtual WAN.

The end benefit for the corporation is a savings in transmission costs by using the Internet rather than long distance dial-up connections.


Secure Access to Corporate Networks over the Internet

A RAS client that has a PPTP driver as its WAN driver can access resources on a remote LAN by connecting to a Windows NT RAS server through the Internet. There are two ways to do this: By connecting directly to the Internet or by dialing an Internet Service Provider (ISP) as shown in the following examples.

The client that is directly connected on the Internet dials the number for the RAS server. The PPTP driver on the client makes a tunnel through the Internet and connects to the PPTP enabled adapter on the RAS server. After authentication, the client can access the corporate network, as shown in the figure below.

Note

Connecting directly to the Internet means direct IP access without going through an ISP. (For example, some hotels allow you to use an Ethernet cable to gain a direct connection to the Internet.)

The same functionality is achieved by calling an ISP instead of being directly connected to the Internet. The client first makes a call to the ISP. After that connection is established, the client makes another call to the RAS sever located anywhere on the Internet or the ISP and that establishes the PPTP tunnel.

At Terra Flora, the clients are directly connected to the Internet, no ISP is used. The RAS servers at headquarters and Seville will dial directly into the Internet.

Security Considerations

Data sent across the PPTP tunnel is encapsulated in PPP packets. Because RAS supports encryption, the data will be encrypted. RAS supports bulk data encryption using RSA RC4 and a 40-bit session key that is negotiated at PPP connect time between the RAS client and the Windows NT RAS server.

PPTP uses the Password Authentication Protocol and the Challenge Handshake Authentication Protocol encryption algorithms.

In addition to supporting encrypted PPP links across the Internet, a PPTP-based solution also enables the Internet to become a network backbone for carrying IPX and NetBEUI remote-access traffic. PPTP can transfer IPX traffic because it encapsulates and encrypts PPP packets so that they can ride TCP/IP. Thus, a solution does not depend only on TCP/IP LANs.

This technology gives Terra Flora the opportunity to send sensitive materials over the Internet, an option that they haven't had previously. They will use this connection to collect general ledger information from Seville and to provide to Seville marketing information such as product special pricing and corporate advertisements which will be incorporated into network web pages.


Installing PPTP

For PPTP to succeed, a PPTP driver must be installed on the RAS servers—and on the client or communications server—for PPTP tunneling to succeed.

To Install PPTP

  1. Click Start, point to Settings, and click Control Panel.
  2. Double-click Network.
  3. Click the Protocols Tab.
  4. Click Microsoft PPTP Driver, and then click Add.
  5. Click Have Disk if loading the software from disks or a CD.

Or, click OK if loading from the network.

  1. When prompted, type the full path to the Windows NT Server PPTP files, and then click OK.
  2. Enter the number of connections you want available to PPTP (that is, for Virtual Private Networks).

  1. Click the port on which you want to install the PPTP driver, and click OK.

You must restart your computer to complete the DNS installation.


Protecting a RAS Server from Internet Attacks

If PPTP filtering is selected, the selected network adapter for all other protocols is effectively disabled. Only PPTP packets will be allowed in.

Terra Flora will want to do this on all multihomed computers with one network adapter (with PPTP filtering enabled) connected to the Internet and another network adapter connected to the internal corporate network. Clients outside the corporate network can use PPTP to connect to the computer from across the Internet and gain secure access to the corporate network. Thus, the only traffic that can access the corporate network is PPTP packets from clients who have been authenticated using RAS authentication.

Note

The RAS client can either be connected to the Internet directly or to a service provider. It is not necessary to be connected to both to use PPTP.

To install PPTP filtering for protection

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Protocols tab.

4. Click TCP/IP Protocol.

5. Click Properties.

6. Click the IP Address tab, if necessary, and then click Advanced.

7. In Adapter, click the network adapter for which you want to specify PPTP filtering.

The PPTP filtering settings in this dialog box are defined only for the selected network adapter.

8. To enable PPTP filtering, click Enable PPTP Filtering.

You must restart the computer to have the settings take effect.

For more information about advanced TCP/IP configuration, see the topic "To Configure Advanced TCP/IP Options" in the TCP/IP online Help file.


Chapter 6 - TCP/IP Implementation Details

The Transmission Control Protocol/Internet Protocol (TCP/IP) suite is a set of networking transports that govern how data passes between networked computers. Microsoft has adopted TCP/IP as the strategic enterprise network transport for its platforms. Microsoft 32-bit TCP/IP for Windows NT is a high-performance, portable, 32-bit implementation of the industry-standard TCP/IP protocol.

This chapter is intended for network engineers and support professionals who are already familiar with TCP/IP or who have read the TCP/IP chapters in the Networking Supplement for Windows NT Server version 4.0. This chapter provides additional technical detail about Microsoft 32-bit TCP/IP as implemented in Windows NT.

This chapter discusses the following topics:

  • Microsoft TCP/IP architectural model
  • Microsoft Network Driver Interface Specification (NDIS)
  • Core TCP/IP protocol stack components
  • Transport driver interface (TDI)
  • Network application interfaces and Microsoft TCP/IP
  • Windows NT client/server programs that use TCP/IP

This chapter concludes with a summary of TCP/IP changes in Windows NT Server version 4.0.

Network traces are used throughout this chapter to help illustrate concepts. These traces were gathered and formatted using Microsoft Network Monitor, a software-based protocol tracing and analysis tool included in the Microsoft Systems Management Server product. All the IP addresses in these traces have been replaced with the IP addresses for the fictitious company Terra Flora.

Note

The base code described in this chapter is shared by all Microsoft 32-bit TCP/IP protocol stacks, including TCP/IP for Windows NT Server, Windows NT Workstation, and Windows 95. However, there are small differences in implementation, configuration methods, and available services. This chapter describes the implementation, configuration, and available services for Microsoft 32-bit TCP/IP for Windows NT.


Architecture of Microsoft TCP/IP for Windows NT

TCP/IP is the primary protocol of the Internet and intranets (networks that connect enterprise-wide local area networks). You can communicate with computers running under Windows NT, with devices that use other Microsoft networking products, and with computers running under non-Microsoft operating systems using TCP/IP (such as UNIX computers).

The TCP/IP protocol suite in Windows NT Server and Windows NT Workstation was completely redesigned beginning with Windows NT version 3.5. It is a high-performance, portable, 32-bit implementation of the industry-standard TCP/IP protocol suite and is easy to administer. Microsoft 32-bit TCP/IP for Windows NT provides support for standard TCP/IP features including:

  • Logical multihoming
  • Internal IP routing capability
  • IP multicasting support using the Internet Group Management Protocol (IGMP)
  • Duplicate IP address detection
  • Multiple default gateways
  • Dead gateway detection
  • Automatic discovery when using Path Maximum Transfer Unit (PMTU)

The TCP/IP protocol suite for Windows NT Server and Windows NT Workstation is comprised of:

  • Core protocol elements
  • Windows NT – based services
  • Interfaces between the protocol elements and services

The Windows NT – based networking services include, but are not limited to, the following:

  • Windows Internet Name Service (WINS), used for NetBIOS name resolution services
  • Domain Name System (DNS), used for host and domain name resolution services
  • Point-to-Point (PPP) and Serial Line IP (SLIP), used for Remote Access Service (RAS)
  • Point-to-Point Tunneling Protocol (PPTP), used for virtual private remote networks
  • TCP/IP network printing (lpr/lpd)
  • SNMP agent
  • NetBIOS interface
  • 32-bit Windows Sockets interface
  • Remote Procedure Call (RPC)
  • Network Dynamic Data Exchange (NetDDE)
  • WAN (wide area network) browsing support
  • High-performance Internet Information Server with Web, FTP, and GOPHER services
  • TCP/IP connectivity utilities, including finger, ftp, rcp, rexec, rsh, telnet, and tftp
  • Server software for simple network protocols, including Character Generator, Daytime, Discard, Echo, and Quote of the Day
  • TCP/IP management and diagnostic tools, including arp, hostname, ipconfig, nbtstat, netstat, nslookup, ping, route, and tracert

The following figure illustrates the Windows NT TCP/IP architecture model and shows the core protocol elements and the interfaces between protocol elements and services.

Figure 6.1 The Windows NT TCP/IP Architecture Model

Note

Specifications and programming information for Microsoft 32-bit TCP/IP are included in the Windows NT Device Driver Kit (DDK). The Transport Driver Interface (TDI) and the Network Driver Interface Specification (NDIS) are public specifications available from Microsoft.


Network Driver Interface Specification

Microsoft networking protocols (including TCP/IP) communicate with network card drivers using the Network Driver Interface Specification (NDIS). Windows NT Server version 4.0 uses NDIS version 4.0. The following figure illustrates the NDIS interface and the layers below the NDIS interface.

Figure 6.2 NDIS Interface

The NDIS interface (Ndis.sys) provides basic services used by the protocol modules. The protocol driver uses the NDIS interface to send raw data packets over a network device and to receive notification of incoming packets received by the NIC. NDIS allows the protocol components to function independently of the NIC.

Any NDIS-compliant protocol driver can communicate with any NDIS-compliant NIC.


Network Adapter Card Bindings

The NDIS layer supports binding, a process that establishes the communication channel between a protocol driver (such as TCP/IP) and a network card, in the following ways:

  • Multiple protocol drivers of different types binding to a single NIC driver
  • A single protocol driver binding to multiple NIC drivers

The NDIS specification describes the communications technique known as multiplexing, which allows transmitting a number of separate signals simultaneously over a single channel or line and which supports the different ways of binding a protocol driver and network card.

To improve networking performance, you can manually change the default bindings on a computer running under Windows NT by using the Bindings tab in the Control Panel—Network dialog box. You can choose to disable a binding, enable a binding, or redefine the default binding search order.


Media Access Control Layer

Because the NDIS interface handles raw packets, the protocol stack is normally responsible for building each frame, including Media Access Control (MAC) layer headers. This means that the protocol stack must explicitly support each media type. Microsoft 32-bit TCP/IP for Windows NT versions 4.0 and 3.5x provides support for:

  • Ethernet (and 802.3 SNAP)
  • FDDI
  • Token Ring (802.5)
  • ARCNET
  • WAN (switched virtual circuit wide area media, such as ISDN, X.25, and dial-up or dedicated asynchronous lines)

In addition, there are now asynchronous transfer mode (ATM) adapters available for Windows NT. The drivers for these adapters use "LAN emulation" to appear to the protocol stack as a supported media type, such as Ethernet.


Link Layer

Link layer functionality is divided between the combination (binding) of the NIC driver and the low-level protocol stack driver. The binding of the NIC driver and low-level protocol stack driver creates filters based on the destination MAC address of each frame. Normally, the hardware filters out all incoming frames except those containing one of the following destination addresses:

  • The address of the adapter
  • The IP broadcast address (255.255.255.255)
  • Multicast addresses which a protocol driver on this host has registered interest in by using a fundamental NDIS primitive command

Because this first filtering decision is made by the hardware, all frames not meeting the filter criteria are discarded by the NIC without any CPU processing. All frames (including broadcasts) that do pass the hardware filter are passed up to the NIC driver through a hardware interrupt.

A NIC driver is software on the local computer, and any frames that reach the NIC require some CPU time to process. The NIC driver brings the frame into system memory from the NIC. Then the frame is passed up to the appropriate bound transport drivers, in this case, TCP/IP. The NDIS specification provides more detail on this process.

Most NICs can be selectively configured in a non-selective mode. A NIC in non-selective mode does not perform any address filtering on frames that appear on the media. Instead, it passes upward every frame that passes the cyclic redundancy check (CRC). This feature is used by some protocol analysis software¾for example, Microsoft Network Monitor.

Frames are passed upward to all bound transport drivers, in the order of the binding. By default, the binding order is the alphabetical order of their key names in the Registry.

As a frame traverses a network or series of networks, the source MAC address is always that of the NIC that placed it on the media, and the destination MAC address is that of the NIC that is intended to pull it off the media. This means that in a routed network, the source and destination MAC addresses change with each "hop" through a network-layer device (router).


Maximum Transfer Unit

Each media type has a maximum frame size that cannot be exceeded. The link layer is responsible for discovering this maximum transfer unit (MTU) and reporting it to the protocols above. NDIS drivers can be queried for the local MTU by the protocol stack. The upper layer protocols, such as TCP, use the MTU to automatically optimize packet sizes for each media. See the section "Internet Control Message Protocol" later in this chapter for related information about path maximum transfer unit (PMTU) discovery.

If a NIC driver such as an ATM driver is using LAN-emulation mode, it may report that it has an MTU higher than what is expected for that media type. For example, it may emulate Ethernet but report an MTU of 9180 bytes. Windows NT accepts and uses the MTU size reported by the adapter even when it exceeds the normal MTU for a given media type.


Core Protocol Stack Components

The following figure illustrates the core protocol stack components in the Tcpip.sys driver which exists between the NDIS and TDI interfaces.

Figure 6.3 Core Protocol Stack Components


Address Resolution Protocol

Address Resolution Protocol (ARP) performs IP address-to-MAC-address resolution for outgoing packets. As each outgoing IP datagram is encapsulated into a frame, source and destination MAC addresses must be added. Determining the destination MAC address for each frame is the responsibility of ARP.

ARP compares the destination IP address on every outbound IP datagram to the ARP cache for the NIC which that frame will be sent over. If there is a matching entry, then the MAC address is retrieved from the cache. If not, ARP broadcasts an ARP Request Packet onto the local subnet, requesting that the owner of the IP address in question reply with its MAC address. If the packet is going through a router, ARP resolves the MAC address for that next-hop router rather than for the final destination host. When an ARP reply is received, the ARP cache is updated with the new information, and it is used to address the packet at the link layer.

ARP Cache

You can view, add, or delete entries in the ARP cache using the arp utility (see the following examples). Entries added manually are static, and do not get aged out of the cache like dynamic entries do.

To view the ARP cache, type the following command; you will get results similar to those in the following example:

C:\>arp -a Interface: 172.16.112.123 Internet Address Physical Address Type 172.16.112.1 00-00-0c-1a-eb-c5 dynamic 172.16.112.124 00-dd-01-07-57-15 dynamic Interface: 172.16.113.190 Internet Address Physical Address Type 172.16.113.138 00-20-af-1d-2b-91 dynamic

In these examples, the computer is multihomed, meaning that it has multiple NICs, so there is a separate ARP cache for each interface. The arp-s command can be used to add a static entry to the ARP cache used by the second interface, for the host whose IP address is 172.16.90.32 and whose NIC address is 00608C0E6C6A, as shown in the following example:

C:\>arp -s 172.16.90.32 00-60-8c-0e-6c-6a 172.16.48.190 C:\>arp -a Interface: 172.16.112.123 Internet Address Physical Address Type 172.16.112.1 00-00-0c-1a-eb-c5 dynamic 172.16.112.124 00-dd-01-07-57-15 dynamic Interface:172.16.48.190 Internet Address Physical Address Type 172.16.80.138 00-20-af-1d-2b-91 dynamic 172.16.90.32 00-60-8c-0e-6c-6a static

ARP Cache Aging

Windows NT versions 4.0 and 3.5x adjust the size of the ARP cache automatically. Entries are aged out of the ARP cache if they are not used by any outgoing datagrams for two minutes. Entries that are being referenced get aged out of the ARP cache after 10 minutes. Entries added manually are not aged out of the cache. A new registry parameter, ArpCacheLife, was added to allow more administrative control over aging. This parameter is described in online Registry Help.

Entries can be deleted from the cache using arp -d as shown next:

C:\>arp -d 172.16.90.32 C:\>arp -a Interface: 172.16.112.123 Internet Address Physical Address Type 172.16.112.1 00-00-0c-1a-eb-c5 dynamic 172.16.112.124 00-dd-01-07-57-15 dynamic Interface: 172.16.112.190 Internet Address Physical Address Type 172.16.112.138 00-20-af-1d-2b-91 dynamic

ARP will queue one outbound IP datagram to a given destination address while that IP address is being resolved to a MAC address. If a UDP – based program sends multiple IP datagrams to a single destination address without any pauses between them, some of the datagrams may be dropped if there is no ARP cache entry already present.


Internet Protocol

Internet Protocol (IP) is the "mailroom" of the TCP/IP stack, where packet sorting and delivery takes place. At this layer, each incoming or outgoing packet is known as a datagram. Each IP datagram bears the source IP address of the sender and the destination IP address of the intended recipient. Unlike the MAC addresses, the IP addresses in a datagram remain the same throughout a packet's journey across an internetwork. The following sections describe the IP layer functions.

Routing

Routing is the primary function of IP. Datagrams are handed to the IP protocol from UDP and TCP above, and from the NIC(s) below. Each datagram is labeled with a source and destination IP address. The IP protocol examines the destination address on each datagram, compares it to a locally maintained route table, and decides what action to take. There are three possibilities for each datagram:

  • It can be passed up to a protocol layer above IP on the local host.
  • It can be forwarded by using one of the locally attached NICs.
  • It can be discarded.

The route table maintains four different types of routes. They are listed here in the order in which they are searched for a match:

1. Host (a route to a single, specific destination IP address)

2. Subnet (a route to a subnet)

3. Network (a route to an entire network)

4. Default (used when there is no other match)

You can view the route table from the command prompt, as shown in the following example of the command and its results.

C:\>route print
Network Address | Netmask | Gateway Address | Interface | Metric
0.0.0.0 | 0.0.0.0 | 172.16.112.1 | 172.16.112.123 | 1
127.0.0.0 | 255.0.0.0 | 127.0.0.1 | 127.0.0.1 | 1
172.16.112.0 | 255.255.255.0 | 172.16.112.123 | 172.16.112.123 | 1
172.16.112.123 | 255.255.255.255 | 127.0.0.1 | 127.0.0. | 1
172.16.112.255 | 255.255.255.255 | 172.16.112.123 | 172.16.112.123 | 1
224.0.0. | 224.0.0.0 | 172.16.112.123 | 172.16.112.123 | 1
255.255.255.255 | 255.255.255.255 | 172.16.112.123 | 172.16.112.123 | 1

The preceding route table is for a computer with the class C IP address 172.16.112.123. It contains seven entries, as follows:

  • The first line, to address 0.0.0.0, is the default route.
  • The second line is the loopback address, 127.0.0.0.
  • The third line is a network route, for the network 172.16.112. The local interface is specified as the path to this network.
  • The fourth line is a host route for the local host. Note that it specifies the loopback address, which makes sense because a datagram bound for the local host should be handled internally.
  • The fifth line is the subnet broadcast address (again specifying the local interface).
  • The sixth line is the IP multicast address.
  • The seventh line is for limited broadcast address.

On this host, if a packet is sent to 172.16.112.122, the table is first scanned for a host route (not found), then for a subnet route (not found), then for a network route (that is found). The packet is sent by using the local interface 172.16.112.123. If a packet is sent to 172.17.1.1, the same search is used, and no host, subnet, or network route is found. In this case, the packet is directed to the default gateway, by inserting the MAC address of the default gateway into the destination MAC address field.

The route table is maintained automatically in most cases. When a host initializes, entries for the local network(s), loopback, multicast, and configured default gateway are added. More routes may appear in the table as the IP layer learns of them. For example, a computer may receive a message from the default gateway that indicates (using ICMP, as explained later) a better route to a specific network, subnet, or host. Routes also may be added manually by using the route command. In Windows NT versions 4.0 and 3.5x, the -p (persistent) switch can be used with the route command to specify permanent routes. Permanent routes are stored in the Registry under:

HKEY_LOCAL_COMPUTER\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ PersistentRoutes

Note In Windows NT version 3.5, manually-added routes were treated as temporary files and the routes were deleted from the table when the computer was restarted.

Most routers use a protocol such as RIP (Routing Information Protocol) or OSPF (Open Shortest Path First) to exchange routing tables with each other.

Multi-Protocol Router

The Multi-Protocol Router (MPR) in Windows NT consists of the following:

  • Routing Information Protocol (RIP) for TCP/IP
  • RIP for Internetwork Packet Exchange (IPX)
  • Boot Protocol (BOOTP) relay agent for DHCP

Routers use RIP to dynamically exchange routing information. Windows NT routes the RIP protocols and dynamically exchanges routing information with other routers running the RIP protocol.

The Windows NT router uses the BOOTP relay agent to forward DHCP requests to DHCP servers on other subnets. This allows one DHCP server to service multiple IP subnets.

Note By default, computers running under Windows NT do not behave as routers. You must install MPR after installing TCP/IP on your computer. MPR is included with Windows NT Server and Windows NT Workstation version 4.0. MPR for Windows NT version 3.51 is available from ftp.microsoft.com, and is included with Service Pack 3 and later under the "MPR" directory. Windows NT version 3.5 or earlier, when used as a router, does not include support for RIP.

Routing for Multiple Logical Subnets

When running multiple logical subnets on the same physical network, use the following command to tell IP to treat all subnets as local and to use ARP directly for the destination:

route add 0.0.0.0 MASK 0.0.0.0 <my local ip address>

Thus, packets destined for "non-local" subnets will be transmitted directly onto the local media instead of being sent to a router. In essence, the local interface card can be designated as the default gateway. This might be useful where several class "C" networks are being used on one physical network with no router to the outside world.

Duplicate IP Address Detection

Duplicate address detection is an important feature. When the stack is first initialized, a "gratuitous" ARP Request is broadcast for the IP address(es) of the local host. If another computer replies, the IP address is already in use. When this happens, the Windows NT computer will still start; however, IP on the offending interface is disabled, a system log entry is generated, and a popup error message is displayed. If the computer that is "defending" the address is also a Windows NT computer, a system log entry is generated and a popup error message is displayed there; however, its interface will continue to operate. After transmitting the ARP reply, the "defending" computer ARPs for its own address again so that other hosts on the network will maintain the correct mapping for the address in their ARP caches.

A computer using a duplicate IP address may be started while it is not attached to the network, in which case no conflict would be detected at that point. However, if it is then plugged into the network, the first time that it ARPs for another IP address, any Windows NT computer with a conflicting address will detect the conflict. The computer detecting the conflict will display a popup error message and log a detailed event in the system log. The following is a sample event log entry:

** The system detected an address conflict for IP address 172.16.48.123 with
the system having network hardware address 00:DD:01:0F:7A:B5. Network operations
on this system may be disrupted as a result. **

Multihoming

When a computer is configured with more than one IP address, it is known as a multihomed computer. The different types of multihoming are:

  • Multiple IP addresses per NIC.

Five addresses per card may be configured using Control Panel; however, more may be added in the Registry. For details, see the IPAddress registry parameter in online Registry Help.

NetBT (NetBIOS over TCP/IP per RFC 1001/1002) binds to only one IP address per interface card. When a NetBIOS name registration is sent, it contains the first IP address in the list of addresses assigned to the NIC.

  • Multiple NICs per physical network.

No restrictions other than hardware.

  • Multiple networks and media types.

No restrictions other than hardware and media support as described in the section "Network Driver Interface Specification" earlier in this chapter.

Note

Under Windows NT version 3.51, NetBT did not bind to a NIC that had more than 16 to 20 IP addresses associated with it.

When an IP datagram is sent from a multihomed host, it will be handed down to the interface card with the best apparent route to the destination. Accordingly, the datagram may bear the source IP address of one interface in the multihomed host, yet be placed on the media by a different NIC. The source MAC address on the frame will be that of the NIC that actually transmitted the frame onto the media, and the source IP address will be the one that the sending application sourced it from, not necessarily one of those associated with the sending NIC in the configuration screens in the network control panel.

Routing problems may arise when a computer is multihomed with NICs attached to disjoint networks (networks that are separate from and unaware of each other, such as one connected by using RAS). In this scenario, it is often necessary to set up static routes to remote networks.

More details on name registration and resolution with multihomed computers are provided in the section "NetBIOS over TCP/IP" later in this chapter.

Classless Interdomain Routing

Classless Interdomain Routing (CIDR), also known as supernetting, can be used to consolidate several class C network addresses into one logical network. CIDR is described in RFC 1518/1519. To use supernetting, the IP network addresses that are to be combined must share the same high-order bits, and the subnet mask is "shortened" to take bits away from the network portion of the address and add them to the host portion.

This is best explained with an example. The class C network addresses 172.16.16.0, 172.16.32.0, and 172.16.48.0 can be combined by using a subnet mask of 255.255.252.0 for each:

NET 172.16.16 (1010 1100 . 0001 0000 . 0010 0000.0000 0000) NET 172.16.32 (1010.1100 . 0001.0000 . 0010.0000.0000 0000) NET 172.16.48 (1010.1100 . 0001.0000 . 0011.0000.0000 0000) MASK 255.255.252.0 (1111 1111 . 1111 1111 . 1111 1100.0000 0000)

When routing decisions are made, only the bits covered by the subnet mask are used, thus making these addresses all appear to be part of the same network for routing purposes. Any routers in use must also support CIDR and may require special configuration.

IP Multicasting

IP multicasting is used to provide efficient multicast services to clients that may not be located on the same network segment. Windows Sockets programs can join a multicast group. For more information, see the section "Using IP Multicasts with Windows Sockets Programs," later in this chapter.

Windows NT versions 4.0 and 3.5x are level-2 (send and receive) compliant with RFC 1112. IGMP is the protocol used to manage IP multicasting.


Internet Control Message Protocol

Internet Control Message Protocol (ICMP) is a maintenance protocol specified in RFC 792 and is normally considered to be part of the IP layer. ICMP messages are encapsulated within IP datagrams, so they can be routed throughout an internetwork. ICMP is used by Windows NT to:

  • Build and maintain route tables.
  • Assist in Path Maximum Transfer Unit (PMTU) discovery.
  • Diagnose problems (using the utilities ping and tracert).
  • Adjust flow control to prevent link or router saturation.

Maintaining Route Tables

When a Windows NT computer is initialized, the route table normally contains only a few entries. One of those specifies a default gateway. Datagrams that have a destination IP address with no match in the route table are sent to the default gateway.

However, because routers share information about network topology with each other, the default gateway may know of a better route to a given address. When this is the case, upon receiving a datagram that could be taking the better path, the router forwards the datagram normally, then advises the sender of the better route using an ICMP redirect message.

These messages can specify redirection for one host, a subnet, or for an entire network. When a Windows NT computer receives an ICMP redirect, a check is performed to be sure that it came from the first-hop gateway in the current route, and that the gateway is on a directly connected network. If so, the route table is adjusted accordingly.

If the ICMP redirect did not come from the first-hop gateway in the current route, or if that gateway is not on a directly connected network, then the ICMP redirect is ignored.

Path Maximum Transfer Unit Discovery

TCP uses Path Maximum Transfer Unit (PMTU) discovery. The mechanism relies on ICMP destination unreachable messages.

Using ICMP to Diagnose Problems

The ping utility is used to send ICMP echo requests to an IP address, and wait for ICMP echo responses. Ping reports on the number of responses received and the time interval between sending the request and receiving the response. There are many different options that can be used with the ping utility.

Tracert is a route-tracing utility that can be very useful. Tracert works by sending ICMP echo requests to an IP address, while incrementing the time-to-live (TTL) field in the IP header by one starting at 1, and analyzing the ICMP errors that get returned. Each succeeding echo request should get one hop further into the network before the TTL field reaches 0 and an ICMP Time Exceeded error is returned by the router attempting to forward it. Tracert simply prints out an ordered list of the routers in the path that returned these error messages. If the -d switch is used (meaning do not do a DNS lookup on each IP address), then the IP address of the near-side interface of the routers is reported.

Adjusting Flow Control by Using ICMP

If a host is sending datagrams to another computer at a rate that is saturating the routers or links between them, it may receive an ICMP Source Quench message asking it to slow down. The TCP/IP stack in Windows NT honors a source quench message as long as it contains the header fragment of one of its own datagrams from an active TCP connection. If a Windows NT computer is being used as a router, and it is unable to forward datagrams at the rate they are arriving, it drops any datagrams that cannot be buffered but does not send ICMP source quench messages to the senders.


Internet Group Management Protocol

Windows NT versions 4.0 and 3.5x provide level-2 (full) support for IP multicasting as specified in RFC 1112. The introduction to RFC 1112 provides a good overall summary of IP multicasting. The text reads:

IP multicasting is the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams, i.e., the datagram is not guaranteed to arrive intact at all members of the destination group or in the same order relative to other datagrams.

The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it.

A host group may be permanent or transient. A permanent group has a well-known, administratively assigned IP address. It is the address, not the membership of the group, that is permanent; at any time a permanent group may have any number of members, even zero. Those IP multicast addresses that are not reserved for permanent groups are available for dynamic assignment to transient groups that exist only as long as they have members.

Internetwork forwarding of IP multicast datagrams is handled by "multicast routers" that may be co-resident with, or separate from, Internet gateways. A host transmits an IP multicast datagram as a local network multicast that reaches all immediately-neighboring members of the destination host group. If the datagram has an IP time-to-live greater than 1, the multicast router(s) attached to the local network take responsibility for forwarding it towards all other networks that have members of the destination group. On those other member networks that are reachable within the IP time-to-live, an attached multicast router completes delivery by transmitting the datagram as a local multicast.

IP/ARP Extensions for IP Multicasting

To support IP multicasting, an additional route is defined. The route (added by default) specifies that if a datagram is being sent to a multicast host group, it should be sent to the IP address of the host group by using the local interface card, not forwarded to the default gateway. The following route (which can be seen with the route print command) illustrates this:

Network Address | Netmask | Gateway Address | Interface | Metric
224.0.0.0 | 224.0.0.0 | 172.16.80.138 | 172.16.80.138 | 1

Host group addresses are easily identified, because they are from the class D range, 224.0.0.0 to 239.255.255.255. These IP addresses all have "1110" as their high-order 4 bits.

To send a packet to a host group using the local interface, the IP address must be resolved to a MAC address. From RFC 1112:

An IP host group address is mapped to an Ethernet multicast address by placing the low-order 23 bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). Because there are 28 significant bits in an IP host group address, more than one host group address may map to the same Ethernet multicast address.

For example, a datagram addressed to the multicast address 225.0.0.5 would be sent to the (Ethernet) MAC address 01-00-5E-00-00-05. This MAC address is formed by the junction of 01-00-5E and the 23 low-order bits of 225.0.0.5 (00-00-05).

Because more than one host group address might map to the same Ethernet multicast address, the NIC may indicate up some multicasts for a host group for which no local programs have registered interest. These extra multicasts are discarded.

Finally, the protocol stack must provide a means of joining and leaving host groups.

Using IP Multicasts with Windows Sockets Programs

IP multicasting is currently supported only on AF_INET sockets of type SOCK_DGRAM. By default, IP multicast datagrams are sent with a time-to-live (TTL) of 1. The setsockopt() call can be used by a program to specify a TTL. By convention, multicast routers use TTL thresholds to determine how far to forward datagrams. The following table lists the TTL thresholds that are used to determine how far to forward multicast datagrams.

Table 6.1 Time-to-Live Thresholds for Windows Sockets Programs

TTL Threshold | Description
TTL equal to 0 | Restricted to the same host
TTL equal to 1 | Restricted to the same subnet
TTL equal to 32 | Restricted to the same site
TTL equal to 64 | Restricted to the same region
TTL equal to 128 | Restricted to the same continent
TTL equal to 255 | Unrestricted in scope

Use of IGMP by Windows NT Components

At the time of this writing. the only Windows NT component that uses IGMP is Windows Internet Name Service (WINS), which attempts to locate replication partners by using multicasting.


Transmission Control Protocol

Transmission Control Protocol (TCP) provides a connection-based, reliable, byte-stream service to programs. Microsoft networking relies upon the TCP transport for logging on, file and print sharing, replication of information between domain controllers, transfer of browse lists, and other common functions. TCP can only be used for one-to-one communications. TCP uses a checksum on both the headers and data of each segment to reduce the chance of network corruption going undetected.

Size Calculation of the TCP Receive Window

The TCP receive window size is the amount of receive data (in bytes) that can be buffered at one time on a connection. The sending host can send only that amount of data before waiting for an acknowledgment (ACK) and window update from the receiving host.

The TCP/IP stack is designed to self-tune itself in most environments. Instead of using a hard-coded default receive window size, TCP adjusts to even increments of the maximum segment size (MSS) negotiated during connection setup.

Matching the receive window to even increments of the MSS increases the percentage of full-sized TCP segments used during bulk data transmission. The following defaults are used for receive window size: TCPWindowSize = 8K rounded up to the nearest MSS increment for the connection; if that is not at least 4 times the MSS, then it's adjusted to 4 times the MSS, with a maximum size of 64K.

Note

The maximum window size is 64K because the field in the TCP header is 16 bits in length. RFC 1323 describes a TCP window scale option that can be used to obtain larger receive windows; however Windows NT TCP/IP does not yet implement that option.

For Ethernet, the window will normally be set to 8760 bytes (8192 rounded up to six 1460-byte segments); for 16/4 Token Ring or FDDI, it will be around 16K. These are default values and it's not generally advisable to alter them; however, you can either change the registry parameter TcpWindowSize to globally change the setting for the computer, or use the setsockopt() Windows Sockets call to change the setting on a per-socket basis.

Delayed Acknowledgments

Per RFC 1122, TCP uses delayed acknowledgments to reduce the number of packets sent on the media. The Microsoft stack takes a common approach to implementing delayed acknowledgments. The following conditions cause an acknowledgment to be sent as data is received by TCP on a given connection:

  • No ACK is sent for the previous received segment.
  • Segment is received, and no other segment arrives within 200ms for that connection.

In summary, normally an ACK is sent for every other TCP segment received on a connection, unless the delayed ACK timer (200ms) expires. There is no configuration parameter to disable delayed ACKs.

PMTU Discovery

RFC 1191 describes PMTU discovery. When a connection is established, the two hosts involved exchange their TCP MSS values. The smaller of the two MSS values is used for the connection. The MSS for a computer is usually the MTU at the link layer minus 40 bytes for the IP and TCP headers.

When TCP segments are destined to a non-local network, the "don't fragment" bit is set in the IP header. Any router or media along the path may have an MTU that differs from that of the two hosts.

If a media is encountered with an MTU that is too small for the IP datagram being routed, the router will attempt to fragment the datagram accordingly. Upon attempting to do so, it will find that the "don't fragment" bit in the IP header is set. At this point, the router should inform the sending host with an ICMP destination unreachable message that the datagram can't be forwarded further without fragmentation. Most routers will also specify the MTU that is allowed for the next hop by putting the value for it in the low-order 16 bits of the ICMP header field that is labeled "unused" in the ICMP specification. See RFC 1191, section 4, for the format of this message.

Upon receiving this ICMP error message, TCP adjusts its MSS for the connection to the specified MTU minus the TCP and IP header size, so that any further packets sent on the connection will be no larger than the maximum size that can traverse the path without fragmentation. The minimum MTU permitted by RFCs is 68 bytes, and this limit is enforced by Windows NT TCP.

Some non-compliant routers may silently drop IP datagrams that cannot be fragmented, or may not correctly report their next-hop MTU. If this occurs, it may be necessary to make a configuration change to the PMTU detection algorithm. There are two registry changes that can be made to the TCP/IP stack to find and correct errors caused by these problematic routers:

  • EnablePMTUBHDetect: adjusts the PMTU discovery algorithm to attempt to detect these "black hole" routers. Black hole detection is disabled by default.
  • EnablePMTUDiscovery: completely enables or disables the PMTU discovery mechanism. When PMTU discovery is disabled, an MTU of 576 bytes is used for all non-local destination addresses. PMTU discovery is enabled by default.

The PMTU between two computers can be discovered by manually using ping with the -f (do not fragment) switch as follows:

ping -f -n <number of pings> -l <size> <destination ip address>

In the preceding example, the size parameter can be varied until the MTU is found. Note that the size parameter used by ping is the size of the data buffer to send, not including headers. The ICMP header consumes 8 bytes, and the IP header would normally be 20 bytes. In the following case (Ethernet), the link layer MTU is the maximum-sized ping buffer plus 28, or 1500 bytes:

C:\temp>ping -f -n 1 -l 1472 172.16.48.03 Pinging 172.16.48.03 with 1472 bytes of data: Reply from 172.16.48.03: bytes=1472 time<10ms TTL=30 C:\temp>ping -f -n 1 -l 1473 172.16.48.03 Pinging 172.16.48.03 with 1473 bytes of data: Packet needs to be fragmented but DF set

In the preceding example, the router returned an ICMP error message which ping interpreted for us. If the router had been a "black hole" router, the ping would simply not be answered once its size exceeded the MTU that the router could handle. Ping can be used in this manner to detect such a router.

A sample ICMP destination unreachable error message is as follows:

+ FRAME: Base frame properties + FDDI: Length = 77 + LLC: UI DSAP=0xAA SSAP=0xAA C + SNAP: ETYPE = 0x0800 + IP: ID = 0x0; Proto = ICMP; Len: 56 ICMP: Destination Unreachable, Destination: 172.16.112.125 ICMP: Packet Type = Destination Unreachable ICMP: Unreachable Code = Fragmentation Needed, DF Flag Set ICMP: CheckSum = 0x8ABF ICMP: Data: Number of data bytes remaining = 28 (0x001C) 00000: 50 00 60 8C 14 C7 0E 00 00 0C 1A EB C0 AA AA 03 00010: 00 00 00 08 00 45 00 00 38 00 00 00 00 FF 01 D3 00020: 36 C7 C7 2C 01 C7 C7 2C FE 03 04 8A BF 00 00 05 00030: C7 45 00 05 F8 55 24 40 00 1F 01 1B D7 C7 C7 2C 00040: FE C7 C7 28 7D 08 00 00 75 01 00 63 00

Network Monitor did not parse the MTU suggestion in this frame, but it is shown underlined in the hex portion of the trace. This error is generated by using ping -f -l 2000 on an FDDI-based host to send a large datagram through a router to an Ethernet host. When the router tried to place the large frame onto the Ethernet segment, it found that fragmentation is not allowed, and so it returned the error message indicating the largest datagram that could be forwarded is 0x5c7, or 1479 bytes.

Dead Gateway Detection

Microsoft TCP/IP provides dead gateway detection. Dead gateway detection allows TCP to detect failure of the default gateway and to make an adjustment to the IP routing table to use another default gateway.

Dead gateways are detected by using TCP retries. Microsoft TCP/IP stack uses the triggered reselection method as described in RFC 816.

TCP will attempt to send a packet to the default gateway configured on a computer until it receives an acknowledgment or until one-half of the TcpMaxDataRetransmissions registry parameter is reached. If no response is received from the default gateway and multiple gateways are configured on the computer, TCP requests that IP switch to the next default gateway in the list.

Note

If the computer running Windows NT Server or Windows NT Workstation is a DHCP client, the default gateway is automatically configured on the computer.

To add additional default gateways or to configure gateways for non-DHCP configured computers

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network, and then click the Protocol tab.

3. Under Network Protocols, click TCP/IP, and then click Properties.

4. If necessary, click the IP Address tab, and then click Advanced.

5. You can add additional gateways under Gateway in the Advanced IP Addressing dialog box.

IP utilities such as ping do not trigger the dead gateway detection process. They use the current default gateway. If TCP detects a dead gateway and selects a new one, the IP utilities will then function using the new gateway. By default, dead gateway detection is set to "on" when you configure a computer running under Windows NT with the IP address of more than one gateway.

Retransmission Behavior

TCP starts a retransmission timer when each outbound segment is handed down to IP. If no acknowledgment has been received for the data in a given segment before the timer expires, then the segment is retransmitted, up to the value of the TcpMaxDataRetransmissions registry parameter. The default value for this parameter is 5.

The retransmission timer is initialized to three seconds when a TCP connection is established; however it is adjusted "on the fly" to match the characteristics of the connection using smoothed round trip time (SRTT) calculations as described in RFC 793. The timer for a given segment is doubled after each retransmission of that segment. Using this algorithm, TCP tunes itself to the "normal" delay of a connection. TCP connections over high-delay links will take much longer to time out than those over low-delay links.

Note

Adding [1] to the registry parameter TcpMaxDataRetransmissions approximately doubles the total retransmission time-out period for all connections.

The following trace clip shows the retransmission algorithm for two hosts connected over Ethernet on the same subnet. An FTP file transfer was in progress when the receiving host was disconnected from the network. Since the SRTT for this connection is very small, the first retransmission is sent after about one-half second. The timer is then doubled for each of the retransmissions that followed. After the fifth retransmission, the timer is once again doubled, and if no acknowledgment is received before it expires, the transfer is aborted.

Delta | Source Ip | Dest Ip | Pro | Flags | Description
0.000 | 172.16.90.32 | 172.16.80.138 | TCP | .A.... | , len: 1460, seq: 8043781, ack: 8153124, win: 8760
0.521 | 172.16.90.32 | 172.16.80.138 | TCP | .A.... | , len: 1460, seq: 8043781, ack: 8153124, win: 8760
1.001 | 172.16.90.32 | 172.16.80.138 | TCP | .A.... | , len: 1460, seq: 8043781, ack: 8153124, win: 8760
2.003 | 172.16.90.32 | 172.16.80.138 | TCP | .A.... | , len: 1460, seq: 8043781, ack: 8153124, win: 8760
4.007 | 172.16.90.32 | 172.16.80.138 | TCP | .A.... | , len: 1460, seq: 8043781, ack: 8153124, win: 8760
8.130 | 172.16.90.32 | 172.16.80.138 | TCP | .A.... | , len: 1460, seq: 8043781, ack: 8153124, win: 8760

TCP Keepalive Messages

A TCP keepalive packet is simply an ACK with the sequence number set to one less than the current sequence number for the connection. A computer receiving one of these ACKs should respond with an ACK for the current sequence number. Keepalives can be used to verify that the computer at the remote end of a connection is still available. TCP keepalives can be sent once every KeepAliveTime (defaults to 7,200,000 milliseconds or two hours), if no other data or higher level keepalives have been carried over the TCP connection. If there is no response to a keepalive, it is repeated once every KeepAliveInterval seconds. KeepAliveInterval defaults to one second. NetBT connections, such as those used by many Microsoft networking components, send NetBIOS keepalives more frequently, and so normally no TCP keepalives will be sent on a NetBIOS connection. TCP keepalives are disabled by default, but Windows Sockets programs may enable them using setsockopt().

Slow Start Algorithm and Congestion Avoidance

When a connection is initially established, TCP processes at a slow rate to assess the bandwidth of the connection and to avoid overflowing the receiving host or any other devices or links in the path. The send window is set to two TCP segments.

If the TCP/IP segments are acknowledged, the send window is incremented again, and so on until the amount of data being sent per burst reaches the size of the receive window on the remote host. At that point, the slow start algorithm is no longer in use and flow control is governed by the receive window on the remote host.

However, at any time during transmission, congestion could still occur on a connection. If this happens (evidenced by the need to retransmit), a congestion avoidance algorithm is used to reduce the send window size temporarily, and then to slowly increment the send window back towards the receive window size.

Note

Slow start and congestion avoidance are discussed in RFC 1122.

Silly Window Syndrome

Silly Window Syndrome (SWS) is described in RFC 1122 as follows:

In brief, SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data [TCP:5]. The result can be a stable pattern of sending tiny data segments, even though both sender and receiver have a large total buffer space for the connection.

TCP/IP for Windows NT implements SWS avoidance per RFC 1122 by not sending more data until there is a sufficient window size advertised by the receiving end to send a full segment. It also implements SWS on the receive end of a connection by not opening the receive window in increments of less than a TCP segment.

Nagle Algorithm

TCP/IP for Windows NT Server and Windows NT Workstation implements the Nagle algorithm described in RFC 896. The purpose of this algorithm is to reduce the number of "tiny" segments sent, especially on high-delay (remote) links. The Nagle algorithm allows only one small segment to be outstanding at a time without acknowledgment. If more small segments are generated while awaiting the ACK for the first one, then these segments are coalesced into one larger segment. Any full-sized segment is always transmitted immediately, assuming there is a sufficient receive window available. The Nagle algorithm is effective in reducing the number of packets sent by interactive programs, such as Telnet, especially over slow links.

The following trace captured by using Microsoft Network Monitor shows the Nagle algorithm at work. The trace was captured by using PPP to dial up an Internet provider at 9600 bps. A Telnet (character-mode) session is established, then the "y" key is held down on the Windows NT Workstation. At all times, one segment is sent, and further "y" characters were held by the stack until an acknowledgment is received for the previous segment. In this example, three to four "y" characters were saved up each time and sent together in one segment. The Nagle algorithm resulted in a huge savings in the number of packets sent¾it is reduced by a factor of about three.

Source IP | Dest IP | Prot | Description
172.16.16.243 | 172.16.144.0 | TELNET | To Server From Port = 1901
172.16.144.0 | 172.16.16.243 | TELNET | To Client With Port = 1901
172.16.16.243 | 172.16.144.0 | TELNET | To Server From Port = 1901
172.16.144.0 | 172.16.16.243 | TELNET | To Client With Port = 1901
172.16.16.243 | 172.16.144.0 | TELNET | To Server From Port = 1901
172.16.144.0 | 172.16.16.243 | TELNET | To Client With Port = 1901

Each segment contained several of the "y" characters. Following is the first segment shown more fully parsed, and the data portion is pointed out in the hex at the bottom.

Time Source IP Dest IP Prot Description

0.644 172.16.48.1 172.16.112.0 TELNET To Server From Port = 1901 + FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0xEA83; Proto = TCP; Len: 43 + TCP: .AP..., len: 3, seq:1032660278, ack: 353339017, win: 7766, src: 1901 dst: 23 (TELNET) TELNET: To Server From Port = 1901 TELNET: Telnet Data D2 41 53 48 00 00 52 41 53 48 00 00 08 00 45 00 .ASH..RASH....E. 00 2B EA 83 40 00 20 06 F5 85 CC B6 42 53 C7 B5 .+..@. .....BS.. A4 04 07 6D 00 17 3D 8D 25 36 15 0F 86 89 50 18 ...m..=.%6....P. 1E 56 1E 56 00 00 79 79 79 .V.V..yyy ^^^ data

Windows Sockets programs can disable the Nagle algorithm for their connection(s) by setting the TCP_NODELAY socket option. However, this practice should be avoided unless absolutely necessary because it increases network usage. Some network programs may not perform well if their design does not take into account the effects of transmitting large numbers of small packets and the Nagle algorithm.

Throughput Considerations

TCP is designed to provide optimum performance over varying link conditions. Actual throughput for a link is dependent on a number of variables, but the most important factors are:

  • Link speed (bits per second that can be transmitted)
  • Propagation delay
  • Window size (amount of unacknowledged data that may be outstanding on a TCP connection)
  • Link reliability
  • Router congestion

TCP throughput calculation is discussed in detail in Chapters 20 through 24 of TCP/IP Illustrated, by W. Richard Stevens. The following are some key considerations:

  • The capacity of a pipe is (bandwidth * round-trip time). This is known as the bandwidth-delay product. If the link is reliable, for best performance the window size should be greater than or equal to the capacity of the pipe. The largest window size that can be specified is 65535 due to its 16-bit field in the TCP header. RFC 1323 describes a Window Scale option; however, it has not yet been implemented by Windows NT TCP.
  • Throughput will never exceed (window size / round-trip time).
  • If the link is unreliable (or badly congested) and packets are being dropped, using a larger window size may not improve throughput.
  • Propagation delay depends on the speed of light and latencies in transmission equipment, and so on.
  • Transmission delay depends on the speed of the media.
  • For a given path, propagation delay is fixed, but transmission delay depends on the packet size.
  • At low speeds, transmission delay is the limiting factor. At high speeds, propagation delay may become the limiting factor.

To summarize, Windows NT TCP/IP will adapt to most network conditions and dynamically provide the best throughput and reliability possible on a per-connection basis. Attempts at manual tuning are often counter-productive unless a qualified network engineer performs careful study of data flow.


User Datagram Protocol

User Datagram Protocol (UDP) provides a connectionless, unreliable transport service. It is often used for one-to-many communications, using broadcast or multicast IP datagrams. Because delivery of UDP datagrams is not guaranteed, programs using UDP must supply their own mechanisms for reliability if needed. Microsoft networking uses UDP for logon, browsing, and name resolution.

UDP and Name Resolution

UDP is used for (1) NetBIOS name resolution by using unicast to a NetBIOS name server (such as WINS) or subnet broadcasts, and (2) for DNS host name and IP address resolution. NetBIOS name resolution is accomplished over UDP port 137. DNS queries use UDP port 53. Because UDP itself does not guarantee delivery of datagrams, both of these services use their own retransmission schemes if they receive no answer to queries. Broadcast UDP datagrams are not usually forwarded over IP routers, and so NetBIOS name resolution in a routed environment requires a name server of some type, or the use of static database files.

Mailslots over UDP

Many NetBIOS programs use mailslot messaging. A 2nd class mailslot is a simple mechanism for sending a message from one NetBIOS name to another over UDP. Mailslot messages may be broadcast on a subnet, or may be directed to the remote computer. In order to direct a mailslot message to another computer, there must be some method of NetBIOS name resolution available. The WINS server running under Windows NT Server provides this service.


TCP/IP Security Filters

Security filtering for TCP/IP allows you to control the type of network traffic passed up the TCP/IP protocol stack to upper-layer protocols and programs. Security filters are one of the security mechanisms typically used on Internet servers.

TCP/IP security filters control the ports on which TCP connections and UDP datagrams are accepted (For more information ,see Appendix B, "Port Reference for MS TCP/IP.") The filters also control which IP protocol can be assessed by using raw sockets.

If TCP/IP security filters are configured on a computer running under Windows NT, incoming connection requests and datagrams are accepted or rejected based on the configured security filters. Outgoing connection requests and datagrams are not affected.

Security filters are configured separately for each network adapter to which TCP/IP is bound. Filters are applied to network traffic based on the adapter that received the traffic.

For specific information about configuring advanced TCP/IP security, see Microsoft TCP/IP Help.


NetBIOS over TCP/IP

The following TCP and UDP ports are used in NetBT, the Windows NT implementation of NetBIOS over TCP/IP.

  • UDP port 137 (name services)
  • UDP port 138 (datagram services)
  • TCP port 139 (session services)

NetBIOS over TCP/IP is specified by RFC 1001 and RFC 1002. The Netbt.sys driver is a kernel-mode component that supports the TDI interface. Services such as Windows NT Workstation and Windows NT Server services use the TDI interface directly, while traditional NetBIOS programs have their calls mapped to TDI calls by using the Netbios.sys driver. Using TDI to make calls to NetBT is a more difficult programming task, but can provide higher performance and freedom from historical NetBIOS limitations.

See the section "Network Application Interfaces" later in this chapter for more information about NetBIOS.


Transport Driver Interface

Microsoft developed the transport driver interface (TDI) to provide greater flexibility and functionality than provided by existing interfaces such as NetBIOS and Windows Sockets. The TDI interface is exposed by all Windows NT transport providers. The TDI interface specification describes the set of primitive functions by which transport drivers and TDI clients communicate, and the call mechanisms used for accessing them. Currently, the TDI Interface is kernel-mode only.

The Windows NT redirector and server both use TDI directly, rather than going through the NetBIOS mapping layer. By doing so, they are not subject to many of the restrictions imposed by NetBIOS, such as the 254 session limit.

TDI may be the most difficult to use of all the Windows NT network APIs. It is a simple conduit, so the programmer must determine the format and meaning of messages.

Note

More information on the TDI interface is available in the Windows NT Device Driver Kit (DDK).

The following features are part of the Windows NT implementation of TDI.

  • Support for all Windows NT transports excluding the DLC protocol
  • An open naming and addressing scheme
  • Message and stream mode data transfer
  • Asynchronous operation
  • Support for unsolicited indication of events
  • Extensibility¾clients can submit private requests to a transport driver that can process the requests
  • Support for limited use of standard kernel-mode I/O functions to send and receive data
  • 32-bit addressing and values


Network Application Interfaces

There are a number of ways that network programs can communicate by using the TCP/IP protocol stack. Some of them, such as named pipes, go through the network redirector, which is part of the Workstation service. Many older programs were written to the NetBIOS interface, which is supported by NetBIOS over TCP/IP. Windows Sockets is used in many programs.

The network application programming interfaces (APIs) discussed in this section are:

  • Windows Sockets
  • NetBIOS over TCP/IP


Windows Sockets Interface

Windows Sockets is an API used for sending and receiving data on a network. Originally designed as the top-level interface for TCP/IP network transport stacks, the Windows Sockets API provides a standard Windows interface to many transports with different addressing schemes, including, for example, TCP/IP and IPX.

Windows Sockets specifies a programming interface based on the "socket" interface from the University of California at Berkeley. It includes a set of extensions designed to take advantage of the message-driven nature of Microsoft Windows. Windows Sockets is an open, industry-standard specification and Microsoft is one member of the group that originally defined Windows Sockets.

There are many Windows Sockets programs available. A number of the utilities that ship with Windows NT are Windows Sockets – based; for example, the DHCP client/server program.

Note

Windows NT version 4.0 implements 32-bit Windows Sockets version 2.0. Earlier versions of Windows NT implemented 32-bit Windows Sockets version 1.1. See Appendix D, "Windows Sockets," for a list of Microsoft and other Internet sites from which you can receive Windows Sockets specifications.

Name and Address Resolution

Windows Sockets programs generally use the gethostbyname() call to resolve a host name to an IP address. The gethostbyname() call uses the following (default) name lookup sequence:

1. Check local computer host name.

2. Check the HOSTS file for a matching name entry.

3. If a DNS server is configured, query it.

4. If no match is found, try the NetBIOS name resolution.

Some programs use the gethostbyaddr() call to resolve an IP address to a host name. The gethostbyaddr() call uses the following sequence:

1. Check local computer host name.

2. Check the HOSTS file for a matching address entry.

3. If a DNS server is configured, query it.

4. If no match is found, send a NetBIOS Adapter Status Request to the IP address being queried, and if it responds with a list of NetBIOS names registered for the adapter, parse it for the computer name.

Support for IP Multicasting

The Windows Sockets API has been extended to provide support for IP multicasting. The extensions, and a sample program, party.exe, that illustrates usage, are available from ftp.microsoft.com. IP multicasting is currently supported only on AF_INET sockets of type SOCK_DGRAM.

The Backlog Parameter

Windows Sockets server programs generally create a socket and then use listen() to listen on it for connection requests. One of the parameters passed when calling listen() is the backlog of connection requests that the program would like Windows Sockets to queue for it.

Windows NT Server version 4.0 allows a backlog maximum of 200. Windows NT Workstation version 4.0 supports only a maximum allowable value of 5.

Note

Earlier versions of Windows NT based on the Windows Sockets 1.1 specification used the specified maximum allowable value (5) for backlog.

FTP or Web servers that are heavily used may benefit from increasing the backlog to a larger number than the default. Microsoft Internet Information Server allows the backlog parameter to be specified by using a registry setting.

PUSH Bit Interpretation

By default, Windows NT versions 4.0 and 3.5x complete a recv() call when:

  • Data arrives with the PUSH bit set.
  • The user recv() buffer is full.
  • 0.5 seconds have elapsed since any data arrived.

If a client program is run on a computer with a TCP/IP implementation that does not set the PUSH bit on sends, response delays may result. It's best to correct this on the client side; however, a configuration parameter (IgnorePushBitOnReceives) is added to Afd.sys to force it to treat all arriving packets as though the PUSH bit were set.


NetBIOS Interface

Network Basic Input/Output System (NetBIOS) defines a software interface and a naming convention, not a protocol. The NetBEUI protocol, introduced by IBM in 1985, provided a protocol for programs designed around the NetBIOS interface. However, NetBEUI is a small protocol with no networking layer and because of this, it is not a routable protocol suitable for medium-to-large intranets.

NetBIOS over TCP/IP (NetBT) provides the NetBIOS programming interface over the TCP/IP protocol, extending the reach of NetBIOS client/server programs to the WAN and providing interoperability with various other operating systems. NetBT and NetBIOS are illustrated in the following figure.

Figure 6.4 NetBIOS over TCP/IP (NetBT) Component

The Windows NT Workstation service, Server service, Browser, Messenger, and Netlogon services are all direct NetBT clients that use the TDI to communicate with NetBT. Windows NT also includes a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS programs and translates them to equivalent TDI primitives.

NetBIOS Names

The NetBIOS namespace is flat, meaning that all names within a network must be unique. NetBIOS names are 16 characters in length. Resources are identified by NetBIOS names that are registered dynamically when computers start, services start, or users log on. Names can be registered as unique (one owner) or as group (multiple owner) names. A NetBIOS Name Query is used to locate a resource by resolving the name to an IP address.

Microsoft networking components, such as Windows NT Workstation and Windows NT Server services, allow the first 15 characters of a NetBIOS name to be specified by the user or administrator, but reserve the 16th character of the NetBIOS name to indicate a resource type (00-FF hex). See Appendix G, "NetBIOS Names."

To identify the names registered on your local computer

1. Click Start, and then click Run.

2. In Open, type nbtstat -n.

NetBIOS Scope

NetBIOS Scope, also known as TCP/IP Scope, provides a method for adding a second element to the single-element NetBIOS computer name. The scope ID is a character string value that is appended to the NetBIOS name and is used for all NetBT communications from that computer. The character string can be multi-part¾for example, "mydomain.mycompany.com".

Note

Use of NetBIOS Scope is strongly discouraged if you are not already using it, or if you use Domain Name System (DNS) on your network.

By installation default, the NetBIOS Scope value is NULL. You can change the default value by entering a character string in the Scope ID on the WINS Address tab on the Microsoft TCP/IP Properties page. Note that the maximum length of the combined NetBIOS name and NetBIOS Scope ID is limited to 256 characters.

Note

NetBIOS Scope should not be confused with DHCP Scope, which defines the group of IP addresses that the DHCP server can lease to client computers.

The effect of using a NetBIOS Scope ID, other than the default NULL value, is to isolate a group of computers on the network that can communicate only with other computers that are configured with the identical NetBIOS Scope ID. Use NetBIOS Scope only when it is necessary to isolate a group of computers that cannot communicate with other computers on the intranet.

Once configured on the local computer, NetBIOS Scope is automatically attached to all NetBIOS commands on that local computer. In other words, NetBIOS programs started on a computer using NetBIOS Scope ID cannot "see" (receive or send messages) NetBIOS programs started by a process on a computer configured with a different NetBIOS Scope ID.

Several Windows NT-based programs, such as net logon and domain controller pass-through authentication, use NetBIOS names. Therefore, consider the effect of NetBIOS Scope ID if you decide to change the default NetBIOS Scope ID. Use the following guidelines:

1. All Windows NT Workstation, Windows NT Server, and Windows 95 computers in the same Windows NT domain that are using the same NetBIOS Scope ID can communicate and connect with each other.

2. However, no pass-through authentication can occur between domains that are configured with different NetBIOS Scope IDs. In other words, using NetBIOS Scope ID can break the trust between domains.

3. Users cannot log on to their assigned domain from Windows 95 and Windows NT Workstation computers if the scope on the computer is different from the NetBIOS Scope configured on the domain controller in the user's assigned domain.

4. Users cannot log on to any computer on which the configured NetBIOS scope is not the same as the NetBIOS Scope ID configured on the domain controller for the selected domain.

5. Users cannot connect, either by the command window or by using a program that issues a net use command, to a server whose NetBIOS Scope is different from the scope assigned to the domain controllers in the domain the user is logged on to, or the domain specified in the Connect dialog box.

NetBIOS Name Registration and Resolution

Windows NT versions 4.0 and 3.5x computers use several methods for locating NetBIOS resources:

  • NetBIOS name cache
  • NetBIOS name server
  • IP subnet broadcasts
  • Static LMHOSTS files
  • Static HOSTS files
  • DNS servers

Earlier implementations used only cache, broadcasts, and LMHOSTS files; however, in Windows NT versions 4.0 and 3.5x, a NetBIOS name server¾the WINS server¾was implemented, and modifications were made to allow NetBIOS programs to query the DNS namespace by appending configurable domain suffixes to a NetBIOS name.

NetBIOS name resolution order depends on the node type and computer configuration. The following node types are supported:

  • b-node — uses broadcasts for name registration and resolution.
  • p-node — uses only point-to-point name queries to a NetBIOS name server (in this case WINS servers) for name registration and resolution.
  • m-node — uses broadcasts for name registration; for name resolution, tries broadcasts first, but switches to p-node if no answer is received.
  • h-node — uses NetBIOS name server for both registration and resolution; however, if no name server can be located, it switches to b-node. Continues to poll for nameserver and switches back to p-node when one becomes available. By default, WINS clients are configured as h-node.
  • Microsoft-enhanced — local LMHOSTS files or WINS proxies plus Windows Sockets gethostbyname() calls (using standard DNS and local HOSTS files) in addition to standard node types.

The many configurable options sometimes make it difficult to determine what name resolution methods to choose, and what name resolution order each configuration will use. The following flowcharts illustrate name resolution for the various node types and the relationships between the different Windows NT name resolution services.

Figure 6.5 NetBIOS Name Resolution Flowchart (part 1 of 3)

Figure 6.6 NetBIOS Name Resolution Flowchart (part 2 of 3)

Figure 6.7 NetBIOS Name Resolution Flowchart (part 3 of 3)

The NetBIOS name server provided with Windows NT Server is the Windows Internet Name Service (WINS) server. Most WINS clients are set up as h-nodes; in other words, they first attempt to register and resolve names by a using WINS server, and if that fails they try local subnet broadcasts. Using a name server to locate resources is generally preferable to broadcasting, for two reasons:

  • Broadcasts are not usually forwarded over routers.
  • Broadcasts are received by all computers on a subnet, requiring processing time at each one.

NetBT and DNS

It has always been possible to connect from one Windows NT computer to another using NetBT over the Internet and other TCP/IP networks. To do so, some means of name resolution (associating a name with the appropriate IP address) is used because an IP address is required to establish a connection.

NetBT is the name resolution service for Windows-based networking in TCP/IP. DNS is the traditional and widely used name resolution service for the Internet and other TCP/IP networks. Windows NT Server version 4.0 has expanded support for DNS by implementing a DNS server.

A DNS name is similar to a NetBIOS name in that it is a "friendly" name for a computer or other network device. However, the DNS name is based on a hierarchical naming structure (also known as the name space) that is more flexible than the flat structure of NetBIOS names. DNS computer names consist of two parts: a host name and a domain name, which when combined, form the fully qualified domain name (FQDN).

NetBIOS computer names are analogous to DNS host names, however a DNS name can be as long as 255 characters while the NetBIOS name is limited to 15 user-definable characters.

Note

Under Windows NT, the DNS host name defaults to the NetBIOS computer name. Windows NT combines the NetBIOS computer name with the DNS domain name to form a FQDN by removing the 16th character in the NetBIOS name and appending a dot and the DNS domain name. If you want to change the default host name from the NetBIOS computer name, reconfigure TCP/IP by selecting the DNS page on the Microsoft TCP/IP Properties dialog box and changing the host name displayed on the DNS page.

It is now possible, in Windows NT 4.0, to connect to a NetBT resource by using an IP address, FQDN, or NetBIOS computer name. For example, if using the Event Viewer, when prompted to "select computer," you now can choose to enter an FQDN or IP address or NetBIOS computer name.

NetBIOS Name Registration and Resolution for Multihomed Computers

As mentioned earlier, NetBT only binds to one IP address per physical network interface. From the NetBT viewpoint, then, a computer is multihomed only when it has more than one NIC installed. When a name registration packet is sent from a multihomed computer, it is flagged as a "multihomed name registration" so that it will not conflict with the same name being registered by another interface in the same computer.

When a broadcast name query is received by a multihomed computer, all NetBT interface bindings receiving the query will respond with their address and, by default, the client will choose the first response and connect to the address supplied by it. This behavior can be controlled by the RandomAdapter registry parameter described in online Registry Help.

When a directed name query is sent to a WINS server, the WINS server will respond with a list of all IP addresses that were registered with WINS by a multihomed computer.

Choosing the "best" IP address to connect to on a multihomed computer is a client function. Currently, the following algorithm is employed, in the order listed:

1. If one of the IP addresses in the name query response list is on the same logical subnet as the calling binding of NetBT on the local computer, then that address is selected. If more than one of the addresses meet this criteria, one is picked at random from those that match.

2. If one of the IP addresses in the list is on the same logical subnet as any binding of NetBT on the local computer, then that address is selected. If more than one of the addresses meet this criteria, one is picked at random from those that match.

3. If none of the IP addresses in the list is on the same subnet as any binding of NetBT on the local computer, then an address is selected at random from the list.

This algorithm provides a reasonably good way of balancing connections to a server across multiple NICs, while still favoring direct connections when they are available.

Note

The current implementation of NetBT does not attempt to "walk the list" of returned addresses if a connection attempt to the first choice fails. This enhancement has been requested and is under review.

NetBT Sessions

NetBIOS sessions are established between two names. For example, when a Windows NT Workstation makes a file sharing connection to a server, the following sequence of events takes place:

1. The NetBIOS name for the server is resolved to an IP address.

2. A TCP connection is established from the workstation to the server, using port 139.

3. The workstation sends a NetBIOS session request to the server name over the TCP connection. Assuming the server is listening on that name, it will respond affirmatively and a session is established.

Once the NetBIOS session has been established, the workstation and server negotiate a higher level protocol to use over it. Microsoft networking uses only one NetBIOS session between two names at any point in time. Any additional file or print sharing connections made after the first one are multiplexed over that same NetBIOS session.

NetBIOS keepalives are used on each connection to verify that the server and workstation are both still up and able to maintain their session. This way, if a workstation is shut down ungracefully, the server will eventually clean up the connection and associated resources, and vice versa. NetBIOS keepalives are controlled by the SessionKeepAlive registry parameter and default to once per hour.

If LMHOSTS files are used and an entry is misspelled, it is possible to attempt to connect to a server using the correct IP address but an incorrect name. In this case, a TCP connection will still be established to the server. However, the NetBIOS session request (using the wrong name) will be rejected by the server, because there is no listen posted on that name. Error 51, "remote computer not listening," will be returned.

NetBT Datagram Services

Datagrams are sent from one NetBIOS name to another over UDP port 138. The datagram service provides the ability to send a message to a unique name or to a group name. Group names may resolve to a list of IP addresses or to a broadcast. For example, the command net send /d:mydomain test would send a datagram containing the text "test" to the group name <mydomain>[03]. The <mydomain>[03] name would resolve to an IP subnet broadcast, and so the datagram would be sent with the following characteristics:

  • Destination MAC address: broadcast (255.255.255.255)
  • Source MAC address: The NIC address of the local computer
  • Destination IP address: The local subnet broadcast address
  • Source IP address: The IP address of the local computer
  • Destination name: <mydomain>[03] (the Messenger service on the remote computers)
  • Source name: <localcomputer>[03] (the Messenger service on the local computer)

All hosts on the subnet would pick up the datagram and process it at least to the UDP protocol. On hosts running a NetBIOS datagram service, UDP would hand the datagram to NetBT on port 138. NetBT would check the destination name to see if any program had posted a datagram receive on it, and if so would pass the datagram up. If no receive is posted, the datagram is discarded.


TCP/IP Client/Server Programs

This chapter is intended to provide an overview of the Windows NT versions 4.0 and 3.5x implementation of the TCP/IP stack, not the many clients and services that are shipped with the product or are available from third parties. However, there are a few client/server programs that are critical to the configuration and operation of the TCP/IP protocol suite. These client/programs are briefly described in the following sections and then explained in detail in:

  • Chapter 7, "Managing Microsoft DHCP Servers"
  • Chapter 8, "Managing Microsoft WINS Servers"
  • Chapter 9, "Managing Microsoft DNS Servers"
  • Chapter 11, "Using SNMP for Network Management"
  • Appendix E, "RAS Reference"


Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) client/server is a Windows Sockets program that is used to provide automatic and dynamic configuration of various TCP/IP protocol components. The server is configured with "scopes," which are ranges of IP addresses, to distribute to network clients as they start on the network. The DHCP server can also provide the additional configuration parameters that are associated with the IP addresses. For example, a scope that includes a specific range of IP addresses may also be associated with default gateway, DNS server, and NetBIOS Name Server (WINS), with which the DHCP clients can be configured.

Obtaining Configuration Parameters Using DHCP

When a DHCP-enabled client starts for the very first time, it broadcasts a DHCP Discover request onto the local subnet. Any DHCP server that receives the request may respond with a DHCP Offer that contains proposed configuration parameters. The client can evaluate the offer, and respond with a DHCP request to accept it. The server finalizes the transaction with a DHCP ACK. The following example explains this sequence.

First, the DHCP Discover is sent as the stack initializes:

Time Source IP Dest IP Prot Description

0.000 0.0.0.0 255.255.255.255 DHCP Discover (xid=68256CA8) + FRAME: Base frame properties ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + ETHERNET: Destination address : 255.255.255.255 + ETHERNET: Source address : 00DD01075715 ETHERNET: Frame Length : 342 (0x0156) ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 328 (0x0148) IP: ID = 0x0; Proto = UDP; Len: 328 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) + IP: Service Type = 0 (0x0) IP: Total Length = 328 (0x148) IP: Identification = 0 (0x0) + IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 32 (0x20) IP: Protocol = UDP - User Datagram IP: CheckSum = 0x99A6 IP: Source Address = 0.0.0.0 IP: Destination Address = 255.255.255.255 IP: Data: Number of data bytes remaining = 308 (0x0134) UDP: IP Multicast: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server (67); Length = 308 (0x134) UDP: Source Port = BOOTP Client UDP: Destination Port = BOOTP Server UDP: Total length = 308 (0x134) bytes UDP: CheckSum = 0x4A0E UDP: Data: Number of data bytes remaining = 300 (0x012C) DHCP: Discover (xid=68256CA8) DHCP: Op Code (op) = 1 (0x1) DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet DHCP: Hardware Address Length (hlen) = 6 (0x6) DHCP: Hops (hops) = 0 (0x0) DHCP: Transaction ID (xid) = 1747283112 (0x68256CA8) DHCP: Seconds (secs) = 0 (0x0) DHCP: Flags (flags) = 0 (0x0) DHCP: 0............... = No Broadcast DHCP: Client IP Address (ciaddr) = 0.0.0.0 DHCP: Your IP Address (yiaddr) = 0.0.0.0 DHCP: Server IP Address (siaddr) = 0.0.0.0 DHCP: Relay IP Address (giaddr) = 0.0.0.0 DHCP: Client Ethernet Address (chaddr) = 00DD01075715 DHCP: Server Host Name (sname) = <Blank> DHCP: Boot File Name (file) = <Blank> DHCP: Magic Cookie = [OK] DHCP: Option Field (options) DHCP: DHCP Message Type = DHCP Discover DHCP: Client-identifier = (Type: 1) 00 dd 01 07 57 15 DHCP: Host Name = DAVEMAC4 DHCP: End of this option field

There are several interesting points to note in the DHCP discover packet. First, it is sent as a broadcast at both the link layer and the IP layer. Second, the DHCP broadcast flag is set to 0, indicating that the client is capable of receiving a response that is directed to its MAC address (indicated by chaddr). This means that the DHCP server is not required to broadcast the response.

Note

Windows NT version 3.5 computers required a broadcast response and did not set this flag to 0.

Finally, note that there is a transaction ID (XID) used to track each configuration sequence. Any response to this discover packet should reference the same XID.

A DHCP offer follows:

Time Source IP Dest IP Prot Description

0.165 172.16.113.254 172.16.112.13 DHCP Offer (xid=68256CA8) + FRAME: Base frame properties ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + ETHERNET: Destination address : 00DD01075715 + ETHERNET: Source address : 00000C1AEBC5 ETHERNET: Frame Length : 590 (0x024E) ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 576 (0x0240) IP: ID = 0x906; Proto = UDP; Len: 576 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) + IP: Service Type = 0 (0x0) IP: Total Length = 576 (0x240) IP: Identification = 2310 (0x906) + IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 31 (0x1F) IP: Protocol = UDP - User Datagram IP: CheckSum = 0xAF0D IP: Source Address = 172.16.113.254 IP: Destination Address = 172.16.112.13 IP: Data: Number of data bytes remaining = 556 (0x022C) UDP: Src Port: BOOTP Server, (67); Dst Port: BOOTP Client (68); Length = 556 (0x22C) DHCP: Offer (xid=68256CA8) DHCP: Op Code (op) = 2 (0x2) DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet DHCP: Hardware Address Length (hlen) = 6 (0x6) DHCP: Hops (hops) = 0 (0x0) DHCP: Transaction ID (xid) = 1747283112 (0x68256CA8) DHCP: Seconds (secs) = 0 (0x0) DHCP: Flags (flags) = 0 (0x0) DHCP: 0............... = No Broadcast DHCP: Client IP Address (ciaddr) = 0.0.0.0 DHCP: Your IP Address (yiaddr) = 172.16.112.13 DHCP: Server IP Address (siaddr) = 0.0.0.0 DHCP: Relay IP Address (giaddr) = 172.16.112.1 DHCP: Client Ethernet Address (chaddr) = 00DD01075715 DHCP: Server Host Name (sname) = <Blank> DHCP: Boot File Name (file) = <Blank> DHCP: Magic Cookie = [OK] DHCP: Option Field (options) DHCP: DHCP Message Type = DHCP Offer DHCP: Subnet Mask = 255.255.255.0 DHCP: Renewal Time Value (T1) = 1 Days, 12:00:00 DHCP: Rebinding Time Value (T2) = 2 Days, 15:00:00 DHCP: IP Address Lease Time = 3 Days, 0:00:00 DHCP: Server Identifier = 172.16.113.254 DHCP: End of this option field

The DHCP offer is also interesting. The XID is the same as that in the discover packet. It is a directed offer, not sent as a broadcast, and it is directed to the MAC address of the client and to the proposed IP address for the client. The source address is from a different subnet (172.16.113) than the subnet that the client is attached to, indicating that both the discover and the offer must have traversed a router. This can be verified by checking the DHCP "giaddr" field, that is set to 172.16.112.1. As you might suspect, a router is configured to forward DHCP broadcasts from this subnet to the one where the DHCP server is located. DHCP forwarding is discussed in RFC 1542, and routers used for this purpose must explicitly support the RFC and be configured accordingly.

Next, the client accepts the offer:

Time Source IP Dest IP Prot Description

0.172 0.0.0.0 255.255.255.255 DHCP Request (xid=08186BD1) + FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x100; Proto = UDP; Len: 328 + UDP: IP Multicast: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server (67); Length = 308 (0x134) DHCP: Request (xid=08186BD1) DHCP: Op Code (op) = 1 (0x1) DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet DHCP: Hardware Address Length (hlen) = 6 (0x6) DHCP: Hops (hops) = 0 (0x0) DHCP: Transaction ID (xid) = 135818193 (0x8186BD1) DHCP: Seconds (secs) = 0 (0x0) DHCP: Flags (flags) = 0 (0x0) DHCP: 0............... = No Broadcast DHCP: Client IP Address (ciaddr) = 0.0.0.0 DHCP: Your IP Address (yiaddr) = 0.0.0.0 DHCP: Server IP Address (siaddr) = 0.0.0.0 DHCP: Relay IP Address (giaddr) = 0.0.0.0 DHCP: Client Ethernet Address (chaddr) = 00DD01075715 DHCP: Server Host Name (sname) = <Blank> DHCP: Boot File Name (file) = <Blank> DHCP: Magic Cookie = [OK] DHCP: Option Field (options) DHCP: DHCP Message Type = DHCP Request DHCP: Client-identifier = (Type: 1) 00 dd 01 07 57 15 DHCP: Requested Address = 172.16.112.13 DHCP: Server Identifier = 172.16.113.254 DHCP: Host Name = DAVEMAC4 DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06 DHCP: End of this option field

The request is again broadcast, and the proposed IP address from the server is referenced. The request is broadcast for a reason¾the client could have received more than one offer and, by broadcasting its request, it allows the other DHCP servers to see that it isn't going to use their offers.

Finally, the client acknowledges that it will accept the lease:

Time Source IP Dest IP Prot Description

0.061 172.16.113.254 172.16.112.13 DHCP ACK (xid=08186BD1) + FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0xA06; Proto = UDP; Len: 576 + UDP: Src Port: BOOTP Server, (67); Dst Port: BOOTP Client (68); Length = 556 (0x22C) DHCP: ACK (xid=08186BD1) DHCP: Op Code (op) = 2 (0x2) DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet DHCP: Hardware Address Length (hlen) = 6 (0x6) DHCP: Hops (hops) = 0 (0x0) DHCP: Transaction ID (xid) = 135818193 (0x8186BD1) DHCP: Seconds (secs) = 0 (0x0) DHCP: Flags (flags) = 0 (0x0) DHCP: 0............... = No Broadcast DHCP: Client IP Address (ciaddr) = 0.0.0.0 DHCP: Your IP Address (yiaddr) = 172.16.112.13 DHCP: Server IP Address (siaddr) = 0.0.0.0 DHCP: Relay IP Address (giaddr) = 172.16.112.1 DHCP: Client Ethernet Address (chaddr) = 00DD01075715 DHCP: Server Host Name (sname) = <Blank> DHCP: Boot File Name (file) = <Blank> DHCP: Magic Cookie = [OK] DHCP: Option Field (options) DHCP: DHCP Message Type = DHCP ACK DHCP: Renewal Time Value (T1) = 1 Days, 12:00:00 DHCP: Rebinding Time Value (T2) = 2 Days, 15:00:00 DHCP: IP Address Lease Time = 3 Days, 0:00:00 DHCP: Server Identifier = 172.16.113.254 DHCP: Subnet Mask = 255.255.255.0 DHCP: Domain Name = (Length: 22) 63 73 77 61 74 63 70 2e 6d 69 63 72 6f 73 6f 66 ... DHCP: Router = 172.16.112.1 DHCP: NetBIOS Name Service = 172.16.113.254 DHCP: NetBIOS Node Type = (Length: 1) 08 DHCP: End of this option field

The acknowledgment is the final packet of the transaction, and it contains all of the configuration parameters that the client will use.

Lease Expiration and Renewal

DHCP-supplied configurations are "leased" from the server. Periodically, the client will contact the server to renew the lease. The protocol and implementation are very robust and configurable, and short-term server or network outages do not generally affect lease renewal. For example, DHCP clients start to try to renew their lease when 50 percent of the lease time has expired. Repeated attempts are made to contact the DHCP server and renew the lease, until 87.5 percent of the lease time has expired. At this point, the client attempts to get a new lease from any available DHCP server.

When a DHCP client is rebooted, it attempts to verify that the lease it holds is valid for the current subnet. If it is moved to another subnet and rebooted, the following sequence takes place:

Source Destination Source IP Destination IP Pro Description

davemacp *BROADCAST 0.0.0.0 255.255.255.255 DHCP Request (xid=6E3A2E74) router *BROADCAST 10.57.8.1 255.255.255.255 DHCP NACK (xid=6E3A2E74) davemacp *BROADCAST 0.0.0.0 255.255.255.255 DHCP Discover (xid=51CA7FED) router davemacp 10.57.8.1 10.57.13.152 DHCP Offer (xid=51CA7FED) davemacp *BROADCAST 0.0.0.0 255.255.255.255 DHCP Request (xid=2081237D) router davemacp 10.57.8.1 10.57.13.152 DHCP ACK (xid=2081237D)

In this example the portable computer "davemacp" is moved to a new subnet and re-started. It broadcasts a DHCP request for renewal of its old parameters, but the DHCP server responsible for the new subnet recognized that these were invalid for the subnet and NAK'd them. The DHCP client software automatically went through a normal discovery process to get reconfigured with parameters that are valid for the new location. For additional information on DHCP, see Chapter 7, "Managing Microsoft DHCP Servers."


Windows Internet Name Service

Windows Internet Name Service (WINS) is a NetBIOS name service as described in RFC 1001 and RFC 1002. When a Windows NT computer is configured as h-node (default for WINS clients), it attempts to use a WINS server for name registration and resolution first and, if that fails, it resorts to subnet broadcasts.

WINS Name Registration and Resolution

Using WINS for name services dramatically reduces the number of IP broadcasts used by Microsoft network clients. The following portion of a trace illustrates name registration and resolution traffic caused by starting a Windows NT workstation.

Source IP Destination IP Prot Description

  • 172.16.112.124 172.16.113.254 NBT NS: MultiHomed Name Registration req. for DAVEMAC4<00>
  • 172.16.113.254 172.16.112.124 NBT NS: Registration resp. for DAVEMAC4<00>, Success
  • 172.16.112.124 172.16.113.254 NBT NS: Registration req. for DAVEMACD<00>
  • 172.16.113.254 172.16.112.124 NBT NS: Registration resp. for DAVEMACD<00>, Success
  • 172.16.112.124 172.16.113.254 NBT NS: Query req. for DAVEMACD<1C>
  • 172.16.113.254 172.16.112.124 NBT NS: Query resp. for DAVEMACD<1C>, Success
  • 172.16.112.124 172.16.113.254 NBT NS: MultiHomed Name Registration req. for DAVEMAC4<03>
  • 172.16.113.254 172.16.112.124 NBT NS: Registration resp. for DAVEMAC4<03>, Success

This trace shows that the starting client (172.16.112.124) sends a single name registration request to the WINS server, asking to register the computer name (DAVEMAC4<00>) as a unique name for a multihomed host. The WINS server responds affirmatively. Next, the domain name (DAVEMACD<00>) is registered as a group name. Then a name query is sent to the WINS server, requesting a list of domain controllers (who all register the <domain>[1C] name) so that a logon server can be contacted. One more registration is shown, for DAVEMAC4<03>, which is the name registered by the Messenger service. The fully parsed version of the domain name registration follows:

Source IP Destination IP Prot Description

172.16.112.124 172.16.113.254 NBT NS: Registration req. for DAVEMACD<00> + FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x300; Proto = UDP; Len: 96 + UDP: Src Port: NETBIOS Name Service, (137); Dst Port: NETBIOS Name Service (137); Length = 76 (0x4C) NBT: NS: Registration req. for DAVEMACD<00> NBT: Transaction ID = 32770 (0x8002) NBT: Flags Summary = 0x2900 - Req.; Registration; Success NBT: 0............... = Request NBT: .0101........... = Registration NBT: .....0.......... = Non-authoritative Answer NBT: ......0......... = Datagram not truncated NBT: .......1........ = Recursion desired NBT: ........0....... = Recursion not available NBT: .........0...... = Reserved NBT: ..........0..... = Reserved NBT: ...........0.... = Not a broadcast packet NBT: ............0000 = Success NBT: Question Count = 1 (0x1) NBT: Answer Count = 0 (0x0) NBT: Name Service Count = 0 (0x0) NBT: Additional Record Count = 1 (0x1) NBT: Question Name = DAVEMACD<00> NBT: Question Type = General Name Service NBT: Question Class = Internet Class NBT: Resource Record Name = DAVEMACD<00> NBT: Resource Record Type = NetBIOS General Name Service NBT: Resource Record Class = Internet Class NBT: Time To Live = 300000 (0x493E0) NBT: RDATA Length = 6 (0x6) NBT: Resource Record Flags = 57344 (0xE000) NBT: 1............... = Group NetBIOS Name NBT: .11............. = Reserved NBT: ...0000000000000 = Reserved NBT: Owner IP Address = 172.16.112.13

Because the domain name is a group name, any number of hosts are allowed to register it.

WINS in a DHCP Environment

WINS is especially helpful on DHCP-enabled networks. One of the DHCP-provided parameters can be the address of a WINS server, and so as soon as the client is configured by DHCP, it registers its name(s) and address with the WINS server, and can then be easily located by the other computers on the network. This combination of DHCP and WINS is ideal for dynamic situations.

For additional information on WINS, see Chapter 8, "Managing Microsoft WINS Servers."


Domain Name System

Windows NT Server version 4.0 includes an RFC-compliant Domain Name System (DNS) server. DNS servers are defined in RFCs 1034 and 1035.

DNS is a global, distributed database based on a hierarchical naming system. The naming system was developed to provide a method for uniquely identifying hosts (computers and other network devices) on the Internet and other TCP/IP networks. The root of the DNS database is managed by the Internet Network Information Center. The top-level domains are assigned by organization and by country.

The DNS name consists of two parts¾the domain name and the host name¾known together as the fully qualified domain name (FQDN). For example, using the fictional domain name of Terra Flora, an FQDN for a workstation in the nursery division could be: jeff.nursery.terraflora.com. Note that the DNS name can actually be multi-part with each part of the name separated by a period (.).

DNS uses a client/server model. The DNS name server contains information about a portion of the global DNS name space, such as a private intranet. Client computers can be configured to query the DNS server for host name-to-IP-address mapping as needed to connect to the Internet or an intranet TCP/IP network resource.

Integration of Windows NT DNS and WINS Servers

The Windows NT-based DNS server provides connectivity between WINS and DNS. In addition to providing an RFC-compliant DNS service, the Windows NT Server-based DNS server can pass through an unresolved DNS name query to a WINS server for final name resolution.

This occurs transparently and the client need not be aware of whether a DNS or WINS server processed the name query. In a Windows NT– based network running both DNS and WINS servers, you can perform forward look-up—which is IP address resolution by using a friendly (NetBIOS or DNS) name, and reverse look-up—which is (NetBIOS or DNS) name resolution by using an IP address.

Dynamic WINS and Static DNS

WINS provides a dynamic, distributed database for registering and querying dynamic NetBIOS computer name-to-IP-address mappings. DNS provides a static, distributed database for registering and querying static FQDN name-to-IP-address mappings.

DNS depends on static files for name resolution and does not yet support dynamic updates of name and IP address mapping. In other words, DNS requires static configuration of IP addresses to perform name-to-IP-address mapping, WINS supports DHCP dynamic allocation of IP addresses and can resolve a NetBIOS computer name to a dynamic IP address mapping.

Note

Dynamic DNS is currently under discussion by the Internet Engineering Task Force (IETF).

For information about installing a Microsoft DNS server, see online Help. For information about configuration of the DNS server and using the DNS Manager, see online DNS Manager Help.

Note

Microsoft first included a Beta version of a DNS server for Windows NT 3.5x in the Windows NT 3.5x Resource Kits. You can upgrade the Beta version to Microsoft DNS server under Windows NT Server version 4.0. See the topic "To Upgrade a Windows NT 3.51 Resource Kit DNS Server" in Microsoft TCP/IP Help.

For additional information on DNS, see Chapter 9, "Managing Microsoft DNS Servers."


The Browser

The Browser service (not to be confused with a Web browser) was originally designed to be a simple workgroup enumeration tool, but has been enhanced significantly over time. The Browser service supports browsing computers on the network and being browsed by other computers.

It is the service that gathers and organizes the list of computers and domains that is displayed in Network Neighborhood. (You can also see the browse list by typing net viewin the command window.) The Browser maintains an up-to-date list of computers and provides this information to programs that require it.

Note

Under Windows NT version 3.5x, use the File Manager Connect Network Drive dialog box to view the computer browser list.

Master Browser Elections

The Primary Domain Controller (PDC) for a domain always functions as the Domain Master Browser and is responsible for replicating the browse lists to all Master Browsers within the domain. A Master Browser is elected on each subnet within the domain.

Each domain has one Master Browser per subnet that contains computers listening for server announcements. The Master Browser maintains lists of available resources that can be requested by client computers.

As the number of hosts on a subnet grows, the Master Browser will start to replicate the browse list to Backup Browsers. If the Master Browser is shut down, an election takes place to determine the new Master Browser. Existing Backup Browsers have an advantage in the election. For this process, workgroups and domains function alike, except that all Windows NT Servers are either a Master Browser or Backup Browser, and Windows NT Workstation and Windows for Workgroups computers are not allowed to become Backup or Master browsers unless specifically configured.

Master Browser elections take place over the special <domain>[1E] NetBIOS name using subnet broadcasts (without using WINS). The election is fully automatic and takes into consideration a number of heuristics: operating system, version number, uptime, role (Workstation, Backup Domain Controller, Primary Domain Controller), etc. In general, the most robust computer on the network wins. Elections are forced when:

  • A client cannot find its Master Browser at startup.
  • A client detects that a Master Browser has disappeared.
  • A Windows NT Server starts on the network.

Maintaining Browse Lists

File servers periodically (once every 12 minutes) announce their presence to the special <domain>[1D] NetBIOS name in an IP subnet broadcast. The Master Browser builds a list from these broadcasts. In addition, all Master Browsers register a group name \0x01\0x02__MSBROWSE__\0x02\0x01on the local subnet (not with WINS). Periodically the Master Browsers in the domains and workgroups announce their presence to this special name. Thus, in addition to the workgroup or domain membership lists, Master Browsers also maintain lists of other domains with their associated Master Browsers.

Requesting Browse Lists

When a browse request is made from a client, a "GetBackupListRequest" is sent to the <domain>[1D] name (the Master Browser) that returns a list of Browser servers for the local subnet. The "GetBackupListRequest" is also unicast to the Domain Master Browser, which handles the case in which the queried domain has no members on the subnet. The client Browser service selects three of the browsers from the list and stores them for future use. Then when further browsing is done, by calling the NetServerEnum API, one of the three saved names is contacted by the client.

When a client queries its workgroup or domain browser, it first gets back a list of all of the domains and workgroups that the browser has learned about through the \0x01\0x02__MSBROWSE__\0x02\0x01 name as well as the name of the Master Browser for each. When the user expands a domain or workgroup into a membership list, the client sends a request to <domain>[1D] to get to the list (this is translated to a local subnet broadcast by WINS). If this fails, it contacts the Master Browser for the particular domain or workgroup and fetches the membership list.

The Domain Master Browser

As mentioned earlier, the PDC always acts as the Domain Master Browser. Because each locally-elected Master Browser will only hear local membership announcements, there needs to be a mechanism to consolidate all of the members into a single list. This is the role of the Domain Master Browser.

Periodically, all of the locally-elected Master Browsers contact the PDC and replicate their membership lists to it. The PDC merges the list with the "master" list for the whole domain and replicates the master list back down.

The replication algorithm is "smart" in that the local Master Browsers only replicate the members that they have learned about locally to the domain master. This whole mechanism allows members in a domain to span subnets and, for all clients (eventually), to be able to get complete membership lists.

On WINS-enabled networks, the browser code in Windows NT versions 4.0 and 3.5x periodically connects to WINS and learns all of the computers that have registered any <domain>[1B] names. The Browser then does a GetDCName() on each of the <domain>[1B] names (followed by an attempt on <domain>[1C]), and adds the <domain name> <master browser name> to its domain/workgroup list. This allows members of one domain to locate the Master Browser for another domain even when it is on another subnet and the two domains have no "broadcast area" in common.

Browsing for Other Windows-based Computers

Browser code for Windows for Workgroups computers has been enhanced several times to reduce the dependency on having a BDC per subnet. The updated files are available from ftp.microsoft.com. Windows 95 computers also contain enhanced browsing code.


Windows NT Workstation and Windows NT Server Services

The Workstation and Server services are used for file and print sharing. Both use NetBIOS over TCP/IP to communicate with each other; however, they are not NetBIOS programs. They are written to talk directly to NetBT over the TDI interface. Being direct TDI clients, they are high performance and not subject to limitations of the NetBIOS interface, such as the 254 session limit. The Server Message Block (SMB) protocol is used to send commands and responses between clients and servers. Public SMB specifications are available from ftp.microsoft.com.

Logging On

When a user logs on to a Windows NT domain, the following sequence of events occurs:

1. If the computer is WINS-enabled, a name query for the NetBIOS <domain>[1C] name is sent to the WINS server.

2. The WINS server responds with a list of up to 25 IP addresses corresponding to domain controllers for the specified domain name. One of the IP addresses in the list will always be the Primary Domain Controller.

3. A \MAILSLOT\NET\NTLOGON request is broadcast on the local subnet. If a response to the local subnet broadcast is received, then the logon process contacts the responding domain controller to attempt a logon.

4. Otherwise, the logon process sends a directed datagram to each of the addresses returned in the list from the WINS server, and attempts to log on to the first domain controller to respond.

5. All domain controllers register this <domain>[1C] name on the network, typically with the WINS database. All password information is encrypted before being transmitted on the network.

Connecting to Network Resources

When a workstation attempts to connect to a shared resource on the network, the resource is "called" by its NetBIOS name. The name-to -IP-address resolution is done in the manner illustrated in the NetBIOS Name Resolution Flowchart (Figures 6.5 through 6.7) in the section "NetBIOS Interface" earlier in this chapter.

Once the IP address of the target host is known, a standard TCP/IP connection is set up, and a NetBIOS session is established over that connection. The user is authenticated using encrypted passwords, and then client/server messages are exchanged using the SMB protocol. The workstation and server use sophisticated caching mechanisms to reduce network traffic and provide high performance. When WINS is used, there is no reliance on IP broadcasts, with the single exception of ARPs.

Optimizations

The Windows NT Workstation and Windows NT Server services were designed with many optimizations to minimize network traffic and maximize throughput. The network redirector works closely with the Windows NT Cache Manager to provide read-ahead caching, write-behind caching, and search caching. Various file locking schemes, such as opportunistic locking and local file lock optimization, help to reduce network traffic. The SMB protocol which is used supports compound commands and responses, such as LockAndRead and WriteAndUnlock.


Microsoft Remote Access Service

Windows NT Remote Access Service (RAS) is a networking service that connects remote or mobile workers to corporate networks. RAS uses the following remote access protocols for RAS server and client services:

  • Point-to-Point Protocol (PPP)
  • Point-to-Point Tunneling Protocol (PPTP)
  • Serial Line IP (SLIP)
  • Microsoft RAS Protocol (asynchronous NetBEUI)

Note

Remote access protocols control the transmission of data over wide area networks (WANs). Protocols such as TCP/IP, IPX, and NetBEUI are considered local area network (LAN) protocols. The focus of this chapter is TCP/IP; for detailed information about RAS and the other LAN protocols, see the Networking Supplement for Windows NT Server version 4.0.

RAS Servers

RAS servers act as a "proxy" for TCP/IP clients. RAS servers use proxy ARP to respond to ARP requests from RAS clients, and also set up the network host routes to each dial-up client. RAS servers may obtain configuration parameters for their clients from a DHCP server, and then use PPP IPCP (Internet Protocol Control Protocol), as defined in RFC 1332, to dynamically configure their clients with these parameters over the RAS link.

When a RAS server is configured to use DHCP to obtain TCP/IP configuration parameters for its clients, a pool of leased addresses is obtained from the DHCP server and managed locally by the RAS server. If more addresses are needed, or leases need to be renewed, the RAS server will contact the DHCP server; however, it does not check with the DHCP server each time a RAS client starts. If the RAS server is moved to another subnet, it may have a pool of leases that are not valid for the new subnet still stored in the registry until they expire.

RAS Clients

RAS clients using TCP/IP can be configured to use the default gateway on the remote network while they are connected to a RAS server. This default gateway overrides any local network default gateway while the RAS connection is established. The override is accomplished by manipulating the IP route table. Any local routes, including the default gateway, get their metric (hop count) incremented by one, and a default route with a metric of 1 hop is dynamically added for the duration of the connection. One-hop routes are also added for the IP multicast address (224.0.0.0), for the local WAN interface, and for the network that the PPP server is attached to.

This can present a problem connecting to resources by using the local network default gateway, unless static routes are added at the client. The following are sample route tables for a Windows NT workstation before and after connecting to a remote network using PPP:

Route table before dialing a PPP Internet provider:

Network Address | Netmask | Gateway Address | Interfac | Metric
0.0.0.0 | 0.0.0.0 | 172.16.112.1 | 172.16.112.11 |  | 1
127.0.0.0 | 255.0.0.0 | 127.0.0.1 | 127.0.0.1 |  | 1
172.16.112.0 | 255.255.255.0 | 172.16.112.11 | 172.16.112.11 |  | 1
172.16.112.11 | 255.255.255.255 | 127.0.0.1 | 127.0.0. |  | 1
172.16.112.255 | 255.255.255.255 | 172.16.112.11 | 172.16.112.11 |  | 1
224.0.0.0 | 224.0.0.0 | 172.16.112.11 | 172.16.112.11 |  | 1
255.255.255.255 | 255.255.255.255 | 172.16.112.11 | 172.16.112.11 |  | 1

Route table after dialing a PPP Internet provider:

Network Address | Netmask | Gateway Address | Interfac | Metric
0.0.0.0 | 0.0.0.0 | 172.16.112.1 | 172.16.112.11 | 2
0.0.0.0 | 0.0.0.0 | 172.16.16.243 | 172.16.16.243 | 1
127.0.0.0 | 255.0.0.0 | 127.0.0.1 | 127.0.0.1 | 1
172.16.112.0 | 255.255.255.0 | 172.16.112.11 | 172.16.112.11 | 2
172.16.112.11 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 1
172.16.112.255 | 255.255.255.255 | 172.16.112.11 | 172.16.112.11 | 1
204.182.66.0 | 255.255.255.0 | 172.16.16.243 | 172.16.16.243 | 1
172.16.16.243 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 1
224.0.0.0 | 224.0.0.0 | 172.16.16.243 | 172.16.16.243 | 1
224.0.0.0 | 224.0.0.0 | 172.16.112.11 | 172.16.112.11 | 1
255.255.255.255 | 255.255.255.255 | 172.16.112.11 | 172.16.112.11 | 1

Secure Internet Transport with TCP/IP and PPTP

Windows NT-based RAS is based on PPP, the industry-standard for dial-up access services and includes industry-standards for authentication and encryption. PPTP, which is used to create virtual private networks (VPNs), uses PPP to provide compressed and encrypted RAS communication. PPTP technology enables RAS user access to private networks by using the Internet instead of long distance telephone lines (thus reducing transmission costs). RAS users can use PPTP over the Internet by either:

  • Connecting directly to the Internet
  • Dialing into an Internet Service Provider (ISP)

PPTP provides multi-protocol support for IP, IPX, and NetBEUI protocols. For example, RAS clients using PPTP and the Internet (as a network backbone) can send and receive IPX and NetBEUI packets.

Note

Because the Internet is a TCP/IP-based network, you must install and bind TCP/IP to the network card that will be used for RAS and PPTP communications. To select the network card (adapter) and to enable PPTP filtering, open the Microsoft TCP/IP Properties page, and click Advanced to open the Advanced TCP/IP Properties page. For specific instructions, see online Help.

The following figure illustrates the implementation of PPTP. Note that after processing a packet (from an IP, IPX, or NetBEUI transport), PPTP sends the packet to the top of the TCP/IP protocol stack. The TCP/IP protocol stack then sends the packet across the Internet. (At the receiving end of a packet transmission, the PPTP packet must be decoded by another PPTP service.)

Figure 6.8 Using RAS with PPTP and TCP/IP

For detailed information about PPTP, see the chapter "Point-to-Point Tunneling Protocol" in the Networking Supplement for Windows NT Server version 4.0.

Bandwidth Considerations

By default, RAS uses effective compression methods to increase the amount of data that can be pumped over a serial link. Bandwidth planning is important when designing and installing computers and services using RAS. As a rule of thumb, transfer rates can be estimated using the 10-bit byte to allow for protocol and timing overhead. For example, 9600 BPS (without compression) is approximately 1 Kbyte/second, 60Kbytes/minute, and 3.5Mbytes/hour. If the data being transferred compresses fairly well, 5-8 Mbytes per hour throughput might be expected. While this may be an adequate rate for a single workstation, it probably is not feasible as an inter-site link for most programs. ISDN (128Kbits/second or 45 Mbytes/hour, not including compression) might be more realistic. ISDN service in the United States has recently become more available and economical to install and use.


Simple Network Management Protocol

The Simple Network Management Protocol (SNMP) agent in Windows NT provides some programmatic access to the TCP/IP protocol stack and can be used to get information about the performance and usage of network components. The SNMP agent supports network management programs provided by Microsoft and third-party vendors. For more information about SNMP, see Chapter 11, "Using SNMP for Network Management," and Appendix C, "MIB Object Types for Windows NT." For information about installing and configuring SNMP, see Microsoft TCP/IP Help.


TCP/IP Printing

Line printer (LPR) is one of the network protocols and utilities of the TCP/IP protocol suite and is defined in RFC 1179. LPR provides a standard for transmitting TCP/IP print jobs between computers. With the LPR protocol, a client can send a print job to a print spooler service on another computer running the print spooler service known as line-printer daemon (LPD).

Windows NT provides both the LPR and LPD services for TCP/IP printing. In general, Windows NT supports TCP/IP printing as documented in RFC 1179. However, because RFC 1179 describes an existing print server protocol that is widely used on the Internet, but which is not an Internet standard, changes to printing under Windows NT 4.0 is somewhat different than printing described in RFC 1179. The following TCP/IP print enhancements were added to Windows NT version 4.0.

  • Support for multiple data files per control file
  • When used in "print through" mode as an intermediate spooler, the host name parameter is passed through the Windows printing subsystem
  • LPR jobs are sourced from any reserved port between 512 and 1023

Note

Under Windows NT version 3.5x, all TCP/IP print jobs sent from a Windows NT computer were sourced from TCP ports 721 through 731, and, if many jobs were sent in quick succession, the ports could be "used up," causing a pause in printing until one of them passed through the TCP TIME_WAIT state.


Microsoft Internet Information Server

Internet Information Server (IIS) is a powerful Web, FTP, and GOPHER server designed specifically for Windows NT. It uses a worker thread model (as opposed to a "thread per client" model) to provide the ability to service an extremely large number of connections with high performance. It also takes advantage of the new performance-boosting Microsoft Internet API set, which includes calls such as TransmitFile() and AcceptEx().

All three services run from within the same process (inetinfo.exe) and share resources such as worker threads and cached file handles. IIS has configurable logging that supports both text files and logging directly to a database by using ODBC. IIS also supports the use of sophisticated databases on the "backend" so that access to a database can be achieved by using a standard Web browser. In many cases a database is easier to maintain than a large number of static HTML files.

IIS ships with Windows NT Server 4.0, and versions for Windows NT Server 3.51 are available from www.microsoft.com. Microsoft Internet Information Server is not designed (or licensed) to run on Windows NT Workstation. More details are available from the Microsoft Web site.


Summary of Changes

As a convenient reference, the following sections list recent changes in Microsoft 32-bit TCP/IP for Windows NT.


Service Enhancements

  • Domain Name System (DNS) server (added in Windows NT 4.0)
  • NetBT and DNS Enhancements (added in Windows NT 4.0)
  • Nslookup utility added to TCP/IP utilities for troubleshooting DNS (added in Windows NT 4.0)
  • MPR (Multi-Protocol Router) support (added in Windows NT 3.51 Service Pack 2)
  • TCP/IP printing support enhancements (added in Windows NT 4.0)
  • Point-to-Point Tunneling Protocol enhancement (added in Windows NT 4.0)


Additional or Changed TCP/IP Registry Parameters

  • Afd.sys Registry Key
  • IgnorePushBitOnReceives (changed in Windows NT 4.0 and Windows NT 3.51 Service Pack 5)
  • ArpCacheLife (new in Windows NT 4.0 and Windows NT 3.51 Service Pack 4)
  • ArpTRSingleRoute (new in Windows NT 4.0 and Windows NT 3.51 Service Pack 5)
  • DefaultTTL for IP changed from 32 to 128 (changed in Windows NT 4.0)
  • EnableSecurityFilters (new in Windows NT 4.0)
  • MaxForwardBufferMemory (new in Windows NT 3.51 Service Pack 2)
  • MaxForwardPending (new in Windows NT 3.51 Service Pack 2)
  • MaxNumForwardPackets (new in Windows NT 3.51 Service Pack 2)
  • MaxUserPort (new in Windows NT 4.0 and Windows NT 3.51 Service
    Pack 5)
  • PersistentRoutes (The primary route metric is added as the fourth parameter in the PersistentRoutes key; new in Windows NT 3.51 Service Pack 2)
  • RawIpAllowedProtocols (new in Windows NT 4.0)
  • TcpAllowedPorts (new in Windows NT 4.0)
  • TcpTimedWaitDelay (new in Windows NT 4.0 and Windows NT 3.51 Service Pack 5)
  • UdpAllowedPorts (new in Windows NT 4.0)


Chapter 7 - Managing MS DHCP Servers

Dynamic Host Configuration Protocol (DHCP) is an open, industry standard that is designed to reduce the complexity of Transmission Control Protocol/Internet Protocol (TCP/IP) network administration. DHCP specifies methods for simplified and dynamic configuration of computers on TCP/IP networks, and reduces the administrative burden of adding, moving, and configuring computers on TCP/IP networks.

DHCP is specified by Internet Engineering Task Force (IETF) Requests for Comments (RFCs) 1533, 1534, 1541, and 1542.

The information in this chapter is intended for network administrators and support personnel who need to manage and support Microsoft DHCP servers. This chapter includes the following topics:

  • Introduction to Dynamic Host Configuration Protocol (DHCP)
    • Microsoft DHCP server
    • DHCP clients
    • DHCP/BOOTP relay agents
  • Planning for Microsoft DHCP server implementation
    • Planning for small networks
    • Planning for routed networks
    • Planning for DHCP server and client traffic
    • Setting local policies
    • Partitioning the Microsoft DHCP server address pool
    • Using Microsoft DHCP with Domain Name System (DNS) servers
  • Using DHCP Manager
  • Managing the DHCP server database
  • Troubleshooting DHCP services


Introduction to Dynamic Host Configuration Protocol

Every computer on a TCP/IP internetwork must be given a unique computer name and IP address. The IP address identifies both the computer and the subnetwork to which it is attached. When the computer is moved to a different subnetwork, the IP address must be changed to reflect the new subnetwork ID.

DHCP is designed to reduce the complexity of configuring computers for TCP/IP networks. RFC 1541 specifies two major components needed for DHCP services: a protocol for communicating TCP/IP configuration parameters between a DHCP server and a DHCP client, and a method for allocating IP addresses to the DHCP client.


Understanding IP Addresses

To receive and deliver packets successfully between computers, TCP/IP requires that three values be provided by the network administrator: an IP address, a subnet mask, and a default gateway (router).

IP Addresses

Every device attached to a TCP/IP network is identified by a unique IP address. (If a computer has multiple network adapters, each adapter will have its own IP address.) This address is typically represented in dotted-decimal notation—that is, with the decimal value of each octet (8 bits, or 1 byte) of the address separated by a period. The following is a sample IP address:

172.16.48.1

Important

Because IP addresses identify devices on a network, each device on the network must be assigned a unique IP address.

Network ID and Host ID

Although an IP address is a single value, it contains two pieces of information: the network ID and the host ID of your computer.

  • The network ID identifies the systems that are located on the same physical network. All systems on the same physical network must have the same network ID, and the network ID must be unique to the internetwork.
  • The host ID identifies a workstation, server, router, or other TCP/IP device within a network. The address for each device must be unique to the network ID.

A computer connected to a TCP/IP network uses the network ID and host ID to determine which packets it should receive or ignore and to determine the scope of its transmissions. (Only computers with the same network ID accept each other's IP-level broadcast messages.)

Note

Networks that connect to the public Internet must obtain an official network ID from the Internet Network Information Center (InterNIC) to guarantee the uniqueness of the IP network ID. For more information, visit the InterNIC home page on the Internet at http://www.internic.net/

After receiving a network ID, the local network administrator must assign unique host IDs for computers within the local network. Although private networks not connected to the Internet can use their own network identifier, obtaining a valid network ID from InterNIC allows a private network to connect to the Internet in the future without reassigning addresses.

The Internet community has defined address classes to accommodate networks of varying sizes. The address class can be discerned from the first octet of an IP address. Table 7.1 summarizes the relationship between the first octet of a given address and its network ID and host ID fields. It also identifies the total number of network IDs and host IDs for each address class that participates in the Internet addressing scheme. The example in Table 7.1 uses w.x.y.z to designate the bytes of the IP address.

Table 7.1 IP Address Classes

Class | w values 1,2 | Network ID | Host ID | Available networks | Available hosts per network
A | 1–126 | w | x.y.z | 126 | 16,777,214
B | 128–191 | w.x | y.z | 16,384 | 65,534
C | 192–223 | w.x.y | z | 2,097,151 | 254

1 Inclusive range for the first octet in the IP address.

2 The address 127 is reserved for loopback testing and interprocess communication on the local computer; it is not a valid network address. Addresses 224 and above are reserved for special protocols (Internet Group Management Protocol multicast and others), and cannot be used as host addresses.

Subnet Masks

Subnet masks are 32-bit values that allow the recipient of IP packets to distinguish the network ID portion of the IP address from the host ID. Subnet masks are created by assigning 1s to network ID bits and 0s to host ID bits. The 32-bit value is then converted to dotted-decimal notation, as shown in Table 7.2.

Table 7.2 Default Subnet Masks for Standard IP Address Classes

Address class | Bits for subnet mask | Subnet mask
Class A | 11111111 00000000 00000000 00000000 | 255.0.0.0
Class B | 11111111 11111111 00000000 00000000 | 255.255.0.0
Class C | 11111111 11111111 11111111 00000000 | 255.255.255.0

For example, when the IP address is 172.16.16.1 and the subnet mask is 255.255.0.0, the network ID is 172.16 and the host ID is 16.1.

Because the class of a host is easily determined, configuring a host with a subnet mask might seem redundant. But subnet masks are also used to further segment an assigned network ID among several local networks. Sometimes only portions of an octet need to be segmented, using only a few bits to specify subnet IDs.

Important

To prevent addressing and routing problems, all computers on a logical network must use the same subnet mask and network ID.


Microsoft DHCP Server

Microsoft DHCP server provides a reliable and flexible alternative to manual TCP/IP configuration. Microsoft DHCP server includes a graphical administrative tool—DHCP Manager—that allows you to define DHCP client configurations, and a database for managing assignment of client IP addresses and other optional TCP/IP configuration parameters.

You can use Microsoft DHCP server to automatically and dynamically assign TCP/IP configuration parameters to computers that start on the network. TCP/IP configuration parameters that can be dynamically assigned by a Microsoft DHCP server include:

  • IP addresses for each network adapter card in a computer.
  • Subnet masks that identify the portion of an IP address that is the physical segment (subnet) network identifier.
  • Default gateway (router) that connects the subnet to other network segments.
  • Additional configuration parameters that can be optionally assigned to DHCP clients, such as domain name.

A Microsoft DHCP server database is automatically created when the Microsoft DHCP server is installed on a computer running Windows NT Server and the TCP/IP protocol. You add data to the DHCP server database by defining DHCP scopes and DHCP options when using DHCP Manager.

DHCP Scopes

A DHCP scope is an administrative grouping that identifies the configuration parameters for all DHCP clients grouped together on a physical subnet. The scope must be defined before DHCP clients can use the DHCP server for dynamic TCP/IP configuration.

To create a DHCP scope, you must use DHCP Manager to enter the following required information:

  • Scope name assigned by the administrator when the scope is created
  • Unique subnet mask used to identify the subnet to which an IP address belongs
  • Range of IP addresses contained within the scope
  • Time interval (known as lease duration) that specifies how long a DHCP client can use an assigned IP address before it must renew its configuration with the DHCP server

Note

Each subnet can have only one scope with a single continuous range of IP addresses. To use several address ranges within a scope, create a continuous range that encompasses all of the address ranges; then manually exclude the addresses that fall between the specific address ranges. See the section "Using DHCP Manager" later in this chapter for additional information.

In addition to the required DHCP scope information, you can define individual scope options by using DHCP Manager. The following table lists additional scope options:

Table 7.3 Additional Scope Options

Option | Description
Deactivate | You can release an IP address if a computer is removed from a network.
Renewal | You can change the renewal period for IP-address leases. By installation default, DHCP clients begin the renewal process when 50 percent of the IP address lease time has expired.
Reserve | You can reserve a specific IP address for a DHCP client, such as an Internet Information Server or WINS server. An IP address can also be reserved if a computer on the network is not DHCP-enabled. Also, for TCP/IP security, computers designated as network firewalls are configured with reserved IP addresses.

DHCP Options

Other options, known as DHCP options, can also be configured on the DHCP server by using DHCP Manager. In addition to defining the required DHCP Scope configuration parameters, you can use Microsoft DHCP server to automatically assign advanced TCP/IP configuration options, such as a Windows Internet Name Service (WINS) server and a Domain Name System (DNS) server, to DHCP clients. To do this, you select one or more DHCP options when using DHCP Manager.

Microsoft DHCP options can be selected and assigned to a selected scope or to all scopes by clicking either Scope or Global on the DHCP Options menu. When using DHCP options, keep in mind the following guidelines:

  • Active global options always apply unless overridden by Scope options or by manual configuration of a DHCP client.
  • Active options for a scope apply to all computers in that scope, unless overridden by manual configuration of a DHCP client.

Microsoft DHCP server provides the ability to configure many standard DHCP options as defined by RFC 1541. The following table lists the standard DHCP options available when using Microsoft DHCP server.

Note

You can use Microsoft DHCP server to set any of the options described in this table. However, Windows-based and Windows NT-based DHCP clients support only the options whose code and option name are listed in bold type. (If you use Microsoft DHCP server to administer third-party DHCP clients, you can use any option listed in this table that is supported on the third-party DHCP client.)

Table 7.4 Default DHCP Options as Defined by RFC 1541

Code | Option name |  | Meaning
0 | Pad |  | Causes subsequent fields to align on word boundaries.
255 | End |  | Indicates end of options in the DHCP packet.
1 | Subnet mask |  | Specifies the subnet mask of the client subnet. This option is defined in the DHCP Manager Create Scope or Scope Properties dialog box. It cannot be set directly in the DHCP Options dialog box.
2 | Time offset |  | Specifies the Universal Coordinated Time (UCT) offset in seconds.
3 | Router |  | Specifies a list of IP addresses for routers on the client's subnet.*
4 | Time server |  | Specifies a list of IP addresses for time servers available to the client.*
5 | Name servers |  | Specifies a list of IP addresses for name servers available to the client.*
6 | DNS servers |  | Specifies a list of IP addresses for DNS name servers available to the client.* Multihomed computers can have only one list per computer, not one per adapter card.
7 | Log servers |  | Specifies a list of IP addresses for MIT_LCS User Datagram Protocol (UDP) log servers available to the client.*
8 | Cookie servers |  | Specifies a list of IP addresses for RFC 865 cookie servers available to the client.*
9 | LPR servers |  | Specifies a list of IP addresses for RFC 1179 line-printer servers available to the client.*
10 | Impress servers |  | Specifies a list of IP addresses for Imagen Impress servers available to the client.*
11 | Resource Location servers |  | Specifies a list of RFC 887 Resource Location servers available to the client.*
12 | Host name |  | Specifies the host name of up to 63 characters for the client. The name must start with a letter, end with a letter or digit, and have as interior characters only letters, numbers, and hyphens. The name can be qualified with the local DNS domain name.
13 | Boot file size |  | Specifies the size of the default boot image file for the client, in 512-octet blocks.
14 | Merit dump file |  | Specifies the file and directory where the client's core image is dumped if a crash occurs.
15 | Domain name |  | Specifies the DNS domain name that the client should use for DNS host name resolution.
16 | Swap server |  | Specifies the IP address of the client's swap server.
17 | Root path |  | Specifies the ASCII path for the client's root disk.
18 | Extensions path |  | Specifies a file that can be retrieved by using Trivial File Transfer Protocol (TFTP). This file contains information interpreted the same as the vendor-extension field in the BOOTP response, except that the file length is unconstrained and references to Tag 18 in the file are ignored.
19 | IP layer forwarding |  | Enables or disables forwarding of IP packet for this client. 1 enables forwarding; 0 disables it.
20 | Nonlocal source routing |  | Enables or disables forwarding of datagrams with nonlocal source routes. 1 enables forwarding; 0 disables it.
21 | Policy filter masks |  | Specifies policy filters that consist of a list of pairs of IP addresses and masks specifying destination/mask pairs for filtering nonlocal source routes. Any source - routed datagram whose next-hop address does not match a filter will be discarded by the client.
22 | Max DG reassembly size |  | Specifies the maximum size datagram that the client can reassemble. The minimum value is 576.
23 | Default time-to-live |  | Specifies the default time-to-live (TTL) that the client uses on outgoing datagrams. The value for the octet is a number between 1 and 255.
24 | Path MTU aging timeout |  | Specifies the timeout in seconds for aging Path Maximum Transmission Unit (MTU) values (discovered by the mechanism defined in RFC 1191).
25 | Path MTU plateau table |  | Specifies a table of MTU sizes to use when performing Path MTU Discovered as defined in RFC 1191. The table is sorted by size from smallest to largest. The minimum MTU value is 68.
26 | MTU option |  | Specifies the MTU discovery size for this interface. The minimum MTU value is 68.
27 | All subnets are local |  | Specifies whether the client assumes that all subnets of the client's internetwork use the same MTU as the local subnet where the client is connected. 1 indicates that all subnets share the same MTU; 0 indicates that the client should assume some subnets might have smaller MTUs.
28 | Broadcast address |  | Specifies the broadcast address used on the client's subnet.
29 | Perform mask discovery |  | Specifies whether the client should use Internet Control Message Protocol (ICMP) for subnet mask discovery. 1 indicates that the client should perform mask discovery; 0 indicates that the client should not.
30 | Mask supplier |  | Specifies whether the client should respond to subnet mask requests using ICMP. 1 indicates that the client should respond; 0 indicates that the client should not respond.
31 | Perform router discovery |  | Specifies whether the client should solicit routers using the router discovery method specified in RFC 1256. 1 indicates that the client should perform router discovery; 0 indicates that the client should not use it.
32 | Router solicitation address |  | Specifies the IP address to which the client submits router solicitation requests.
33 | Static route |  | Specifies a list of IP address pairs that indicate the static routes the client should install in its routing cache. Any multiple routes to the same destination are listed in descending order or priority. The routes are destination/router address pairs. (The default route of 0.0.0.0 is an illegal destination for a static route.)
34 | Trailer encapsulation |  | Specifies whether the client should negotiate use of trailers (RFC 983) when using the Address Resolution Protocol (ARP). 1 indicates that the client should attempt to use trailers; 0 indicates that the client should not use trailers.
35 | ARP cache timeout |  | Specifies the timeout in seconds for ARP cache entries.
36 | Ethernet encapsulation |  | Specifies whether the client should use Ethernet (as specified by RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is Ethernet. 1 indicates that the client should use RFC 1042 encapsulation; 0 indicates that the client should use RFC 894 encapsulation.
37 | Default time-to-live |  | Specifies the default TTL that the client should use when sending TCP segments. The minimum value of the octet is 1.
38 | Keepalive interval |  | Specifies the interval in seconds that the client TCP should wait before sending a keepalive message on a TCP connection. A value of 0 indicates that the client should not send keepalive messages on connections unless specifically requested by an application.
39 | Keepalive garbage |  | Specifies whether the client should send TCP keepalive messages with an octet of garbage data for compatibility with older implementations. 1 indicates that a garbage octet should be sent; 0 indicates that it should not be sent.
40 | NIS domain name |  | Specifies the name of the Network Information Service (NIS) domain as an ASCII string.
41 | NIS servers |  | Specifies a list of IP addresses for NIS servers available to the client.*
42 | NTP servers |  | Specifies a list of IP addresses for Network Time Protocol (NTP) servers available to the client.1
43 | Vendor-specific information |  | Binary information used by clients and servers to exchange vendor-specific information. Servers not equipped to interpret the information ignore it. Clients that don't receive the information attempt to operate without it.
44 |  | WINS/NBNS servers |  | Specifies a list of IP addresses for NetBIOS name servers (NBNS).*
45 |  | NetBIOS over TCP/IP NBDD |  | Specifies a list of IP addresses for NetBIOS datagram distribution servers (NBDD).*
46 |  | WINS/NBT node type |  | Allows configurable NetBIOS over TCP/IP (NetBT) clients to be configured as described in RFC 1001/1002, where 1 = b-node, 2 = p-node, 4 = m-node, and 8 = h-node. On multihomed computers, the node type is assigned to the entire computer, not to individual adapter cards.
47 |  | NetBIOS scope ID |  | Specifies a text string that is the NetBIOS over TCP/IP Scope ID for the client, as specified in RFC 1001/1002. On multihomed computers, the scope ID is assigned to the entire computer, not to individual adapter cards.
48 |  | X Window system font |  | Specifies a list of IP addresses for X Window font servers available to the client.1
49 |  | X Window system display |  | Specifies a list of IP addresses for X Window System Display Manager servers available to the client.*
51 |  | Lease time |  | Specifies the time in seconds from address assignment until the client's lease on the address expires. Lease time is specified in the DHCP Manager Create Scope or Scope Properties dialog box. It cannot be set directly in the DHCP Options dialog box.
58 |  | Renewal (T1) time value |  | Specifies the time in seconds from address assignment until the client enters the renewing state. Renewal time is a function of the lease time option, which is specified in the DHCP Manager Create Scope or Scope Properties dialog box. It cannot be set directly in the DHCP Options dialog box.
59 |  | Rebinding (T2) time value |  | Specifies the time in seconds from address assignment until the client enters the rebinding state. Rebinding time is a function of the lease time option, which is specified in the DHCP Manager Create Scope or Scope Properties dialog box. It cannot be set directly in the DHCP Options dialog box.
64 |  | NIS + Domain Name |  | Network Information Service (previously known as Yellow Pages) domain name.
65 |  | NIS + Servers |  | Network Information Service (previously known as Yellow Pages) server name.
66 |  | Boot Server Host Name |  | Identifies a Trivial File Transfer Protocol (TFTP) server.
67 |  | Bootfile Name |  | Identifies the file that is to be used as the bootfile.
68 |  | Mobile IP Home Agents |  | Can be used to list (in order of preference) IP addresses that identify mobile IP home agents.

* List is specified in order of preference.
Boldface type indicates those options that Windows-based and Windows NT-based clients support

The Microsoft DHCP network packet allocates 312 bytes for DHCP options. This is more than enough space for most option configurations. With some DHCP servers and clients, you can allocate unused space in the DHCP packet to additional options. This feature, called option overlay, is not supported by Microsoft DHCP server or client. If you attempt to use more than 312 bytes, some options settings will be lost. In that case, you should delete any unused or low-priority options.

Tip

If you are using Microsoft DHCP server to configure computers that should use the services of a WINS server, be sure to use option #44, WINS Servers, and option #46, Node Type. These DHCP options automatically configure the DHCP client as an h-node computer that directly contacts WINS servers for name registration and name query instead of using broadcasts (b-node.)

You can also add custom parameters to be included with DHCP client configuration information and change values or other elements of the predefined DHCP options, as needed.


DHCP Clients

To configure a computer running Windows NT Server or Windows NT Workstation as a DHCP client, select the Obtain an IP address from a DHCP server check box on the IP Address tab of the Microsoft TCP/IP Properties page. A DHCP server can also be used to configure computers running under following operating systems:

  • Windows 95
  • Windows for Workgroups version 3.11 with the Microsoft 32-bit TCP/IP VxD installed
  • Microsoft – Network Client version 3.0 for MS-DOS with the real-mode TCP/IP driver installed
  • LAN Manager version 2.2c

Table 7.5 describes the basic TCP/IP configuration parameters that a DHCP server must provide to DHCP clients.

Table 7.5 Required TCP/IP Configuration Parameters for DHCP Clients

Basic TCP/IP configuration parameters | Description
IP address | Every device attached to a TCP/IP network is identified by a unique IP address. (If the computer has multiple network adapter cards, it will require multiple IP addresses.) The IP address is a numeric identifier comprised of four 8-bit octets separated by periods. (This number is generally shown in dotted-decimal notation, for example, 172.16.32.1) The IP address is actually two parts: the first part represents a network ID and the second part represents a host (computer) ID.
Subnet mask | Used to identify the part of the unique IP address that is the network identifier and the part that is the host identifier. Subnet masks are created by assigning 1s to network ID bits and 0s to the host ID bits of the IP address.
Default gateway | The computer (router) connected to the local subnet and other subnets that is used to pass IP packets from one subnet to another. (A default gateway is required only when the client is located on a routed TCP/IP network.)

Initial DHCP Client Configuration

When a DHCP client computer is started on a TCP/IP network, it communicates with a DHCP server to get its TCP/IP configuration information. The following table describes the DHCP message types exchanged between client and server.

Table 7.6 DHCP Message Types

Message type | Description
Dhcpdiscover | The first time a DHCP client computer attempts to start on the network, it requests IP address information from a DHCP server by broadcasting a Dhcpdiscover packet. The source IP address in the packet is 0.0.0.0 because the client does not yet have an IP address.
Dhcpoffer | When the DHCP server receives the request, it selects an unleased IP address from the range of available IP addresses and offers it to the DHCP client. In most cases, the DHCP server also returns additional TCP/IP configuration information, such as the subnet mask and default gateway in a Dhcpoffer packet. More than one DHCP server can respond with a Dhcpoffer packet, and the client accepts the first Dhcpoffer it receives.
Dhcprequest | When a DHCP client receives a Dhcpoffer packet, it responds by broadcasting a Dhcprequest packet that contains the offered IP address.
Dhcpdecline | A message from the DHCP client to the server indicating that the offered configuration parameters are invalid.
Dhcpack | The DHCP server acknowledges the client Dhcprequest for the IP address by sending a Dhcpack packet.
Dhcpnack | If the IP address cannot be used by the client because it is no longer valid or is now used by another computer, the DHCP server will respond with a Dhcpnack packet.
Dhcprelease | A message from the DHCP client to the server that releases the IP address and cancels any remaining lease.

When the DHCP server receives the request from the DHCP client computer, it dynamically assigns an IP address to the requesting computer from the range of valid IP addresses contained within the DHCP scope. The DHCP server allocates the IP address with a lease that defines how long the IP address is usable by the client computer. The DHCP server can also establish other configuration parameters, such as subnet mask and DNS and WINS server identification, for the client computer.

If the DHCP client has previously been assigned an IP address by the DHCP server or by manual configuration, the client sends a Dhcprequest packet. The following figure illustrates this process.

Figure 7.1 DHCP Client and Server Interaction During System Startup

Note

The client accepts the first offer it receives, regardless of whether the offer came from a DHCP server on the local subnet or from a DHCP server on a different subnet.

When a client accepts an IP address, and any other configuration information offered by the DHCP server, the client saves the configuration in the following Registry keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services: Network interface specific: <adapter>\parameters\Tcpip General: Dhcp\parameters\options\*

IP addressing information is leased to a client until the client manually releases the address, or until the DHCP server cancels the lease and makes the address available to other computers on the network.

If a client does not receive a Dhcpoffer packet from a DHCP server, it will broadcast a request four times, at 2- ,4- ,8- , and 16-second intervals (plus a random amount between 0 and 1,000 milliseconds). If the client does not receive a response after four attempts, it will cease trying and retry again in five minutes. In the case where the DHCP server is unavailable or there is no available IP addressing information to lease to a client computer, the client is unable to bind to TCP/IP.

Restarting a DHCP Client

When a client computer restarts and logs on to the network, it broadcasts a Dhcprequest packet instead of a Dhcpdiscover packet. The Dhcprequest packet contains a request for the previously assigned IP address. The DHCP server will attempt to allow the client to retain the same IP address, and will respond with a Dhcpack packet. If the IP address cannot be used by the client because it is no longer valid, or is now used by another computer, the DHCP server will respond with a Dhcpnack packet. The client that receives a Dhcpnack response must restart the configuration process by sending a Dhcpdiscover request.


DHCP/BOOTP Relay Agents

TCP/IP networks are interconnected by routers that connect network segments (subnets) and pass IP packets between the subnets. As mentioned earlier, one of the major components of the DHCP specification is the DHCP protocol for communications between DHCP servers and clients.

A DHCP server can provide IP addresses to clients in multiple subnets if the router that connects the subnets is an RFC 1542-compliant router. RFC 1542 specifies the DHCP/BOOTP relay agent. If the router cannot function as a relay agent, each subnet that has DHCP clients requires a DHCP server.

A relay agent is a program used to pass specific types of IP packets between subnets. A DHCP/BOOTP relay agent is simply a hardware or software program that can pass DHCP/BOOTP messages (packets) from one subnet to another subnet according to the RFC 1542 specification.


Planning for DHCP Implementation

This section describes how to develop strategies for implementing DHCP servers in small LANs or large routed networks. Most network administrators implementing DHCP will also be planning a strategy for implementing WINS servers. The planning tasks described here also apply to WINS servers. In fact, the administrator will probably want to plan DHCP and WINS implementation in tandem.

Note

If you use DHCP servers, you must use WINS servers so that the dynamic IP addressing of DHCP clients can be dynamically updated in name- to- IP- address mappings.

Before you install Microsoft DHCP servers on your network, consider the following recommendations:

  • The general guideline for determining how many DHCP servers are needed in a network is that one online DHCP server and one backup DHCP server (a hot standby) can support 10,000 clients. However, when deciding how many DHCP servers you will need, consider the location of routers on the network and whether you will want a DHCP server in each subnet.
  • To determine where to install the DHCP servers, use the physical characteristics of your LAN or WAN infrastructure and not the logical groupings defined in the Windows NT domain concepts. When subnets are connected by RFC 1542-compliant routers, DHCP servers are not required on every subnet on the network. Note that DHCP servers can be administered remotely from a computer running under Windows NT Server that is DHCP- or WINS-enabled.
  • Compile a list of requirements including:
    • Client support (numbers and kinds of systems to be supported)
    • Interoperability with existing systems (including your requirements for mission-critical accounting, personnel, and similar information systems)
    • Hardware support and related software compatibility (including routers, switches, and servers)
    • Network monitoring software, including Simple Network Management Protocol (SNMP) and other tools
  • Isolate the areas of the network where processes must continue uninterrupted, and then target these areas for the last stages of implementation.
  • Review the geographic and physical structure of the network to determine the best plan for defining logical subnets as segments of the intranet.
  • Define the components in the new system that require testing, and then develop a phased plan for testing and adding components.

For example, the plan could define the order for types of computers to be phased in (including Windows NT servers and workstations, Microsoft RAS servers and clients, Windows for Workgroups computers, and MS-DOS clients).

  • Create a pilot project for testing.
  • Create a second test phase, including tuning the DHCP (and WINS) server-client configuration for efficiency.

This task can include determining strategies for backup servers and for partitioning the address pool at each server to be provided to local versus remote clients.

  • Document all architecture and administration issues for network administrators.


Planning for Small Networks

In a small LAN that does not include routers and subnetting, a single DHCP server could be used to service all DHCP clients as illustrated in the following figure.

Figure 7.2 A Single Local Network Using Automatic TCP/IP Configuration with DHCP

Before installing the DHCP server you will need to identify:

  • Which computers can immediately be configured as DHCP clients for dynamic TCP/IP configuration and which computers should be manually configured with static TCP/IP configuration parameters including static IP addresses.
  • The DHCP option types and their values to be predefined for the DHCP clients.


Planning for DHCP in Routed Networks

A router is a TCP/IP gateway computer that has two or more network adapter cards (NICs). Each adapter is connected to a different physical network (a subnet). A router device provides services that are determined by the hardware and software configuration of the computer that serves as the router.

Routers that implement the DHCP/BOOTP relay agent as specified by RFC 1542 can be used to route traffic between DHCP servers and clients located on different subnets. The relay agent on the router forwards requests from local DHCP clients to the remote DHCP server and subsequently relays the DHCP server responses back to the DHCP clients. The following figure illustrates an example of a routed network with DHCP server and DHCP clients.

Figure 7.3 An Internetwork Using Automatic TCP/IP Configuration with DHCP

Windows NT Server version 4.0 includes Multi-Protocol Router (MPR), which is a software router that can be configured on a general purpose computer to provide DHCP/BOOTP relay agent support. MPR includes:

  • BOOTP relay agent for DHCP
  • Routing Information Protocol (RIP) for TCP/IP
  • Routing Information Protocol for IPX

Note

Windows NT supports DHCP but does not support BOOTP. You can use Microsoft DHCP server on the same network with clients and servers running BOOTP. The Windows NT-based DHCP servers simply ignore any BOOTP client packets that they may receive from the network. You must make sure, however, that the BOOTP server and the DHCP server do not manage leases for the same IP addresses. The best way to ensure that there is no overlap in managed addresses is to define the scope of the DHCP server as the entire address range that is managed by both the DHCP server and the BOOTP server, and then exclude the address range that is managed by the BOOTP server. As BOOTP clients are dropped or upgraded to DHCP, the exclusion range can be adjusted accordingly.

Additional planning issues for a large enterprise network are:

  • Ensuring the compatibility of hardware and software routers with DHCP.
  • Planning the physical subnetting of the network and relative placement of DHCP servers. This includes planning for placement of DHCP (and WINS) servers among subnets in a way that reduces b-node broadcasts across routers.
  • Specifying the DHCP option types and their values to be predefined per scope for the DHCP clients. This might include planning for scopes based on the needs of particular groups of users. For example, for a marketing group that uses portable computers docked at different stations, or for a unit that frequently moves computers to different locations, shorter lease durations can be defined for the related scopes. This way, frequently changed IP addresses can be freed for reuse.

As one example of planning for a large enterprise network, the segmenting of the WAN into logical subnets could match the physical structure of the internetwork. Then one IP subnet can serve as the backbone, and off this backbone each physical subnet would maintain a separate IP subnet address.

In this case, for each subnet a single computer running Windows NT Server could be configured as both the DHCP and WINS server. Each server would administer a defined number of IP addresses with a specific subnet mask, and would also be defined as the default gateway. Because the server is also acting as the WINS server, it can respond to name resolution requests from all systems on its subnet.

These DHCP and WINS servers can in turn be backup servers for each other. The administrator can partition the address pool for each server to provide addresses to remote clients.

There is no limit to the maximum number of clients that can be served by a single DHCP server. However, your network can have practical constraints based on the IP address class, and server configuration issues such as disk capacity and CPU speed.


Planning for DHCP Traffic

DHCP client and server TCP/IP configuration traffic does not use significant network bandwidth during normal periods of usage. However, there are two phases of DHCP client configuration that do generate some network traffic load. These phases are:

  • IP Address Lease
  • IP Address Renewal

IP Address Lease

When a new client initializes TCP/IP for the first time (and is configured as a DHCP client), its first step is to acquire an IP address using DHCP. This process results in a conversation between the DHCP client and server consisting of four packets, the first of which is the client computer broadcasting a Dhcpdiscover packet in an attempt to locate a DHCP server.

DHCP Discover

The Dhcpdiscover frame will be either 342 or 590 bytes total. (Older versions of Windows for Workgroups TCP/IP stack, TCP/IP-32 3.11a, as well as Windows NT 3.5, used 590-byte frames.) The first 14 bytes constitute the Ethernet header portion of the packet. The first distinguishing characteristic is the destination address, which is the Ethernet broadcast address of 255.255.255.255. The client computer has no knowledge of where any DHCP servers reside, and so it initiates a broadcast which is an Ethernet Type 0800 frame (IP).

The next 20 bytes are the IP header portion of the packet. The interesting things to note are the source and destination addresses. The source address is 0.0.0.0; because the client does not yet have a valid IP address, it initializes with an address of 0.0.0.0. The destination address is 255.255.255.255, which is the IP network broadcast address. As with the Ethernet header, the client does not know the location or address of any DHCP servers, and so it initiates an IP broadcast.

DHCP is a UDP-based protocol, and so the next 8 bytes are the UDP header. The UDP source and destination ports are both BOOTP (68 and 67, respectively). DHCP is an extension of the BOOTP protocol, and thus uses its ports for messaging.

The remainder of the frame contains the Dhcpdiscover packet components. The majority of the remaining fields are either zeros or blank, because the client has no knowledge of any IP addresses or parameters. Upon examining the DHCP Option Field section, you will notice the Client Identifier, which is its MAC address, and its Host name. These are added to the frame in the event that a DHCP server may have a reserved address for the client which is identified by its MAC address.

The host will broadcast up to four Dhcpdiscover messages in an attempt to find a DHCP server. If, after four attempts, a server cannot be located, the computer will cease trying, and then attempt to locate a DHCP server every five minutes until it is successful.

DHCP Offer

Once a DHCP server has received the Discover packet, and determined that it can accommodate the client's request, it responds with a Dhcpoffer message. The Dhcpoffer frame is 342 bytes total. The first 14 bytes constitute the Ethernet header portion of the packet. The first distinguishing characteristic is the destination address, which is the Ethernet broadcast address of 255.255.255.255. The server responds to the client with a broadcast which is an Ethernet Type 0800 frame (IP).

The next 20 bytes are the IP header portion of the packet. The interesting things to note are the source and destination addresses. The source address is that of the DHCP server, and the destination address is 255.255.255.255, which is the IP network broadcast address. As with the Ethernet header, the client responds with an IP broadcast.

DHCP is a UDP-based protocol, and so the next 8 bytes are the UDP header. The UDP source and destination ports are both BOOTP (67 and 68, respectively).

The remainder of the frame (300 bytes) contains the Dhcpoffer packet components. The new items configured are Your IP address, which is set to the proposed address for the client, and proposals for the IP address lease time (including renewal periods). The DHCP server's IP address is also listed here.

DHCP Request

The Dhcprequest frame will be either 342 or 590 bytes total, depending on the size of the Dhcpdiscover message. The first 14 bytes constitute the Ethernet header portion of the packet. The first distinguishing characteristic is the destination address, which is the Ethernet broadcast address of 255.255.255.255. The client computer knows the address of the server it is accepting its address from, but responds with a broadcast to let all DHCP servers know that it has selected an address from a specific server. It is an Ethernet Type 0800 frame (IP).

The next 20 bytes are the IP header portion of the packet. The interesting things to note are the source and destination addresses. The source address is 0.0.0.0; because the client does not yet have a valid IP address, it initializes with an address of 0.0.0.0. The destination address is 255.255.255.255, which is the IP network broadcast address. As with the Ethernet header, the client initiates an IP broadcast to let all DHCP servers accept the frame, and learn that it has accepted an offer.

DHCP is a UDP-based protocol, and so the next 8 bytes are the UDP header. The UDP source and destination ports are both BOOTP (68 and 67, respectively).

The remainder of the frame contains the Dhcprequest packet components. The majority of the remaining fields are either zeros or blank, because the client has no knowledge of any IP addresses or parameters. Upon examining the DHCP Option Field section, you will notice the Requested address, which is the IP address the client is requesting, and a Server Identifier (IP address of the server the request is being made of). These are added to the frame so that other DHCP servers are notified that the client has accepted an offer from a specific server, and they can offer the address they offered to this client to another DHCP client.

DHCP ACK

Once a DHCP server has received the Request packet, it responds with a Dhcpack message. The Dhcpack frame is 342 bytes total. The first 14 bytes constitute the Ethernet header portion of the packet. The first distinguishing characteristic is the destination address, which is the Ethernet broadcast address of 255.255.255.255. The server responds to the client with a broadcast. It is an Ethernet Type 0800 frame (IP).

The next 20 bytes are the IP header portion of the packet. The interesting things to note are the source and destination addresses. The source address is that of the DHCP server, and the destination address is 255.255.255.255, which is the IP network broadcast address. As with the Ethernet header, the client responds with an IP broadcast.

DHCP is a UDP-based protocol, and so the next 8 bytes are the UDP header. The UDP source and destination ports are both BOOTP (67 and 68, respectively).

The remainder of the frame contains the Dhcpack packet components. Your IP address, which is set to the proposed address for the client, is still configured, and parameters, such as IP Lease Time, and renewal and rebinding times, as well as other DHCP options, such as Router, NetBIOS Name Server address, NetBIOS Node Type, and so on, are listed in the Option Field portion of the frame. This portion will be variable, depending on the options requested from the client and those returned by the server.

IP Address Renewal

Whenever a DHCP client starts, it must renew its IP address with its DHCP server. When renewing an IP address using DHCP, the conversation is a simple one consisting of the last two packets of the IP address lease phase. The client computer will request a renewal of its current IP address with a Dhcprequest packet and, if successful, the DHCP server responds with a Dhcpack packet.

The only difference between the Dhcprequest and Dhcpack packets for a renewal and those of the acquisition is that the conversation is directed, and not broadcast, because the client and server already know about each other. Additionally, any new DHCP options, such as Domain Name Server address, that have been configured since the client acquired the IP address lease, are now sent to the client computer.

DHCP clients also renew their IP address lease at one-half of the TTL, which is a configurable length. At this time, the client issues a Dhcprequest packet to its DHCP server, and the server will respond with a Dhcpack, if the address is still valid for the client.

The DHCP client will retry its renewal attempt one time. If unsuccessful, it will try again at the next renewal period.

Summary of DHCP Traffic

To recap, the entire process of acquiring an IP address lease through DHCP takes a total of four packets, varying between 342 and 590 bytes in size. This process, on a clean network (no other network traffic using bandwidth), takes less than 1 second (about 300 milliseconds).

DHCP conversations generally occur in the following instances:

  • When a DHCP client initializes for the first time (all four frames).
  • When an automatic renewal, which is only done every one-half lease life (three days by default, so every 18 hours), takes two packets (Dhcprequest and Dhcpack) and approximately 200 milliseconds.
  • When a client is moved to a new subnet (Dhcprequest, Dhcpnack, then the four frames as if it is a new client).
  • When a DHCP client replaces its network adapter card (all four frames).
  • Whenever a client manually refreshes or releases its address by using the ipconfig utility.

This process should not have a significant effect on network traffic, even if multiple DHCP clients are acquiring or renewing addresses simultaneously.

Planning Guideline for DHCP Traffic

DHCP does not normally have a big impact on network traffic. If you wish to reduce the amount of traffic generated by DHCP, it is possible to adjust the lease duration for IP address leases. This is done using DHCP Manager, and adjusting Lease Duration in the Scope Properties dialog box.

As noted earlier, the default lease duration is three days, which would cause each client to attempt to renew their lease every 18 hours from the time the client acquired the address. A lease renewal is only two packets, with a maximum totoal size of 932 bytes.


Setting Local Policies

This section provides some suggestions for setting lease options, dividing the free address pool among DHCP servers, and preventing DNS naming problems.

Managing DHCP Addressing Policy

Allocation of IP addresses for distribution by DHCP servers can be done dynamically or manually. These methods use the same DHCP client-server protocol, but the network administrator manages them differently at the DHCP server end.

Dynamic Allocation of IP Addresses

Dynamic allocation enables a client to be assigned an IP address from the free address pool. The lease for the address has a lease duration (expiration date), before which the client must renew the lease to continue using that address. Depending on the local lease policies defined by the administrator, dynamically allocated addresses can be returned to the free address pool if the client computer is not being used, if it is moved to another subnet, or if its lease expires. Any IP addresses that are returned to the free address pool can be reused by the DHCP server when allocating an IP address to a new client. Usually, the local policy ensures that the same IP address is assigned to a client each time that it starts.

After the renewal time of the lease duration has passed, the DHCP client enters the renewing state. The client sends a request message to the DHCP server that provided its configuration information. If the request for a lease extension fits the local lease policy, the DHCP server sends an acknowledgment that contains the new lease and configuration parameters. The client then updates its configuration values and returns to the bound state.

When the DHCP client is in the renewing state, it must release its address immediately in the rare event that the DHCP server sends a negative acknowledgment. The DHCP server sends this message to inform a client that it has incorrect configuration information, forcing it to release its current address and acquire new information.

If the DHCP client cannot successfully renew its lease, the client enters a rebinding state. At this stage, the client sends a request message to all DHCP servers in its range, attempting to renew its lease. Any server that can extend the lease sends an acknowledgment containing the extended lease and updated configuration information. If the lease expires or if a DHCP server responds with a negative acknowledgment, the client must release its current configuration, and then return to the initializing state. (This happens automatically, for example, for a computer that is moved from one subnet to another.)

If the DHCP client uses more than one network adapter to connect to multiple networks, this protocol is followed for each adapter that the user wants to configure for TCP/IP. Windows NT allows multihomed systems to selectively configure any combination of the system's interfaces. You can use the ipconfig utility to view the local IP configuration for a client computer.

When a DHCP-enabled computer is restarted, it sends a message to the DHCP server with its current configuration information. The DHCP server either confirms this configuration or sends a negative reply so that the client must begin the initializing stage again. System startup might, therefore, result in a new IP address for a client computer, but neither the user nor the network administrator has to take any action in the configuration process.

Before loading TCP/IP with an address acquired from the DHCP server, DHCP clients check for an IP address conflict by sending an Address Resolution Protocol (ARP) request containing the address. If a conflict is found, TCP/IP does not start, and then the user receives an error message. The conflicting address should be removed from the list of active leases or it should be excluded until the conflict is identified and resolved.

Managing Lease Options

To define appropriate values for lease duration, consider the frequency of the following events for your network:

  • Changes to DHCP options and default values
  • Network interface failures
  • Computer removals for any purpose
  • Subnet changes by users because of office moves, laptop computers docked at different workstations, and so on

All of these types of events cause IP addresses to be released by the client or cause the leases to expire at the DHCP server. Consequently, the IP address is returned to the free address pool to be reused.

If many changes occur on your internetwork, you should assign short lease times, such as two weeks. This way, the addresses assigned to systems that leave the subnet can be reassigned quickly to new DHCP client computers requesting TCP/IP configuration information.

Another important factor to consider is the ratio between connected computers and available IP addresses. For example, the demand for reusing addresses is low on a network where 40 systems share a class C address (with 254 available addresses). A long lease time, such as two months, would be appropriate in such a situation. However, if 230 computers share the same address pool, demand for available addresses is much greater, and so a lease time of a few days or weeks is more appropriate.

Notice, however, that short lease durations require that the DHCP server be available when the client seeks to renew the lease. Backup servers are especially important when short lease durations are specified.

Although infinite leases are allowed, they should be used with great caution. Even in a relatively stable environment, there is a certain amount of turnover among clients. At a minimum, portable computers might be added and removed, desktop computers might be moved from one office to another, and network adapter cards might be replaced. If a client with an infinite lease is removed from the network, the DHCP server is not notified, and then the IP address cannot be reused. A better option is a very long lease duration, such as six months. A long lease duration ensures that addresses are ultimately recovered.


Partitioning the Address Pool

You will probably decide to install more than one DHCP server, so that the failure of any individual server will not prevent DHCP clients from starting. However, DHCP does not provide a way for DHCP servers to cooperate in ensuring that assigned addresses are unique. Therefore, you must divide the available address pool among the DHCP servers to prevent duplicate address assignment.

A typical scenario is where a local DHCP server maintains TCP/IP configuration information for two subnets. For each DHCP server, the network administrator allocates 70 percent of the IP address pool for local clients and 30 percent for clients from the remote subnet, and then configures a relay agent to deliver requests between the subnets.

This scenario allows the local DHCP server to respond to requests from local DHCP clients most of the time. The remote DHCP server will assign addresses to clients on the other subnet only when the local server is not available or is out of addresses. This same method of partitioning among subnets can be used in a multiple subnet scenario to ensure the availability of a responding server when a DHCP client requests configuration information.


Using DHCP with DNS Servers

Domain Name System (DNS) servers can be used to provide names for network resources. However, there is no current IETF specification for dynamically updating DNS servers such as when a DHCP client is dynamically configured with an IP address and other TCP/IP configuration parameters. Therefore, DNS naming conflicts can occur if you are using a DHCP server for dynamic assignment of client IP addresses.

This problem primarily affects systems that extend internetworking services to local network users. For example, a server acting as an anonymous FTP server or as an electronic mail gateway might require users to contact it using DNS names. In such cases, clients should have reserved leases with an unlimited duration.

For workstations in environments that do not require the computers to register in the DNS name space, DHCP dynamic allocation can be used without problems.


Using DHCP Manager

When you install Microsoft DHCP server, the graphical user-interface, DHCP Manager, is automatically installed and added to the Administrative Tools (Common) programs group. You use DHCP Manager to configure and monitor remote and local DHCP servers.

You can use DHCP Manager to view and change parameters for Microsoft DHCP servers on the network for which you have administrator privileges. DHCP Manager Help is organized to provide information for each of the specific administration and configuration tasks that you need to perform to manage DHCP servers. See DHCP Manager Help for specific tasks details.

To start DHCP Manager

· Click Start, point to Programs, point to Administrative Tools (Common), and then click DHCP Manager.


Managing the DHCP Server Database

The DHCP server database under Windows NT Server version 4.0 uses the performance-enhanced Exchange Server storage engine version 4.0. When you install Microsoft DHCP server, the files shown in the following table are automatically created in the \systemroot\System32\Dhcp directory.

Table 7.7 Microsoft DHCP Server Database Files

File | Description
Dhcp.mdb | The DHCP server database file.
Dhcp.tmp | A temporary file used by the DHCP database as a swap file during database index maintenance operations. This file may remain in the \systemroot\System32\Dhcp directory after a crash.
J50.log and J50#####.log | A log of all database transactions. This file is used by the DHCP database to recover data if necessary.
J50.chk | A checkpoint file.

Important

The J50.log file, J50#####.log file, Dhcp.mdb file, and Dhcp.tmp file should not be removed or tampered with in any manner.

As previously discussed, the DHCP server database is a dynamic database that is updated as DHCP clients are assigned, or release, their TCP/IP configuration parameters. Because the DHCP database is not a distributed database like the WINS server database, maintenance of the DHCP server database is less complex.

The DHCP database and related Registry entries are backed up automatically at a specific interval (15 minutes by installation default). This installation default can be changed by changing the value of the Registry parameter BackupInterval in the Registry key:

SYSTEM\current\currentcontrolset\services\DHCPServer\Parameters


Troubleshooting DHCP Server

The following error conditions indicate potential problems with the DHCP server:

  • The administrator can't connect for a DHCP server by using DHCP Manager. The message that appears might be "The RPC server is unavailable."
  • DHCP clients cannot renew the leases for their IP addresses. The message that appears on the client computer is "The DHCP client could not renew the IP address lease."
  • The DHCP Client service or Microsoft DHCP Server service might be stopped and cannot be restarted.

The first troubleshooting task is to make sure that the DHCP services are running. Open Services in Control Panel to verify that the DHCP services are running. "Started" should appear in the Status column for the DHCP Client service and "Started" should appear in the Status column for the Microsoft DHCP Server service. If the appropriate service is not started, start the service.

In rare circumstances, a DHCP server cannot start or a STOP error might occur. If the DHCP server is stopped, complete the following procedure to restart it.

To restart a DHCP server that is stopped

1. Turn off the power to the server, and then wait about one minute.

2. Turn on the power, start Windows NT Server, and then log on under an account with Administrator rights.

3. At the command prompt, type net start dhcpserver, and then press Enter.

Note

Use Event Viewer in the Administrative tools to find the possible source of problems with DHCP services.


Using IPCONFIG

Ipconfig is a TCP/IP utility that you can use at the command prompt. You can use the ipconfig command to get information about the configured TCP/IP parameters on local or remote computers on the network.

For more information on how to use the ipconfig command, see the topic "TCP/IP Procedures Help" in Control Panel Help.


Upgrading the DHCP Database to Windows NT Server Version 4.0

When upgrading a Windows NT Server version 3.51 (or earlier) release to Windows NT 4.0, the DHCP database must be converted to the new database format. This is required because the services now use an improved database engine that is faster and that compacts automatically to prevent fragmentation and consequent growth of the database. The database conversion procedure happens automatically as part of an upgrade installation.

Database Conversion Procedure

When the DHCP service first starts after an upgrade to Windows NT 4.0, it detects that the database needs to be converted. It then starts a conversion process, Jetconv.exe. (If Jetconv.exe has already been started by another service, a second Jetconv.exe process is not started.) Prior to conversion, the user is notified that the conversion process is about to start and is asked for confirmation. If the user clicks OK, the DHCP service terminates and the conversion begins. Jetconv.exe converts the databases of all the installed services (DHCP and if installed WINS and RPL) to the new Windows NT 4.0 database format.

After the DHCP database is converted successfully, the DHCP Server service is automatically restarted.

Before starting the conversion process, note the following guidelines:

  • Prior to upgrading to Windows NT Server 4.0, bring the Windows NT 3.51 databases for the DHCP server to a consistent state. Do this by terminating the services, either by using Service in Control Panel or by using the net stop service command. This is recommended because it prevents the Jetconv.exe conversion from failing due to an inconsistent Windows NT 3.51 database.
  • The conversion requires approximately the same amount of free disk space as the size of the original database and log files. You should have at least 5 MB free for the log files for each database.
  • The conversion process preserves the original database and log files in a subdirectory named 351db under the same directory where the original database and log files were located. On the DHCP server, this is the systemroot\System32\dhcp\351db\ directory. The administrator can later remove these files to reclaim the disk space.

The database conversion can take anywhere from a minute to an hour depending on the size of the database. The user must not try to restart the services while the databases are being converted. To check the status of the conversion, the user should watch the Application Event Log of the Jetconv.exe process by using Event Viewer.

In case this automatic procedure of converting databases fails for some reason (as can be determined from the event logs), the database that couldn't be converted can be converted manually using winntdir\system32\upg351db.exe. At the command line, type upg351db -? for instructions.

Note the following information:

  • You cannot convert the new database back to the previous database format.
  • The converted database will not work with Windows NT 3.51 or earlier services.
  • The new database engine uses log files named by using the prefix J50.


Restoring the DHCP Database

If you determine that the DHCP services are running on both the client and server computers but the error conditions described earlier under "Troubleshooting DHCP Server" persist, then the DHCP database is not available or has become corrupted. If a DHCP server fails for any reason, you can restore the database from a backup copy.

To restore a DHCP database

1. Before starting, make a copy of the DHCP server database files.

2. In the \systemroot\System32\Dhcp directory, delete the J50.log, J50#####.log, and Dhcp.tmp files.

3. Copy an uncorrupted backup version of the Dhcp.mdb to the \systemroot\System32\Dhcp directory.

4. Restart the Microsoft DHCP Server service.

Restarting and Rebuilding a Stopped DHCP Server

In rare circumstances, the DHCP server may not start or a STOP error might occur. If the DHCP server is stopped, use the following procedure to restart it.

To restart a DHCP server that is stopped

1. Turn off the power to the server and wait at least 15 seconds.

2. Turn on the power, start Windows NT Server, and then log on under an account with Administrator rights.

3. At the command prompt, type the net start dhcp command, and then press Enter.

If the hardware for the DHCP server is malfunctioning or other problems prevent you from running Windows NT, you must rebuild the DHCP database on another computer.

To rebuild a DHCP server

1. If you can start the original DHCP server by using the net start DHCP command, use a copy command to make backup copies of the files in the \systemroot\System32\Dhcp directory. If you cannot start the computer at all, you must use the last backup version of the DHCP database files.

2. Install Windows NT Server and Microsoft TCP/IP to create a new DHCP server using the same hard-drive location and \systemroot directory.

That is, if the original server stored the DHCP files on C:\Winnt\System32\Dhcp, then the new DHCP server must use this same path to the DHCP files.

3. Make sure the Microsoft DHCP Server service on the new server is stopped, and then use the Registry Editor to restore the DHCP keys from backup files.

4. Copy the DHCP backup files to the \systemroot\System32\Dhcp directory.

5. Restart the new, rebuilt DHCP server.

Moving the DHCP Server Database

You may find a situation where you need to move a DHCP database to another computer. To do this, use the following procedure.

To move a DHCP database

1. Stop the Microsoft DHCP Server on the current computer.

2. Copy the \System32\Dhcp directory to the new computer that has been configured as a DHCP server.

Make sure the new directory is under exactly the same drive letter and path as on the old computer.

If you must copy the files to a different directory, copy Dhcp.mdb, but do not copy the .log of .chk files.

3. Start the Microsoft DHCP Server on the new computer.

The service automatically starts using the .mdb and .log files copied from the old computer.

When you check DHCP Manager, the scope still exists because the Registry holds the information on the address range of the scope, including a bitmap of the addresses in use. You need to reconcile the DHCP database to add database entries for the existing leases in the address bitmask. As clients renew, they are matched with these leases, and eventually the database is once again complete.

To reconcile the DHCP database

1. On the Scope menu, click Active Leases.

2. In the Active Leases dialog box, click Reconcile.

Although it is not required, you can force DHCP clients to renew their leases in order to update the DHCP database as quickly as possible. To do so, type ipconfig/renew at the command prompt.


Compacting the DHCP Server Database

Windows NT Server 4.0 is designed to automatically compact the DHCP database and normally you should not need to run this procedure. However, if you are using Windows NT Server versions 3.51 or earlier, after DHCP has been running for a while, the database might need to be compacted to improve DHCP performance. You should compact the DHCP database whenever it approaches 30 MB.

You can use the Jetpack.exe utility provided with Windows NT Server version 3.5 and 3.51 to compact a DHCP database. Jetpack.exe is a command-line utility that is run in the Windows NT Server command window. The utility is found in the \%Systemroot\System32 directory.

The Jetpack.exe syntax is:

Jetpack.exe <database name> <temp database name>

For example:

> CD %SYSTEMROOT%\SYSTEM32\DHCP > JETPACK DHCP.MDB TMP.MDB

In the preceding example, Tmp.mdb is a temporary database that is used by Jetpack.exe. Dhcp.mdb is the DHCP server database file.

When Jetpack.exe is started, it performs the following tasks:

1. Copies database information to a temporary database file called Tmp.mdb.

2. Deletes the original database file, Dhcp.mdb.

3. Renames the temporary database file to the original filename.

To compact the DHCP database

1. In Control Panel, double-click Services.

2. Under Service, click Microsoft DHCP Server.

3. Click Stop, and then click Close. (Alternatively, you can type net stop DHCP at the command prompt.)

4. At the command prompt, run the Jetpack.exe program as previously described.

5. Restart the DHCP Server service by using the Services dialog box.


Chapter 8 - Managing MS WINS Servers

Microsoft Windows Internet Name Service (WINS) is an RFC-compliant NetBIOS name- to-IP-address mapping service. WINS allows Windows-based clients to easily locate resources on Transmission Control Protocol/Internet Protocol (TCP/IP) networks. WINS servers maintain databases of static and dynamic resource name—to-IP-address mappings. Because the Microsoft WINS database supports dynamic name and IP address entries, WINS can be used with Dynamic Host Configuration Protocol (DHCP) services to provide easy configuration and administration of Windows-based TCP/IP networks.

The information in this chapter is intended for network administrators and support personnel who need information about WINS and how to plan, manage, and troubleshoot WINS services. The following topics are included in this chapter:

  • Introduction to Windows Internet Name Service (WINS)
    • Microsoft WINS servers
    • Microsoft WINS server push and pull partners
    • Microsoft WINS clients
    • Microsoft WINS proxies
  • Planning for Microsoft WINS server implementation
  • Using WINS Manager
    • Viewing WINS server operational status
    • Configuring WINS server and WINS client behavior
    • Managing static NetBIOS computer name—to-IP-address mappings
    • Special names for static entry types
    • Managing the WINS server database
  • Troubleshooting WINS servers and databases


Introduction to Windows Internet Name Service

NetBIOS is a session-level interface used by programs to communicate over NetBIOS- compatible transports, including TCP/IP. One function of the NetBIOS interface is to establish logical names for networking programs.

Microsoft Windows Internet Name Service (WINS) is compliant with RFC 1001 and RFC 1002. Microsoft WINS is designed to provide a flexible solution to the problem of locating NetBIOS resources in routed, TCP/IP-based networks.

When using TCP/IP to communicate on a network, a "friendly" Windows-based NetBIOS computer name, such as "mycomputer," must be resolved to an IP address. This is necessary because TCP/IP requires an IP address, such as 172.16.48.1, to establish a connection to a network device. Several different name resolution methods provide NetBIOS name resolution. These methods include:

  • IP broadcasts
  • Static mapping files (LMHOSTS and DNS-based HOSTS files)
  • NetBIOS name server (in Windows NT-based networks, this is the Microsoft WINS server)
  • Domain Name System server (in Windows NT-based networks, this is the Microsoft DNS Server)


Microsoft WINS Servers

WINS servers are designed to prevent the administrative difficulties that are inherent in the use of both IP broadcasts and static mapping files such as LMHOSTS files. Microsoft WINS is designed to eliminate the need for IP broadcasts (which use valuable network bandwidth and cannot be used in routed networks), while providing a dynamic, distributed database that maintains computer name-to-IP-address mappings.

WINS servers use a replicated database that contains NetBIOS computer names and IP address mappings (database records). When Windows-based computers log on to the network, their computer name and IP addressing mapping are added (registered) to the WINS server database, providing support for dynamic updates. The WINS server database is replicated among multiple WINS servers in a LAN or WAN. One of the benefits of this database design is that it prevents different users from registering duplicate NetBIOS computer names on the network.

WINS servers provide the following benefits:

  • Dynamic database that supports NetBIOS computer name registration and name resolution in an environment where the dynamic TCP/IP configuration of DHCP-enabled clients is dynamically configured for TCP/IP.
  • Centralized management of the NetBIOS computer name database and its replication to other WINS servers.
  • Reduction of NetBIOS name query IP broadcast traffic.
  • Support for Windows-based clients (including Windows NT Server, Windows NT Workstation, Windows 95, Windows for Workgroups, and LAN Manager 2.x).
  • Support for transparent browsing across routers for Windows NT Server, Windows NT Workstation, Windows 95, and Windows for Workgroups clients.

The following figure illustrates an intranet with multiple WINS servers in a routed network. The components of a WINS system are shown in the illustration and are discussed in the following sections:

  • Microsoft WINS server push and pull partners
  • WINS clients, referred to as WINS-enabled computers
  • WINS proxy and non-WINS enabled computers

Figure 8.1 WINS Servers and WINS Clients in a Routed TCP/IP Network


Microsoft WINS Server Push and Pull Partners

A given network should have one or more WINS servers that WINS clients can contact to resolve a computer name to an IP address. It is desirable to have multiple WINS servers installed on an intranet for the following reasons:

  • To distribute the NetBIOS computer name query and registration processing load
  • To provide WINS database redundancy, backup, and disaster recovery

Microsoft WINS servers communicate with other Microsoft WINS servers to fully replicate their databases with each other. This ensures that a name registered with one WINS server is replicated to all other Microsoft WINS servers within the intranet, providing a replicated and enterprise-wide database.

When multiple WINS servers are used, each WINS server is configured as a pull or push partner of at least one other WINS server. The following table describes the pull and push partner types of replication partners.

Table 8.1 WINS Server Replication Partners

Type

Description

Pull partner

A pull partner is a WINS server that pulls (requests) WINS database entries from its push partners. The pull partner pulls new WINS database entries by requesting entries with a higher version number than the last entry it received during the last replication from that push partner. A pull partner can notify push partners that replication is needed by using either of the following:

· An arbitrary time interval, as configured by the WINS administrator. This is called the time interval.

· Immediate replication, initiated by the WINS administrator by using the WINS Manager.

Push partner

A push partner is a WINS server that sends a message to its pull partners that the WINS database has changed. When the pull partners respond to the message with a replication request, the push partner sends a copy of its new WINS database entries to the pull partners. The push partner notifies pull partners of replication requirements by using any of the following:

· An arbitrary number of WINS updates, as configured by the WINS administrator. This is referred to as the update count.

· Immediate replication, initiated by the WINS administrator by using WINS Manager.

It is always a good idea for replication partners to be both push and pull partners of each other. The primary and backup WINS servers must be both push and pull partners with each other to ensure that the primary and backup databases are consistent.

Replication is triggered when a WINS server polls another server to get replicated information. This can begin when the WINS server is started, and is repeated based on the configured update count or time interval, or by using WINS Manager to start immediate replication.


Microsoft WINS Clients

WINS clients, referred to as WINS- enabled clients, are configured to use the services of a WINS server.

Windows NT- based clients are configured with the IP address of one or more WINS servers by using the WINS Address tab on the Microsoft TCP/IP Properties page in Control Panel - Network. The following figure illustrates this configuration page.

Figure 8.2 Enabling the WINS Service on a WINS Client

The WINS-enabled client communicates with the WINS server to:

  • Register the client names in the WINS database.
  • Get mappings for user names, NetBIOS names, DNS names, and IP addresses from the WINS database.

How WINS Clients Register Their Names

When a WINS-enabled computer is started, the WINS client service attempts to directly contact the WINS server (by using point-to-point communication) to register the client names and corresponding IP address. The type of message the client sends is referred to as a name registration request. The WINS client sends one name registration request (which includes the computer IP address) for the computer, logged-on user, and networking services running on the computer.

Note

The IP address is dynamically assigned by a DHCP server if the client is DHCP-enabled. If DHCP is not used, the IP address is a statically assigned number which you must get from a network administrator and manually configure on the computer.

When the WINS server receives a name registration request, it checks the WINS database to ensure that the name in the request is unique and does not exist in the WINS database. The WINS server responds with either a positive or negative name registration response. The following table describes the processing that occurs for each type of WINS server name registration response.

Table 8.2 WINS Server Response to Name Registration Request

WINS server name registration response

WINS client behavior

No response

The WINS client sends another name registration request.

Positive

The WINS server responds with a positive name registration response if there is not a duplicate name in the WINS database. The response includes a time- to- live (TTL) value that indicates how long the client can own that name. The client must renew the name registration before the TTL expires.

Negative

If there is an existing registration for the name in the WINS database, the WINS server sends a challenge, referred to as a name query request, to the currently registered owner of the name.

The WINS server sends the challenge three times, waiting 500 milliseconds between attempts. If the computer is multihomed, the WINS server tries each IP address it has for the computer until the WINS server receives a response or until all of the IP addresses have been tried.

If the WINS server receives a response from the current owner, it sends a negative name registration response to the WINS client attempting to register the name, by using the IP address included in the client registration request.

The following figure illustrates the flow of name registration request and name response.

Figure 8.3 WINS Client Name Registration

How WINS Clients Renew Their Names

WINS clients must renew their name registrations before the time-to-live (TTL) value expires. The TTL value indicates how long the client can own that name.

When a WINS client renews its name registration, it sends a name refresh request directly (point- to-point) to the WINS server. The name refresh request includes the WINS client's IP address and the name that the client is requesting to have refreshed. The WINS server responds to the name refresh request with a name refresh response that includes a new TTL for the name.

A WINS client first attempts to refresh its name registrations after one-half of the TTL is expired. If the WINS client does not receive a name refresh response from the WINS server, it sends name refresh requests every two minutes, until one-half of the TTL is expired.

If the WINS client does not receive a name refresh response and one-half of the TTL is expired, the WINS client begins sending name refresh requests to a secondary WINS server if the computer is configured with an IP address for a secondary WINS server. The WINS client attempts to refresh its registrations with the secondary WINS server as if it were the first refresh attempt— n time increments equal to one-eighth of the TTL. The WINS client sends the name refresh requests until it successfully receives a name refresh response, or one-half of the TTL is expired. If the WINS client cannot contact the secondary WINS server by the time half of the TTL has expired, it reverts back to the primary WINS server. After a WINS client has successfully refreshed its name registrations, it does not start subsequent name registration requests until one-half of the TTL is expired.

How WINS Clients Release Their Names

When a WINS-enabled computer is correctly stopped, the WINS client sends a name release request to the WINS server. A name release request is sent for each name associated with the computer, logged-on user, and network client service that is registered with the WINS server. The name release request includes the computer IP address and the name that should be released (deleted) from the WINS server database.

Because the WINS-enabled client is configured with the IP address of the WINS server, the name release requests are sent directly to the WINS server. When the WINS server receives a name release request, the WINS server checks the WINS database for the specified name.

Based on the results of the database check, the WINS server sends a positive or negative name release response to the WINS client and removes the specified name from the WINS database. The name release response contains the name released and a TTL of 0 (zero).

Table 8.3 WINS Server Response to Name Release Request

WINS server name release response

WINS client behavior

No response

The WINS client waits to receive the response, and if it does not receive one, it sends another name release request.

Positive

The WINS client releases the name and stops. Microsoft WINS clients ignore the contents of the name release response.

Negative

The WINS client releases the name and stops. Because Microsoft WINS clients ignore the contents of the name release response when the WINS server sends a negative name release response, the server does not prevent the client from releasing the name and stopping.

The WINS server sends a negative name release response only if it encounters a WINS database error or if the address of the WINS client does not match the address stored in the WINS database.

How WINS Clients Perform Name Resolution

WINS clients perform NetBIOS computer name-to-IP-address mapping resolution by using the NetBIOS over TCP/IP (NetBT) component. A Windows NT-based computer is automatically configured to use one of four different NetBT name resolution modes (methods), based on how TCP/IP is configured on the computer. The following table describes the computer (referred to as a node) configuration and its associated NetBT name resolution mode.

Table 8.4 Description of NetBIOS Node Types

NetBIOS name resolution node type | Description
b-node | Uses IP broadcast messages to register and resolve NetBIOS names to IP addresses. Windows NT-based computers can use modified b-node name resolution.
p-node | Uses point-to-point communications with a NetBIOS name server (in Windows NT-based networks, this is the WINS server) to register and resolve computer names to IP addresses.
m-node | Uses a combination (mix) of b-node and p-node communications to register and resolve NetBIOS names. M-node first uses b-node; then, if necessary, p-node. M-node is typically not the best choice for larger networks because its preference for b-node broadcasts increases network traffic.
h-node | Uses a hybrid combination of b-node and p-node. When configured to use h-node, a computer always tries p-node first and uses b-node only if p-node fails. When a Windows NT-based computer is configured as a WINS client, it is by default configured as h-node. To further lessen the potential for IP broadcasts, Windows NT-based computers are configured, by installation default, to use an LMHOSTS file to search for name –to- IP-address mappings before using b-node IP broadcasts.

Note

Use the ipconfig /all command to display the TCP/IP configuration, including node type, of your computer. For example, on a computer that is configured as a WINS client, the node type Hybrid appears when the ipconfig /all command is entered.

The following figure illustrates the name resolution processes between a WINS client (h-node) and a WINS server.

Figure 8.4 H-Node Name Resolution for WINS Clients


Microsoft WINS Proxy

A WINS proxy is a WINS-enabled computer that helps resolve name queries for non-WINS enabled computers in routed TCP/IP intranets. By default, non-WINS enabled computers are configured as b-node which use IP broadcasts for name queries. The WINS proxy computer listens on the local subnet for IP broadcast name queries.

When a non-WINS enabled computer sends an IP name query broadcast, the WINS proxy accepts the broadcast and checks its cache for the appropriate NetBIOS computer name-to-IP-address mapping. If the WINS proxy has the correct mapping in its cache, the WINS proxy sends this information to the non-WINS computer. If the name-to-IP-address mapping is not in cache, the WINS proxy queries a WINS server for the name-to-IP-address mapping.

If a WINS server is not available on the local subnet, the WINS proxy can query a WINS server across a router. The WINS proxy caches (stores in memory) computer name-to-IP-address mappings it receives from the WINS server. These mappings are used to respond to subsequent IP broadcast name queries from b-node computers on the local subnet.

The name-to-IP-address mappings that the WINS proxy receives from the WINS server are stored in the WINS proxy cache for a limited time. (By installation default this value is 6 minutes. The minimum value is 1 minute.)

When the WINS proxy receives a response from the WINS server, it stores the mapping in its cache and responds to any subsequent name query broadcasts with the mapping received from the WINS server.

The role of the WINS proxy is similar to that of the DHCP/BOOTP relay agent which forwards DHCP client requests across routers. Because the WINS server does not respond to broadcasts, a computer configured as a WINS proxy should be installed on subnets which contain computers that use broadcasts for name resolution.

Note

To configure a computer as a WINS proxy, you must manually edit that computer's registry. The registry parameter EnableProxy must be set to 1 (REG_DWORD). This parameter is located in the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters


Planning for Microsoft WINS Server Implementation

The number of Windows NT-based WINS servers that an enterprise requires is based on the number of WINS client connections per server and the network topology. The number of users that can be supported per server varies according to usage patterns, data storage, and processing capabilities of the WINS server computer.

Planning for WINS server implementation on the network typically requires consideration of the issues presented in the following table.

Table 8.5 Network Configuration Planning Issues for WINS Servers

Planning issue | Guideline
How many WINS servers are required to ensure distribution of name query and name registration loads throughout the network? | One WINS server can handle NetBIOS name resolution requests for 10,000 computers. However, the location of routers on the network and the distribution of clients in each subnet should be considered when deciding how many WINS servers are required. See the following sections: "Planning for WINS Server Performance," "Planning for WINS Client Network Traffic," and "Planning for Replication Partners and Proxies."
Is the WAN bandwidth sufficient to support WINS server and WINS client name registration traffic? | See the next section, "Planning for WINS Client Network Traffic."
How many WINS servers are needed for disaster recovery, backup, and redundancy requirements? | See the following sections: "Planning for WINS Server Fault Tolerance" and "Planning for WINS Server Performance."
How can a planned distribution of WINS servers throughout the network be validated before installation? | When planning a network configuration, a generally accepted approach is to consider the consequences of two simultaneous failures at different points on the network. See the following section, "Planning for WINS Server Fault Tolerance."

Other planning issues for WINS servers can be similar to those for implementing Microsoft DHCP servers, as described in Chapter 7, "Managing Microsoft DHCP Servers."


Planning for WINS Client Network Traffic

WINS clients generate the following types of network traffic:

  • Name registration
  • Name refresh
  • Name release
  • Name query

When a WINS-enabled client starts on the network, it sends a name registration request for the computer name, user name, domain name, and any additional Microsoft network client services running on the computer. In other words, when a WINS client starts on the network, it generates a minimum of three name registration requests and three entries in the WINS database.

A Windows NT Server-based WINS client usually registers more NetBIOS names than other WINS-enabled clients. The name registration requests generated by a computer running under Windows NT Server include the following:

  • Server component
  • Domain names
  • Replicator service name
  • Messenger service name
  • Browser service name
  • Additional network program and service names

WINS Client Traffic on Routed Networks

When planning for WINS client traffic on large routed networks, consider the effect of name query, registration, and response traffic routed between subnets. Name requests and responses that occur at the daily startup of computers must pass through the traffic queues on the routers, and may cause delays at peak times.

Daily Startup of WINS Clients

An active WINS client name registration in a WINS server database is replicated to all pull partners configured on that WINS server. After some time, the active name registration is replicated to all WINS servers on the network.

When the WINS client is turned off at the end of the day, it releases the name. When the computer is started the next morning, the WINS client registers the name again with the WINS server, and receives a new version ID. This new, active name registration entry is replicated to the WINS server's pull partners as on the previous day.

Therefore the number of name registration entries that are replicated each day is roughly equivalent to the number of computers started each day times the number of NetBIOS names registered at each computer.

On large networks (50,000 or more computers), the biggest traffic load may be the name registration requests generated when WINS clients start on the network.. Fortunately, the difference in time zones in large enterprise networks provides some distribution of this WINS client startup load.

Roving User

When a user stops the computer and then moves and starts the computer on a different subnet with another primary WINS server, name challenge traffic is generated. Typically, the name registration request is answered with a Wait for Acknowledgment message (100 bytes), and the new WINS server (assuming the active entry was replicated) challenges the IP address that is currently in its database for this name (Name Query packet, 92 bytes). When there is no reply, as can be expected in this case, the WINS server repeats the challenge two more times and then updates the name registration entry with the new IP address and a new version ID. The new version ID indicates that the entry must be replicated from its new "owning" WINS server to other WINS servers on the network.

Estimating WINS Client Traffic

You can estimate WINS client traffic based on the behavior of the WINS clients as described in the preceding sections. However, when estimating WINS client traffic, you must also consider the network topology and the design or configuration of the routers in the network. In some cases it may not always be possible to predict the traffic load on a specific network router because the routers may be designed, or configured, to autonomously route traffic based on factors other than traffic load.


Planning for WINS Server Replication Across Wide Area Networks

The frequency of WINS database replication between WINS servers is a major planning issue. The WINS server database should be replicated frequently enough that the down-time of a single WINS server does not affect the reliability of the mapping information in the database of other WINS servers. However, when planning WINS database replication frequency, you do not want frequency of database replication to interfere with network throughput, which could happen if replication frequency is set to a small time interval.

Consider the network topology when planning for replication frequency. For example, if your network has multiple hubs connected by relatively slow wide-area-network (WAN) links, you can configure WINS database replication between WINS servers on the slow links to occur less frequently than replication on the local area network or on fast WAN links. This reduces traffic across the slow link and reduces contention between replication traffic and WINS client name queries.

For example, WIN servers at a central local-area-network site may be configured to replicate every 15 minutes, while database replication between WINS servers in different WAN hubs might be scheduled for every 30 minutes, and replication between WINS servers on different continents might be scheduled to replicate twice a day. The following figure illustrates this example of variation in replication frequency.

Figure 8.5 Enterprise Network Configuration and WINS Server Replication


Planning for Replication Convergence Time

The time needed to replicate a new entry in a WINS database from the WINS server that owns the entry to all other WINS servers on the network is called convergence time. When planning for WINS servers, you need to decide what is acceptable as the convergence time for your network.

This following figure illustrates an example network installation of WINS servers and the database replication interval between each WINS server. This example network configuration is presented to show how replication interval between WINS servers affects the convergence time.

Figure 8.6 Replication Intervals Between WINS Servers in a Routed TCP/IP Network

If a WINS client registers its name with the WINS server labeled WINS_C in the figure, other WINS clients can query WINS_C for this name and get the name –to-IP-address mapping. WINS clients that query any of the other WINS servers shown in the figure (WINS_A, WINS_B, and WINS_D) do not get a positive response until the entry is replicated from the WINS_C server to WINS_A, WINS_B, and WINS_D. WINS_C is configured to start replication when the push Update Count threshold is exceeded or when the pull Replication Interval expires on its WINS pull partner, WINS_A. (For this example, WINS_A is configured with a replication interval of 15 minutes.)

Only when the pull Replication Interval expires is the entry replicated, but queries for the new name to WINS servers B and D may still not be successful. The time interval for replication to server B is 15 minutes; to server D, it is 12 hours. The convergence time is calculated as:

12 hours + 2x (15 minutes) = 12.5 hour

Name query requests may, in reality, succeed before the convergence time has passed. This would happen if the entries have to be replicated over a shorter path than the worst case path. And it would also happen when an Update Count threshold would be passed before the Replication Interval would expire; this would result in earlier replication of the new entry. The longer the replication path, the longer the convergence time.


Planning for WINS Server Fault Tolerance

There are two basic types of WINS server failures:

  • A WINS server may crash, or be stopped to do maintenance.
  • Network failures including failures of routers and link stations.

In Figure 8.6, a failure of WINS-A or WINS-B would segment the distribution of WINS server services. Entries would no longer be replicated from WINS-C to WINS-D, and vice versa. Because the IP address and name would no longer match for updated clients, other clients would not be able to connect to the updated computers. Adding replication between WINS-B and WINS-C would improve the configuration for cases in which WINS-A fails. Adding replication between WINS-D and WINS-C would improve fault tolerance in a case where the WINS-B server fails.

Failure of one of the links between A, B, and C could be tolerated because the underlying router network would reroute the traffic. Failure of the link between B and D, however, would segment the communication between WINS servers and would make other network traffic impossible should there be an on-demand backup link between D and C. The WINS replication traffic would then be rerouted by the underlying router infrastructure.


Planning for WINS Server Performance

A WINS server can typically service:

  • 1,500 name registrations per minute.
  • 4,500 queries per minute.

A conservative recommendation is that you plan to install one WINS server and a backup server for every 10,000 computers on the network, based on these numbers and the possibility for large-scale power outages that would cause many computers to re-start simultaneously.

Two factors enhance WINS server performance. WINS server performance can be increased almost 25 percent on a computer with two processors. WINS server name replication response time can be measurably improved by using a dedicated disk.

After you establish WINS servers on the intranet, you can adjust the time between a WINS client name registration and name renewal. This is referred to as the Renewal Interval. Setting this interval to reduce the numbers of registrations can help tune server response time. (The Renewal Interval is specified when configuring the WINS server.)


Planning for Replication Partners and Proxies

Choosing whether to configure another WINS server as a push partner or pull partner depends on several considerations, including the specific configuration of servers at your site, whether the partner is across a wide area network (WAN), and how important it is to distribute changes throughout the network. Only one computer configured as a WINS proxy should be installed on each subnet. (Configuring more than one WINS proxy per subnet can overload the WINS servers on the same subnet.)

In one possible configuration, one WINS server can be designated as the central server, and all other WINS servers can be configured as both push partner and pull partner of this central server. Such a configuration ensures that the WINS database on each server contains addresses for every node on the WAN.

Figure 8.7 WINS Servers Replication by using a Central WINS Server

Another option is to set up a chain of WINS servers, where each server is both the push partner and pull partner with a nearby WINS server. In such a configuration, the two servers at the ends of the chain would also be push and pull partners with each other.

Figure 8.8 WINS Servers Replication in a Chained Network Configuration

Other replication partner configurations can be established for your site's needs. For example, in the following illustration, Server1 has only Server2 as a partner, but Server2 has three partners. So, for example, Server1 gets all replicated information from Server2, but Server2 gets information from Server1, Server3, and Server4.

Figure 8.9 WINS Server Replication in a T Network Configuration

  • If Server2, for example, needs to perform pull replications with WINS ServerB, make sure it is a push partner of Server3.
  • If Server2 needs to push replications to Server3, it should be a pull partner of WINS ServerB.


Fine-tuning WINS Server Replication Traffic

Fine-tuning the Replication Intervals may save some bandwidth on WAN links. Figure 8.10 illustrates a network configuration based on the network configuration first illustrated in Figure 8.6. The network configuration in Figure 8.6 was changed to the configuration shown in Figure 8.10 to illustrate one possible method for reducing convergence time.

Figure 8.10 Reducing WINS Server Replication Convergence Time

By keeping the pull Replication Intervals between WINS-C and WINS-B short (15 minutes), WINS servers A, B, and C can be reasonably synchronized. Replicas are never pulled in twice; only replicas with a higher version ID are copied. When WINS-B has an entry directly from WINS-C, it does not pull that entry from WINS-A.

However, under the example configuration there is the chance that both WINS-D and WINS-B can pull replicas from WINS-C by using the link between WINS-B and WINS-C. The resultant load on the link between WINS-B and WINS-C would increase.

In the example, this problem can be avoided if WINS-D is configured to pull replicas from WINS-B first and then check WINS-C. The pull Replication Interval between WINS-D and WINS-C would typically be the same 12 hours. Remember to configure push Update Counts (on WINS-D and WINS-C) to correspond to the 12 hours pull Replication Interval; otherwise unexpected replication is triggered by the Update Count threshold and not by the pull Replication Interval.


Using WINS Manager

When you install a WINS server, the WINS Manager graphic administration tool is added to the Administrative Tools (Common) Programs group on the Start menu.

Figure 8.11 Using WINS Manager

Use WINS Manager to view and change parameters for WINS servers on the network for which you have administrator privileges. WINS Manager Help is organized to provide information for each of the specific administration and configuration tasks that you need to perform to manage WINS servers. See WINS Manager Help for specific task lists and instructions.

Note

Other tools you can use to manage WINS servers include the Performance Monitor and SNMP agent service. Use Performance Monitor to monitor WINS server performance. Use the SNMP service to monitor and configure WINS servers by using third-party SNMP manager tools. Note that when using a third-party SNMP manager tool, some WINS queries may time out; if so, you should increase the time-out on the SNMP tool you are using.


Viewing WINS Server Operational Status

WINS Manager allows you to view administrative and operational information about WINS servers. When you open WINS Manager, it displays basic statistics about the selected WINS server in the right pane of the WINS Manager window. The following table describes these basic statistics for WINS servers.

Table 8.6 Statistics in WINS Manager

Statistic | Description
Database Initialized | The last time static mappings were imported into the WINS database.
Statistics Cleared | The time when statistics for the WINS server were last cleared with the Clear Statistics command from the View menu.
Last Replication Times | The times at which the WINS database was last replicated.
Periodic | The last time the WINS database was replicated based on the replication interval specified in the Preferences dialog box.
Admin Trigger | The last time the WINS database was replicated because the administrator clicked the Replicate Now button in the Replication Partners dialog box.
Net Update | The last time the WINS database was replicated as a result of a network request, which is a push notification message that requests propagation.
Total Queries Received | The number of name query request messages received by this WINS server. Successful indicates how many names were successfully matched in the database, and Failed indicates how many names this WINS server could not resolve.
Total Releases | The number of messages received that indicate a NetBIOS program has stopped. Successful indicates how many names were successfully released, and Failed indicates how many names this WINS server could not release.
Total Registrations | The number of messages received that indicate name registrations for clients.

You can display additional statistics by clicking Detailed Information on the Server menu. The following table describes these detailed information statistics.

Table 8.7 Detailed Information Statistics for WINS Manager

Statistic | Meaning
Last Address Change | Indicates the time at which the last WINS database change was replicated.
Last Scavenging Times | Indicates the last times that the database was cleaned for specific types of entries. (For information about database scavenging, see "Managing the WINS Server Database" later in this chapter.)
Periodic | Indicates when the database was cleaned based on the renewal interval specified in the WINS Server Configuration-(Local) dialog box.
Admin Trigger | Indicates when the database was last cleaned because the administrator chose Initiate Scavenging.
Extinction | Indicates when the database was last cleaned based on the Extinction interval specified in the WINS Server Configuration dialog box.
Verification | Indicates when the database was last cleaned based on the verify interval specified in the WINS Server Configuration dialog box.
Unique Registrations | Indicates the number of name registration requests that have been accepted by this WINS server.
Unique Conflicts | The number of conflicts encountered during registration of unique names owned by this WINS server.
Unique Renewals | The number of renewals received for unique names.
Group Registrations | The number of registration requests for groups that have been accepted by this WINS server. (For information about groups, see Table 8.10 later in this chapter.)
Group Conflicts | The number of conflicts encountered during registration of group names.
Group Renewals | The number of renewals received for group names.


Configuring WINS Server and WINS Client Behavior

Use WINS Manager to configure WINS server management of WINS client mappings by using the configuration options in the WINS Server Configuration - (Local) dialog box. The configuration options allow you to specify time intervals that govern WINS client behavior as described in the following table.

Table 8.8 Configuration Options for WINS Server

Configuration option | Description
Renewal Interval | Specifies how often a client reregisters its name. The default is six days.
Extinction Interval | Specifies the interval between when an entry is marked as released and when it is marked as extinct. The default is dependent on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. Maximum allowable value is six days.
Extinction Timeout | Specifies the interval between when an entry is marked extinct and when the entry is finally scavenged from the database. The default is dependent on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. The default is six days.
Verify Interval | Specifies the interval after which the WINS server must verify that old names it does not own are still active. The default is dependent on the extinction interval. The maximum allowable value is 24 days.

The extinction interval, extinction timeout, and verify interval are derived from the renewal interval and the partner replication interval. The WINS server adjusts the values specified by the administrator to keep the inconsistency between a WINS server and its partners as small as possible.

You can run the Registry Editor program at the command prompt to configure a WINS server by changing the values of the Registry parameters listed in the following table.

Table 8.9 Advanced WINS Server Configuration Options

Configuration option | Description
Logging Enabled | Specifies whether logging of database changes to J50.log files should be turned on.
Log Detailed Events | Specifies whether logging events is verbose mode. (This requires considerable computer resources and should be turned off if you are tuning for performance.)
Replicate Only With Partners | Specifies that replication occurs only with configured WINS pull or push partners. If this option is not checked, an administrator can ask a WINS server to pull or push from or to a non-listed WINS server partner. By default, this option is checked.
Backup On Termination | Specifies that the database is backed up automatically when WINS Manager is stopped, except when the computer is stopped.
Migrate On/Off | Specifies that static unique and multihomed records in the database are treated as dynamic when they conflict with a new registration or replica. This means that if they are no longer valid, they are overwritten by the new registration or replica. Check this option if you are upgrading non-Windows NT-based computers to Windows NT. By default, this option is not checked.
Starting Version Count | Specifies the highest version ID number for the database. Usually, you do not need to change this value unless the database becomes corrupted and needs to start fresh. In such a case, set this value to a number higher than appears as the version number counter for this WINS server on all the remote partners that earlier replicated the local WINS server's records. WINS may adjust the value you specify to a higher one to ensure that database records are quickly replicated to other WINS servers. The maximum allowable value is 231 - 1. This value can be seen in the View Database dialog box in WINS Manager.
Database Backup Path | Specifies the directory where the WINS database backup is stored. If you specify a backup path, WINS automatically performs a full backup of its database to this directory every 24 hours. WINS uses this directory to perform an automatic restoration of the database in the event that the database is found to be corrupted when WINS is started. Do not specify a network directory.


Managing Static NetBIOS Name-to-IP-Address Mappings

Static mappings are non-dynamic database entries of NetBIOS computer name-to-IP address mappings for computers on the network that are not WINS-enabled or special groups of network devices.

Click Static Mappings on the Mappings menu in WINS Manager to view, add, edit, import, or delete static mappings.

Once entered to the WINS server database, static name-to-IP-address mappings cannot be challenged or removed, except by an administrator who manually removes the specific mapping by using WINS Manager to remove the entry from the WINS server database. All changes made to the WINS server database by using WINS Manager take effect immediately.

Important

A DHCP reserved (or static) IP address for a unique name in a multihomed computer overrides an obsolete WINS static mapping if the WINS server advanced configuration option Migration On/Off is checked "on."

Static NetBIOS name mappings can be any of the types listed in the following table.

Table 8.10 Types of Static NetBIOS Name Mappings

Type option

Description

Unique

A unique name that maps to a single IP address. Contrast with multihomed type.

Group

Also referred to as a "Normal" Group. When adding an entry to Group by using WINS Manager, you must enter the computer name and IP address.

However, the IP addresses of individual members of Group are not stored in the WINS database. Because the member addresses are not stored, there is no limit to the number of members that can be added to a Group.

Broadcast name packets are used to communicate with Group members. Contrast with Internet group type.

Domain

A NetBIOS name-to-IP-address mapping that has 0x1C as the 16th byte. A domain group stores up to a maximum of 25 addresses for members. For registrations after the 25th address, WINS overwrites a replica address or, if none is present, it overwrites the oldest registration.

Internet group

Internet groups are user-defined groups that allow you to group resources, such as printers, for easy reference and browsing. The default 16th byte of an Internet group name is set equal to 0x20. An Internet group can store up to a maximum of 25 addresses for members.

When you add a Internet group three unique records are added:

· InternetGroupName<0x20>

· InternetGroupName<0x3>

· InternetGroupName<0x0>

This is similar to the domain group.

Internet group members can be added as the result of dynamic group registrations. A dynamic member, however, does not replace a static member added by using WINS Manager or importing the LMHOSTS file. Contrast with Group type.

Multihomed

A unique name that can have more than one address. This is used for multihomed computers. The maximum number of addresses that can be registered as multihomed is 25. For registrations after the 25th address, WINS overwrites a replica address or, if none is present, it overwrites the oldest registration. Contrast with Unique type.

A WINS server can be configured to replicate only domain, Internet, and multihomed groups to its replication partners. This is done by manually changing the registry parameter ReplicationType to a value of 1.

This eliminates replication of information (the unique names) that is not needed outside the local domain, while allowing replication of special group information. This is desirable to reduce replication traffic, and allows WINS clients to obtain the group addresses when the group spans multiple domains that are serviced by other Microsoft WINS servers.


Managing the WINS Server Database

The WINS database under Windows NT Server 4.0 uses the performance-enhanced Exchange Server Storage engine version 4.0.

There is no built-in limit to the number of records that a WINS server can replicate or store. The size of the database is dependent upon the number of WINS clients on the network. The WINS database grows over time as a result of clients starting and stopping on the network.

The size of the WINS database is not directly proportional to the number of active client entries. Over time, as some WINS client entries become obsolete, and are deleted, there remains some unused space.

To recover the unused space, the WINS database is compacted. Under Windows NT Server 4.0, WINS server database compaction occurs as an automatic background process during idle time after a database update.

Because the WINS server database compaction occurs while the database is being used, you do not need to stop the WINS server to compact the database.

Note

Under Windows NT Server 3.51 or earlier, you must manually compact the WINS server database. See the topic "Compacting the WINS Server Database" in the section "Troubleshooting the WINS Server Database" later in this chapter. In most cases there is no need to manually compact the WINS server database under Windows NT Server 4.0. However, if you decide to do so, use this same procedure.

The following database files are stored in the \%systemroot%\System32\Wins directory.

Table 8.11 Microsoft WINS Server Database Files

File | Description
J50.log and J50#####.log | A log of all transactions done with the database. This file is used by WINS to recover data if necessary.
J50.chk | A checkpoint file.
Wins.mdb | The WINS server database file which contains two tables: · IP address-Owner ID mapping table · Name-to-IP-address mapping table
Winstmp.mdb | A temporary file that is created by the WINS server service. This file is used by the database as a swap file during index maintenance operations and may remain in the %systemroot%\System32\Wins directory after a crash.

Important

The J50.log, J50#####.log, Wins.mdb, and Winstmp.mdb files should not be removed or tampered with in any manner.

WINS Manager provides the tools you need to maintain, view, back up, and restore the WINS server database. For example, you use the WINS Manager to back up the WINS server database files, and this administrative task should be done when you back up other files on the WINS server.

Backing Up the Database

WINS Manager provides backup tools so that you can back up the WINS database. After you specify a backup directory for the database, WINS performs complete database backups every three hours, by installation default.

For specific instructions on how to back up and restore the WINS database, see the Help topic "Backing Up and Restoring the Database" in WINS Manager Help.

You should also periodically back up the Registry entries for the WINS server.

Scavenging the Database

Scavenging the WINS server database is an administrative task related to backing up the database. Like any database, the WINS server database of address mappings needs to be periodically cleaned and backed up.

The local WINS server database should periodically be cleared of released entries and old entries that were registered at another WINS server and replicated to the local WINS server, but for some reason did not get removed from the local WINS database when the entries were removed from the remote WINS server database.

This process, called scavenging, is done automatically over intervals defined by the relationship between the Renewal and Extinct intervals defined in the Configuration dialog box. You can also clean the database manually.

The following table describes the results of scavenging the WINS database.

Table 8.12 Scavenging the WINS Database

State before scavenging | State after scavenging
Owned active names for which the Renewal interval has expired | Marked released
Owned released name for which the Extinct interval has expired | Marked extinct
Owned extinct names for which the Extinct timeout has expired | Deleted
Replicas of extinct names for which the Extinct timeout has expired | Deleted
Replicas of active names for which the Verify interval has expired | Revalidated
Replicas of extinct or deleted names | Deleted


Troubleshooting WINS Servers

This section describes some basic troubleshooting steps for common problems. It also describes how to restore or rebuild the WINS database.

The following error conditions can indicate potential problems with the WINS server:

  • The administrator can't connect to a WINS server by using WINS Manager and receives an error message when attempting to do so.
  • The WINS client service or Windows Internet Name Service might be down and cannot be restarted.


Verifying WINS Service Status

The first troubleshooting task is to make sure the appropriate services are running.

To ensure that the WINS services are running

1. Use the Services option in Control Panel to verify that the WINS services are running.

In the Services dialog box for the client computer, "Started" should appear in the Status column for the WINS client service. For the WINS server itself, "Started" should appear in the Status column for the Windows Internet Name Service.

2. If a necessary service is not started on either computer, start the service.


Resolving Common WINS Errors

To resolve "duplicate name" error messages

· Check the WINS database for the entries for that name that have a static name -to-IP-address mapping. If there is a static address record, delete it from the WINS server database.

Or, set the value of MigrateOn in the Registry equal to 1, so that the static records in the database can be updated by dynamic registrations (after the WINS server successfully challenges the old address).

To locate the source of "network path not found" error messages on a WINS client

· Check the WINS database for the name. If the name is not present in the database, check whether the destination or target computer uses b-node name resolution. If so, add a static mapping for it in the WINS database.

If the computer is configured as p-node, m-node, or h-node, and if its IP address is different from the one in the WINS database, then it may be that its address changed recently and the new address has not yet replicated to the local WINS server. To get the latest records, ask the WINS server that registered the address to perform a push replication with propagation to the local WINS server.

To discover why a WINS server cannot pull or push replications to another WINS server

1. Use the ping utility to verify that each WINS server is running and can be connected to.

2. Ensure that each server is correctly configured as both a pull and push partner.

  • If ServerA needs to perform pull replications with ServerB, make sure it is a push partner of ServerB.
  • If ServerA needs to push replications to ServerB, it should be a pull partner of ServerB.

To determine the configuration of a replication partner, check the values under the Pull and Push keys in the Registry.

To determine why WINS backup fails

· Make sure the path for the WINS backup directory is on a local disk on the WINS server.

WINS cannot back up its database files to a remote drive.


Troubleshooting the WINS Server Database

This section describes how to restore, rebuild, or move the WINS database. Also provided is a procedure for compacting the WINS database for Windows NT Server version 3.51 or earlier. (Microsoft WINS running under Windows NT Server version 4.0 provides automatic compacting of the WINS database.)

Restoring a WINS Server Database

If you have determined that the Windows Internet Name Service is running on the WINS server, but you cannot connect to the server using WINS Manager, then the WINS database is not available or has become corrupted. If a WINS server fails for any reason, you can restore the database from a backup copy.

You can use WINS Manager to restore the WINS database, or you can manually restore the database. For information about using WINS Manager to restore a WINS database, see the topic "Backing Up and Restoring the Database" in WINS Manager Help.

To restore a WINS database manually

1. Before starting, make a copy of the WINS database files.

2. In the \%Systemroot%\System32\Wins directory, delete the J50.log, J50#####.log, and Wins.tmp files.

3. Copy an uncorrupted backup version of Wins.mdb to the \Systemroot\System32\Wins directory.

4. Restart the WINS service on the WINS server, using the procedure in the next section.

Restarting and Rebuilding a Stopped WINS Server

In rare circumstances, the WINS server may not start or a STOP error might occur. If the WINS server is stopped, use the following procedure to restart it.

To restart a WINS server that is stopped

1. Turn off the power to the server and wait at least 15 seconds.

2. Turn on the power, start Windows NT Server, and then log on under an account with Administrator rights.

3. At the command prompt, type net start wins, and then press Enter.

If the hardware for the WINS server is malfunctioning or other problems prevent you from running Windows NT, you must rebuild the WINS database on another computer.

To rebuild a WINS server

1. If you can start the original WINS server using MS-DOS, use MS-DOS to make backup copies of the files in the \Systemroot\System32\Wins directory.

If you cannot start the computer with MS-DOS, you must use the last backup version of the WINS database files.

2. Install Windows NT Server and Microsoft TCP/IP to create a new WINS server using the same hard drive location and \Systemroot directory.

That is, if the original server stored the WINS files on C:\Winnt35\System32\Wins, then the new WINS server must use this same path to the WINS files.

3. Make sure the WINS services on the new server are stopped, and then use the Registry Editor to restore the WINS keys from backup files.

4. Copy the WINS backup files to the \Systemroot\System32\Wins directory.

5. Restart the new, rebuilt WINS server.

Moving the WINS Server Database

You may find a situation where you need to move a WINS database to another computer. To do this, use the following procedure.

To move a WINS database

1. Stop the Windows Internet Name Service on the current computer, using the procedure in the preceding section.

2. Copy the \System32\Wins directory to the new computer that has been configured as a WINS server.

Make sure the new directory is under exactly the same drive letter and path as on the old computer.

If you must copy the files to a different directory, copy Wins.mdb, but do not copy the checkpoint (.chk) or log files.

3. Start the Windows Internet Name Service on the new computer.

The service automatically starts using the .mdb and .log files copied from the old computer.

Compacting the WINS Server Database

Windows NT Server version 4.0 is designed to automatically compact the WINS database, and you should normally not need to run this procedure. However, if you are using Windows NT Server version 3.51 or earlier, after WINS has been running for a while, the database might need to be compacted to improve WINS performance. You should compact the WINS database whenever it approaches 30 MB.

You can use the Jetpack.exe utility provided with Windows NT Server version 3.5 and 3.51 to compact a WINS database. Jetpack.exe is a command-line utility that is run in the Windows NT Server command window. The utility is found in the \%Systemroot\System32 directory.

The Jetpack.exe syntax is:

Jetpack.exe <database name> <temp database name>

For example:

> CD %SYSTEMROOT%\SYSTEM32\WINS > JETPACK WINS.MDB TMP.MDB

In the preceding examples, Tmp.mdb is a temporary database that is used by Jetpack.exe. Wins.mdb is the WINS database file. When Jetpack.exe is started, it performs the following sequential tasks:

1. Copies database information to a temporary database file called Tmp.mdb.

2. Deletes the original database file, Wins.mdb.

3. Renames the temporary database file to the original filename.

To compact the WINS database

1. In Control Panel, on the local WINS server computer, double-click Services.

2. Under Service, click Windows Internet Name Service.

3. Click Stop, and then click Close. (Alternatively, you can type net stop wins at the command prompt.)

4. Click Start, and then click Run.

5. In Open, type Jetpack.exe, and then click OK.

6. Restart the Windows Internet Name Service by using the Services dialog box.


Chapter 9 - Managing MS DNS Servers

The Domain Name System (DNS) is a set of protocols and services for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. DNS enables you to use hierarchical "friendly" names to easily locate computers and other resources on a network. Microsoft DNS server is a new service in the family of TCP/IP networking services provided by Windows NT Server version 4.0. It enables you to provide and manage DNS services for your private TCP/IP networks and for users who connect to the public Internet. Microsoft DNS server is based on a client/server architecture that enables Microsoft DNS servers to maintain DNS name data and process DNS client name queries.

This chapter is for network administrators and support personnel who need to understand and administer DNS services. It includes the following topics:

  • Introduction to the Domain Name System
  • Microsoft DNS server
    • DNS server database
    • Primary and secondary DNS servers
  • Microsoft DNS clients
  • Planning for Microsoft DNS server implementation
    • Using Microsoft DNS server to connect to the Internet
    • Planning for Microsoft DNS and Microsoft WINS integration
  • Using DNS Manager
    • Adding DNS servers
    • Creating zones
    • Adding and Modifying DNS resource records
    • The zone transfer
  • Troubleshooting DNS server
    • Using the DNS diagnostic utility¾ Nslookup
    • Refreshing DNS server statistics
    • Resolving slow DNS zone transfer
    • Resolving zone wizard errors
    • Porting data files from other DNS servers


Introduction to Domain Name System

The Domain Name System (DNS) is used extensively on the Internet and in many private enterprises today. Computers running TCP/IP and connected to the Internet can have one or more IP addresses associated with each network adapter card in the computer. DNS is designed so that people do not have to remember IP addresses, but can instead use "friendly" names to locate and connect to remote computers and other network devices on TCP/IP networks. DNS is used on private TCP/IP-based intranets as well as the Internet.

Before the implementation of DNS, the use of names to locate resources on TCP/IP networks was supported by using a name resolution method based on files known as HOSTS files. Each HOSTS file contained a list of host (computer or other TCP/IP network device) names and their associated IP addresses. As the number of computers and users on the Internet grew, the HOSTS file method of name resolution became an unmanageable solution.

DNS is designed to replace the HOSTS file with a distributed database that implements a conceptual naming system. This naming system allows for growth on the Internet and the creation of host names that are unique throughout the Internet and private TCP/IP-based intranets.

The conceptual naming system on which DNS is based is a hierarchical and logical tree structure called the domain name space. The root (the top-most level) of the domain name space is managed by the Internet Network Information Center (InterNIC) (http://www.internic.com). InterNIC is responsible for delegating administrative responsibility for portions of the domain name space to organizations and enterprises that connect to the Internet.

These organizations and enterprises then employ DNS servers to manage the name-to-IP-address mappings for computers and network devices contained within their authoritative domain. The DNS servers that are used at the upper levels of the DNS hierarchy and at private domain nodes lower down in the DNS hierarchy are referred to as the authoritative name servers.

To understand how the conceptual domain name space is used to create unique names for computers on TCP/IP networks, you need to understand the top-down structure of DNS. The top level of the domain name space is managed by InterNIC and is divided into three main areas:

  • Organizational domains—these are named by using a 3- character code that indicates the primary function or activity of the enterprises contained within the domain. Most organizations and enterprises located in the United States are contained within one of these organizational domains, as shown in Table 9.1.
  • Geographical domains—these are named by using the 2-character country codes established by ISO 3166. These codes are used primarily for international organization and enterprise domains.
  • Reverse domain¾this is a special domain, named in-addr.arpa, that is used for IP-address-to-name mappings (referred to as reverse name lookup.)

The most commonly used top-level DNS name components for organizations and institutions in the United States are described in the following table and in Figure 9.1.

Table 9.1 Top-level Name Component of the DNS Hierarchy

Top-level name component | Description | Example domain name
.com | InterNIC assigns portions of the domain name space under this level to commercial organizations, such as the Microsoft Corporation. | microsoft.com
.edu | InterNIC assigns portions of this domain name space to educational organizations, such as the Massachusetts Institute of Technology. | mit.edu
.gov | InterNIC assigns portions of this domain name space to governmental organizations, such as the White House in Washington, D.C. | whitehouse.gov
.int | InterNIC assigns portions of this domain name space to international organizations, such as the North Atlantic Treaty Organization. | nato.int
.mil | InterNIC assigns portions of the domain name space to military operations, such as the Defense Date Network. | ddn.mil
.net | InterNIC assigns portions of the domain name space to networking organizations, such as the the National Science Foundation. | nsf.net
.org | InterNIC assigns portions of the domain name space to noncommercial organizations, such as the Center for Networked Information Discovery and Recovery. | cnidr.org

As mentioned earlier, InterNIC manages the assignment of domain names to organizations, private enterprises, and institutions. The organizations and enterprises to which InterNIC assigns a portion of the domain name space are then responsible for naming the computers and network devices within their assigned domain and its subdivisions.

The following figure illustrates the DNS naming conventions described in Table 9.1 by using a fictional domain named TerraFlora that contains a host (computer) named 'mfgserver'.

Figure 9.1 Domain Name System

A DNS-based name for the server in the TerraFlora domain is constructed as mfgserver.terraflora.com, which is the concatenation of the host name (mfgserver) with the domain name (terraflora) and the upper-level name (com) separated by the dot "." character at each point of concatenation. This name is referred to as the Fully Qualified Domain Name (FQDN).

Note

In general, domain names and host names have restrictions in their naming which only allow the use of characters a-z, A-Z, 0-9, and the dash or minus sign (-). The use of characters such the slash (/), period (.), and underscore (_) is not allowed by specification. However, Microsoft DNS server does allow the use of underscore (_) in a name.

The preceding figure presents a simple view of a domain. In actuality, domains can contain both hosts (computers) and other domains (referred to as zones, sub-zones, or domains). Each organization assigned authority for a portion of the domain name space is responsible for administering, subdividing, and naming the zones, sub-zones, domains, and computers within the domain for which they are "authoritative" by InterNIC assignment.

Subdividing is an important concept in DNS. Creating subdivisions of the domain name space and private TCP/IP network domains supports new growth on the Internet and the ability to continually expand name and administrative groupings.

For example, the Terraflora domain could contain groups such as retail, manufacturing, and so on. A DNS administrator of the Terraflora domain could subdivide the domain to create host names that reflect these groupings. For example, Terraflora's Internet server could be named www.terraflora.com and their retail departmental server could be named ntserver.retail.terraflora.com, and so on.


Microsoft DNS Server

Microsoft DNS server running under Windows NT Server version 4.0 is an RFC-compliant DNS name server that you use to manage and administer DNS services on your TCP/IP network. Microsoft DNS server supports RFCs 1033, 1034, 1035, 1101, 1123, 1183, and 1536, and is also compatible with the Berkeley Internet Name Domain (BIND) implementation of DNS.

Note

BIND is a popular implementation of DNS originally developed at Berkeley for the 4.3 BSD UNIX operating system.

Because Microsoft DNS server is an RFC-compliant DNS server, it creates and uses standard DNS database files and record types. These are referred to as resource record types. Microsoft DNS server is interoperable with other DNS servers and can be managed by using the standard DNS diagnostic utility, nslookup. (Nslookup is included with the TCP/IP utilities provided with Windows NT Server version 4.0.)

Microsoft DNS server also has features above and beyond those specified in the RFCs, such as tight integration with Microsoft Windows Internet Name Service (WINS) and ease-of-administration through the use of the graphical user interface, DNS Manager.

Integration of DNS and WINS services is an important feature that allows interoperability between non-Microsoft and Microsoft Windows-based TCP/IP network clients. DNS and WINS integration provides a method to reliably resolve name queries for Windows-based computers that use dynamic (DHCP-based) IP addressing and NetBIOS computer names.

The other important new feature of the Microsoft DNS server implementation is DNS Manager, a graphical user interface that you use to manage local and remote Microsoft DNS servers and database files.

Microsoft DNS server allows you to use a computer running under Windows NT Server version 4.0 to administer an entire domain or subdivisions of the domain referred to as zones, sub-zones and domains. These subdivisions are dependent on your enterprise requirements for name and administrative groupings of computers, integration of Windows NT-based domains into the DNS domain model, or your role as an Internet Service Provider (ISP) to other enterprises.

Note

In existing TCP/IP networks that are administratively organized by using Windows NT-based domain concepts, it is recommended that you use, or realign, your Windows NT-based domains with the DNS domain and subdivisions you have or may create. For additional information, see the topic "Planning for Microsoft DNS and Microsoft WINS Integration" later in this chapter.

The main administrative grouping by which a computer running Microsoft DNS server manages DNS services is the zone. A zone is an administrative portion (in small enterprises it can be the entire portion) of a DNS domain, referred to as the zone's root domain. (This root domain is generally the domain for which your organization is authoritative.) You can install Microsoft DNS servers in the root domain, zone, and zone subdivisions of a TCP/IP network¾ wherever you need a DNS server to manage your DNS data and DNS name query traffic.

The following figure illustrates an example deployment of Microsoft DNS servers based on the domain and zone concepts.

Figure 9.2 DNS Zones

A single Microsoft DNS server can be configured to manage one or multiple zones. You can also use multiple DNS servers to administer a zone and its subdivisions, as shown in the preceding figure. Dividing a domain into multiple zones can be done to distribute administrative tasks to different groups and to provide efficient data distribution by using the data replication method referred to as a zone transfer.


Microsoft DNS Server Database

The Microsoft DNS server database is a set of files that contain the host name –to-IP-address mappings and other DNS information data for the computers on your TCP/IP network. These data records are referred to as resource records and are contained in the zone, cache, reverse-lookup, and arpa-127 files in the \%systemroot%\Winnt\System32\Dns directory.

The following table describes the different types of resource records that may be used to provide DNS-based data about computers on a TCP/IP network.

Table 9.2 DNS Resource Record Types

Record type | Description
A | An address record that maps a host name to an IP address in a DNS zone. Its counterpart, the PTR resource record, is used to map an IP address to a host name in a DNS reverse zone (those in the in-addr.arpa. DNS domain).
AFSDB | Gives the location of either an Andrew File System (AFS) cell database server, or a DCE (Distributed Computing Environment) cell's authenticated name server. The AFS system uses DNS to map a DNS domain name to the name of an AFS cell database server. The Open Software Foundation's DCE Naming service uses DNS for a similar function.
CNAME | The canonical name resource record creates an alias (synonymous name) for the specified host name. You can use CNAME records to hide the implementation details of your network from the clients that connect to it. For example, ftp.terraflora.com is an alias (CNAME) for the real name of the computer that runs the FTP server. This alias also allows the FTP server to be moved to a different computer; only the CNAME record needs to change.
HINFO | The host information resource record identifies a host's hardware type and operating system. The CPU Type and Operating System identifiers should come from the computer names and system names listed in RFC 1700.
ISDN | The Integrated Services Digital Network (ISDN) resource record is a variation of the A (address) resource record. Rather than mapping a host name to an IP address, the ISDN record maps the name to an ISDN address. An ISDN address is a phone number that consists of a country code, an area code or country code, a local phone number, and, optionally, a subaddress. The ISDN resource record is designed to be used in conjunction with the RT (route through) resource record.
MB | The mailbox resource record is an experimental record that specifies a DNS host with the specified mailbox. Other related experimental records are the MG (mail group) resource record, the MR (mailbox rename) resource record, and the MINFO (mailbox information) resource record.
MG | The mail group resource record is an experimental record that specifies a mailbox that is a member of the mail group (mailing list) specified by the DNS domain name. Other related experimental records are the MB (mailbox) resource record, the MR (mailbox rename) resource record, and the MINFO (mailbox information) resource record.
MINFO | The mailbox information resource record is an experimental record that specifies a mailbox that is responsible for the specified mailing list or mailbox. Other related experimental records are the MB (mailbox) resource record, the MG (mail group) resource record, and the MR (mailbox rename) resource record.
MR | The mailbox rename resource record is an experimental record that specifies a mailbox that is the proper rename of the other specified mailbox. Other related experimental records are the MB (mailbox) resource record, the MG (mail group) resource record, and the MINFO (mailbox information) resource record.
MX | The mail exchange resource record specifies a mail exchange server for a DNS domain name. A mail exchange server is a host that will either process or forward mail for the DNS domain name. Processing the mail means either delivering it to the addressee or passing it to a different type of mail transport. Forwarding the mail means sending it to its final destination server, sending it using Simple Message Transfer Protocol (SMTP) to another mail exchange server that is closer to the final destination, or queuing it for a specified amount of time.
NS | The name server resource record identifies the DNS server(s) for the DNS domain. NS resource records appear in all DNS zones and reverse zones (those in the in-addr.arpa DNS domain).
PTR | The pointer resource record maps an IP address to a host name in a DNS reverse zone (those in the in-addr.arpa DNS domain). Its counterpart, the A (address) resource record, is used to map a host name to an IP address in a DNS zone.
RP | The responsible person resource record indicates who is responsible for the specified DNS domain or host. You can specify multiple RP records for a given DNS domain or host. The record has two parts: an electronic mail address (in the same DNS format as the one in the SOA resource record), and a DNS domain name that points to additional information about the contact.
RT | The route through resource record specifies an intermediate host that routes packets to a destination host. The RT record is used in conjunction with the ISDN and X25 resource records. It is syntactically and semantically similar to the MX record type and is used in much the same way.
SOA | The start of authority resource record indicates that this DNS server is the authoritative source of information for the data within this DNS domain. It is the first record in each of the DNS database files. The SOA resource record is created automatically by DNS Manager when you create a new DNS zone.
TXT | The text resource record associates general textual information with an item in the DNS database. A typical use is for identifying a host's location (for example, Location: Building 26S, Room 2499). The text string must be less than 256 characters, but multiple TXT resource records are allowed.
WINS | A record that contains the IP address of the WINS server configured on the DNS Server for WINS name resolution. This record is automatically created when WINS lookup is enabled on the DNS server, and is not a record that can be manually created by using Add Record in DNS Manager.
WINS_R | This record instructs Microsoft DNS server to use a NetBIOS node adapter status (nbtstat) command to resolve a DNS client reverse-lookup query. The reverse-lookup query requests the name of a computer identified only by an IP address. This record is automatically created when WINS reverse lookup is enabled on the DNS server, and is not a record that can be manually created by using Add Record in DNS Manager.
WKS | The well-known service resource record describes the services provided by a particular protocol on a particular interface. The protocol is usually UDP or TCP, but can be any of the entries listed in the PROTOCOLS file (\%systemroot%\system32\drivers\etc\protocol). The services are the services below port number 256 from the SERVICES file (\%systemroot%\system32\drivers\etc\services).
X.25 | The X.25 resource record is a variation of the A (address) resource record. Rather than mapping a host name to an IP address, the X.25 record maps the name to an X.121 address. X.121 is the International Standards Organization (ISO) standard that specifies the format of addresses used in X.25 networks. The X.25 resource record is designed to be used in conjunction with the RT (route through) resource record.

The following sections describe the DNS files that contain DNS resource records and that you create and use as the Microsoft DNS server database files.

Zone Files

A zone file contains resource records (described in the preceding table) for computers within the zone for which the DNS server is authoritative. A Microsoft DNS server zone file can contain multiple resource records of different types, depending on the information you enter about the computers in the zone.

A zone file is automatically created when you create a zone by using DNS Manager. The DNS Manager zone wizard prompts you for the needed information and then automatically creates a file named zonename.dns in the \%systemroot%\System32\Dns directory. You then use DNS Manager to add resource records to the zonename.dns file.

Note

If you want to create a new zone file or reuse an existing zone file by using a text editor, rather than by using DNS Manager, see the sample zone files in the \%systemroot%\System32\Dns\Sample directory.

Cache Files

The cache file contains name –to-IP-address mappings for the Internet root DNS servers and is used by the Microsoft DNS server to resolve name queries for computers that are located outside the enterprise network on the Internet.

When you install Microsoft DNS server, a cache file with current Internet root DNS mappings is automatically installed in the \%systemroot%\System32\Dns directory.

If you plan to use the Internet, you can use this cache file or you can obtain a copy from ftp://rs.internic.net/domain/named.cache.

If you do not connect to resources on the Internet, you should delete this file and create a new cache file that contains the host name – to-IP-address mappings for the DNS servers that are authoritative for the root of your private TCP/IP network. Replace the existing cache file in the \%systemroot%\System32\Dns directory with the new cache file.

Reverse Lookup Files

This file contains IP-address-to-host-name mappings (PTR records) that are used when a program or user has only the IP address of a remote computer but needs the host name associated to that IP address. This reverse lookup file is important for programs that implement security based on the connecting host name, and is also used for TCP/IP network troubleshooting.

There is no direct correlation between the conceptual model used to create IP addresses and the hierarchical structure of domain names. To provide a conceptual structure to manage IP-address-to-host-name mappings by using DNS servers, a special domain named in-addr.arpa was created. Nodes in the in-addr.arpa domain are named by using the numbers that comprise the dotted-octet representation of IP addresses, and IP-address-to-host-name mappings are mapped to these node numbers.

This is a somewhat complex mapping because IP addresses get more specific from left to right and domain names get less specific from left to right. The order of IP address octets must be reversed when building the in-addr.arpa top-down hierarchy (or tree). However, by using this method, administration of lower levels of the in-addr.arpa domain can be managed by using DNS servers and zones based on the class A, B, or C subnet addresses assigned to an enterprise.

You use the zone wizard in DNS Manager to create the reverse-lookup zone and files. DNS Manager automatically creates a reverse-lookup zone when the zone name that you enter is some form of nnn.nnn.nnn.in-addr.arpa.

After the reverse-lookup zone is created, you can add PTR records for the IP addresses contained within that zone. (The PTR record is analogous to the A record in the other zone files.) Reverse-lookup files also contain SOA and name server (NS) records as do other zone files.

Note

In a PTR record, the IP address is actually written in reverse order and the text "in-addr.arpa." is appended to the end of the IP address to create the pointer. For example, the pointer for a computer with the static IP address 172.16.48.1 would be entered as "1.48.16.172.in-addr.arpa".

Boot Files

Although a boot file is not needed for Microsoft DNS server, it is described here for completeness. This file is not required by RFC and is actually a feature of DNS servers running under a BIND implementation of DNS. You would only use a boot file on a Microsoft DNS server if you want to port an existing BIND boot file to the Microsoft DNS server. For more information about using a BIND boot file, see the topic "Porting Data Files from Other DNS Servers" in the section "Troubleshooting DNS Server" later in this chapter.


Primary and Secondary Servers

The Microsoft DNS server can be either a primary or secondary DNS server to another Microsoft DNS server or to a DNS server running under another operating system (such as UNIX or other vendor's Windows NT implementation).

A primary name server is a DNS server that gets the data for its zones from the local DNS database files. When a change is made to the zone data, such as delegating a portion of the zone to another DNS server or adding hosts in the zone, these changes must be made on the primary DNS server so that the new information is entered in the local zone file.

A secondary name server gets its zone data file from the primary DNS server that is authoritative for that zone. The primary DNS server sends a copy of the zone file to the secondary DNS server in a process referred to as a zone transfer.

The minimum number of DNS servers you need in order to serve each zone is two — a primary and a secondary. Both a primary and a secondary server are required to provide database redundancy and a degree of fault tolerance. Generally, plan to install the primary and secondary servers on different subnets to provide continual support for DNS name queries if one subnet should go down. (Note that Microsoft DNS server automatically makes a zone backup by creating a local DNS backup directory the first time a zone is created on the computer running Microsoft DNS server.)

When a DNS server receives a DNS name query, it attempts to locate the requested information by retrieving data from its local zone files. If this fails because the server is not authoritative for the domain requested and thus does not have the data for the requested domain, the server can communicate with other DNS servers to resolve the request.


Caching-only Servers

Although all DNS servers cache queries that they have resolved, caching-only servers are DNS servers that only perform queries, cache the answers, and return the results. In other words, they are not authoritative for any domains and only store data that they have cached while resolving queries.

When trying to determine when to use such a server, keep in mind that when the server is initially started it has no cached information and must build up this information over time as it services requests. The benefit of using a caching-only server is that it does not generate zone transfer network traffic.


Microsoft DNS Clients

A DNS client (sometimes called a resolver) uses a DNS server to resolve name queries and to locate resources on TCP/IP networks.

Note

Computers running under Windows NT Workstation or Windows NT Server version 4.0 automatically use DNS name resolution when a name query contains a name that is greater than 15 characters in length. If the name is less than or equal to 15 characters, either NetBIOS or DNS name resolution may be attempted. See Chapter 6, "TCP/IP Implementation Details," for additional details about DNS and NetBIOS name resolution.

There are three types of name queries that a DNS client can make. These types of name queries are recursive, iterative, and reverse (also called inverse).

A recursive name query is one in which the DNS client requires that the DNS server either respond to the client with the requested name –to-IP-address mapping or an error message stating that the data or domain name does not exist. The DNS server can not just refer the DNS client to a different DNS server.

Recursive name queries are generally made by a DNS client to a DNS server or by a DNS server that is configured to pass unresolved name queries to another DNS server. (Keep in mind that a DNS server can be a client to another DNS server.)

An iterative name query is one in which the queried DNS server returns the best answer it can give based on its cache or zone data. What this means is that if the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a pointer to an authoritative DNS server in a higher level of the domain name space. This process will continue up through the DNS hierarchy to the next authoritative DNS server until the query reaches a DNS server that can provide a referral down the hierarchy to a lower-level DNS server in a different branch of the domain name space, until a DNS server is located that has data that is an exact match for the queried name, or an error or timeout condition is met.

This process is sometimes referred to as "walking the tree" and this type of query is typically initiated by a DNS server that attempts to resolve a recursive name query for a DNS client.

A reverse name query is one in which the DNS client provides the IP address and requests the name that matches that IP address. For example, to find a host name for the IP address 172.16.48.1, the DNS client would query the DNS server for a PTR record for 1.48.16.172.in-addr.arpa. If this IP address is outside the local domain, the DNS server would need to connect to the in-addr.arpa root server and sequentially resolve the in-addr.arpa domain nodes until it locates the DSN server that is authoritative for that IP address.


Planning for Microsoft DNS Server Implementation

You will want to install a Microsoft DNS server if the following conditions exist on your network:

  • You have established your own domain on the Internet and need a DNS name server.
  • Your enterprise needs to implement DNS names on a TCP/IP-based intranet.
  • You need a DNS name server that provides a GUI-based administration tool.
  • You need to migrate existing non-Microsoft DNS name services to the Windows NT-based DNS server.

The number and location of computers running Microsoft DNS server that are needed to effectively manage DNS name data and name query traffic within your enterprise is a function of the size (number of hosts and their locations) of your network, the links between network subnets, and your network's security requirements.

When planning for the installation of Microsoft DNS server in your enterprise, there are several choices you can make. One option is to create one DNS zone that contains your entire enterprise domain.

The minimum number of DNS servers needed to serve each zone is two—a primary and a secondary¾to provide database redundancy. As with any fault tolerant system, the computers should be as independent as possible, for example, by placing the primary and secondary servers on different subnets.

There are some disadvantages to using a single zone. One of the disadvantages is that the primary DNS server may have a problem responding to polling from secondary DNS servers. There are several ways to resolve this problem, such as increasing the secondary refresh interval, configuring some of the secondaries to obtain zone data from other secondaries, and configuring DNS servers in remote locations (or on the far side of a slow network link) as caching-only servers. (Caching-only servers allow you to avoid the overhead of zone transfers to remote locations or over slow network links.)

Large networks which span multiple sites should not use a single zone but instead use multiple zones to manage their DNS services. This implementation would consist of one root domain with (1) a primary DNS server and one or more secondary DNS servers and (2) one or more zones (and sub-zones as needed), each with a primary DNS server and one or more secondary DNS servers.

A network architect usually breaks up a corporate DNS domain into multiple subdivisions to distribute the administration of parts of the domain to various entities within the enterprise.

Whenever possible, plan to align your Windows NT domains with the organizational structure of your DNS domain, zones, and subdomains.


Using Microsoft DNS Server to Connect to the Internet

Many enterprises today are connecting their private, internal networks to the Internet to provide access to external resources on the Internet. Although this is an important capability, it is one that must be well planned to avoid possible security risks by exposing the internal network to users outside the enterprise.

One common way to provide protection is to use a computer that is referred to as a firewall. A firewall is a computer or network device that allows only certain authorized operations or programs to be run between internal networks and the Internet.

A firewall configuration can be very simple or extremely complex depending on the particular requirements of the enterprise. This chapter is not designed to provide an exhaustive description of firewalls but will briefly discuss how the Microsoft DNS server can be used on a network that uses the services of a firewall to provide security for the network.

The following figure illustrates a typical network architecture that includes a multihomed computer running as an Internet firewall.

Figure 9.3 A Typical Network with a Firewall

As is illustrated in the Figure, the firewall protects the internal network from computers on the Internet that may attempt to access the internal network, while allowing computers on the internal network to access Internet resources. The example network design also includes computers that are configured as WWW and FTP servers that are external to the firewall.

The external servers allow computers from outside the internal network to access resources provided as public services, but these external servers must be closely monitored and secured because they are connected directly to the Internet network and do not use the firewall for access control. A router that is configured to control the type of packets allowed to pass through the router (referred to as packet filtering) can provide some additional access control.

The DNS services for the external and internal networks should be entirely isolated from one another to prevent computers outside the internal network from obtaining the names and IP addresses for resources located on the internal side of the firewall. This will help ensure that the only externally available information are the names and IP addresses of the external servers that are configured to provide external public services. These services include electronic mail, WWW, and FTP servers.

When internal network computers require access to computers outside the internal network, DNS name resolution typically requires interaction with DNS servers located on the public Internet. For this reason, you may want to allow only certain DNS servers to communicate outside the internal enterprise network. A DNS server that can communicate outside of the private network to resolve a DNS name query is referred to as forwarder.

After one or more DNS servers are designated as a forwarder, all other DNS servers on the internal network should be configured to use the forwarder for name resolution outside the internal network. The following figure illustrates this concept.

Figure 9.4 Using a DNS Forwarder and a Firewall

When a DNS server which is configured to use forwarders receives a DNS request that it is unable to resolve (through its own zone files), it passes the request to one of the designated forwarders. The forwarder then carries out whatever communication is necessary to resolve the request and returns the results to the requesting server, which, in turn, returns the results to the DNS client. If the forwarder is unable to resolve the query, the DNS server attempts to resolve the query on its own as normal.

To configure a Microsoft DNS server to use a forwarder

1. In DNS Manager, right-click the appropriate server icon, and then click Properties.

2. In the Server Properties dialog box, click the Forwarders tab and enter the IP address of the forwarder.


Planning for Microsoft DNS and Microsoft WINS Integration

You can configure Microsoft DNS servers to use a Microsoft WINS server for host name resolution (remember that the host name portion of a fully qualified domain name (FQDN) is analogous to a NetBIOS computer name.) Microsoft DNS server includes support for inter-operation with the NetBIOS naming system of traditional Microsoft networking by delegating part of the name resolution process to computers running Microsoft WINS server. DNS names and NetBIOS computer names can be integrated as complementary naming schemes by using Microsoft WINS servers and Microsoft DNS servers.

A Microsoft DNS server can be configured to resolve the upper layers of a FQDN and, if necessary, to pass the final part of name resolution, the host name portion of the FQDN, to a Microsoft WINS server. The Microsoft WINS server can then use the host name (if it is the same as the NetBIOS computer name) to find the correct name-to-IP-address mapping. Once the WINS server finds the correct mapping, it then returns this information to the DNS server. The DNS server then sends the information to the DNS client; the interaction between the WINS server and the DNS server is transparent to the DNS client to whom it appears as though the DNS server handled the entire name resolution process.

Using Microsoft WINS and Microsoft DNS on a TCP/IP network allows network clients to use either a NetBIOS name or a DNS name to find, communicate with, and connect to network resources. When both Microsoft WINS and Microsoft DNS are enabled on a computer, the order of name resolution is as follows:

1. A name query that contains a name greater than 16 characters is first sent to the DNS server for name resolution.

2. If the name is less than or equal to 16 characters, the name query is sent to the WINS server. If the WINS server cannot resolve the name, the name query is forwarded to the DNS server.

By integrating Microsoft WINS and Microsoft DNS, you can use the dynamic names services of Microsoft WINS and reduce the number of static resource records you would normally have to maintain in a DNS database file. Note that this support is available only for Windows NT-based and Windows-based computers that are configured to use Microsoft DHCP and Microsoft WINS servers.

You can install Microsoft WINS server and Microsoft DNS server on the same computer or on different computers running under Windows NT Server version 4.0.

When configuring TCP/IP on a computer running Microsoft WINS server under Windows NT Server, consider the following recommendations:

  • When determining the physical location of Microsoft WINS and DNS servers, use the physical characteristics of your LAN or WAN infrastructure and not the logical groupings defined in the Windows NT (or DNS) domain concepts.
  • Manually assign an IP address, subnet mask, default gateway, and other TCP/IP parameters on the computer. Do not configure the computer as a DHCP client. Enter the Microsoft WINS server's static IP address into the DHCP server database as a reserved IP address (using DHCP Manager) to prevent assigning the IP address to another computer.

To configure TCP/IP on a computer running Microsoft WINS server under Windows NT server

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Network.

3. On the Protocols tab, select TCP/IP Protocol, and click Properties.

4. Click the WINS Address tab.

5. Select the Enable DNS for Windows Resolution checkbox.

Unresolved host name queries will then be passed to a DNS server.

6. Click the DNS tab.

7. In the DNS Service Search Order list, type the IP address of the DNS server that is geographically (physically) closest to the WINS server.

You can enter multiple DNS servers in this list.

When configuring TCP/IP on a computer running Microsoft DNS Server under Windows NT Server, consider the following recommendations:

  • Manually assign an IP address, subnet mask, default gateway, and other TCP/IP parameters on the Microsoft DNS server. Enter the DNS server's static IP address into the DHCP server database as a reserved IP address (using DHCP Manager) to prevent assigning the IP address to another computer.
  • Use DNS Manager to configure the Microsoft DNS server to pass unresolved name queries to WINS servers, referred as WINS Lookup. See online Help in DNS Manager for detailed DNS server configuration tasks. (Microsoft DNS server can also be configured to perform Reverse WINS Lookup, which refers to obtaining an NetBIOS name by IP address query.)
  • After you have configured TCP/IP on the Microsoft DNS server, create a zone for each group of computers where name resolution can be performed by using a WINS server.


Capacity Planning and Performance

Microsoft DNS server keeps track of a number of server usage statistics and displays these statistics in the right pane of the DNS Manager window. These statistics are cumulative; in other words they are started when the DNS server is started and are not cleared until the DNS server is stopped.

These statistics are useful for comparing relative name query traffic and load on each DNS server to determine how many name queries each DNS server is servicing. If one DNS server is busier than other DNS servers, you can direct some of the name query traffic away from the overloaded server to another server that is not as heavily loaded. For example if you have a primary and two secondaries, you can balance the load on the primary by configuring some of the DNS clients to point to one DNS secondary and other clients to point to the other DNS secondary. This reconfiguration can be done by using the DHCP server to change the DNS server which DHCP clients are configured to use, or by manually reconfiguring TCP/IP on non-DHCP enabled clients.

For capacity planning purposes, it is important to periodically compare the level of growth in usage of the DNS server versus the memory, disk, network, and CPU capabilities of the computer running the DNS server. If you feel that a DNS server is not responding as fast as it should, look first at the following performance monitor counters on that server. If any of the thresholds described in the following table are being met, there may be room to improve performance on the DNS server.

Table 9.3 Using Performance Monitor Counters to Monitor DNS Server

Object | Counter | Threshold | Notes
processor | %processor time | > 80% |
memory | available bytes | < 1 MB |
physical disk | %disk time | > 67% | only available if you start the counters from the command line with diskperf -y, and reboot
network segment | % network usage | > 40% | only available if Network Monitor Agent is installed

If memory is an issue, then check the 'process' object, 'DNS' instance, 'Private Bytes' counter. If this counter is high, then the DNS service is causing the memory available bytes counter to be low. If this is the case, add more memory or possibly investigate which records are currently active in the DNS cache and find out the TTL associated with each.

If processor is an issue , check the 'process' object, 'DNS' instance, '%processor time' counter. If this is > 80 %, consider running the DNS server on a more powerful server. If this is not high, and processor '%processor time' is still high, look at all the other processes and determine which process is requiring large amounts of CPU time.

On a DNS server, physical disk '%disk time' should not be a problem, unless the system has started paging for lack of memory. If this is the case, treat this as a memory issue.

If network use is a problem, find out if it is the DNS server that is causing all of the traffic or another server on the same segment. To do this, use the Network Monitor utility to examine the traffic that is received and sent by the server.

DNS Server Memory Usage

Microsoft DNS server cache memory is different than processing of resource records. Virtual (pageable) memory is allocated for cached data as needed (remember, as a DNS server performs name resolution for a name query, it caches a copy of the data which is retained for the time period specified by the TTL). If the DNS server requires more than the normal amount of cache memory, this memory is taken from the local computer page file and is usually slower than cache memory.


Using DNS Manager

DNS Manager is the graphical user interface that is automatically installed and added to Administrative (Tools) on the Program menu when you install Microsoft DNS server on a computer running under Windows NT Server 4.0. You can use DNS Manager to administer local and remote Microsoft DNS servers and database files.

Note

Keep in mind that you cannot administer non-Microsoft DNS servers by using DNS Manager.

DNS Manager provides menus and options that enable you to add and configure DNS servers, and a zone wizard that enables you to create the zones and sub-zones managed by each DNS server. Once you have added DNS servers and their zones, you can then administer the local and remote DNS servers and add, view, and edit DNS resource records that comprise the database files for each zone and DNS server.

To start DNS Manager

· Click Start, point to Programs, point to Administrative Tools, and click DNS Manager.

The following sections provide introductory information about the basic tasks you perform to start using Microsoft DNS server. For a complete task list and detailed task instructions, see DNS Manager Help.

Tip

When you make a change to DNS server and zone data by using DNS Manager, click DNS on the menu bar, then click Update Server Data Files to immediately write the changed information to the DNS database files.


Adding DNS Servers

Use DNS Manager to add the local and remote Microsoft DNS servers to be managed by using the local computer running Microsoft DNS server.

To add a Microsoft DNS server

1. In DNS Manager, click the Server List icon.

2. Click New Server, and enter either the DNS server host name or the IP address in the Add DNS Server dialog box.

3. Click OK.

DNS Manager will automatically display a server icon for the new server and automatically create the following zones:

  • Cache— contains the records needed to connect to the Internet root DNS name servers.
  • 0.in-addr.arpa— used to prevent passing reverse-lookup queries for the IP address 0.0.0.0 to the root DNS server .
  • 127.in-addr.arpa ¾used to prevent passing reverse-lookup queries for the loopback address name queries to the root DNS server.
  • 255.in-addr.arpa ¾ used to prevent passing broadcast name queries to the root DNS server.

After you have added a server, you can then configure the server and create the zone or zones to be managed by the server.

To configure the server

1. Right-click the server icon, and click Properties.

2. In the Server Properties dialog box, add the IP address (or IP addresses for a multihomed computer) and forwarder information as needed.


Creating Zones

After you have added and configured a server by using DNS Manager, you create the zone or zones managed by that server. Remember that you will need to create a zone for each group of WINS-enabled computers where you want to use both DNS and NetBIOS name resolution. Before creating a zone, make sure that you have correctly configured TCP/IP on the DNS server and that you have entered the DNS server host name and domain name on the DNS tab on the Microsoft TCP/IP Properties page.

To add a Primary zone

1. Right-click the appropriate server icon, and click New Zone to start the zone wizard.

2. Click Primary, and then click Next.

The zone wizard will prompt you for additional information and then automatically create the zone, zone file, and the SOA, NS, and server A data records.

Tip

To create a reverse-lookup zone, use this same procedure and use a zone name that complies with the reverse-lookup name format (nnn.nnn.nnn.in-addr.arpa). For example, the reverse-lookup zone that could contain PTR records for IP addresses 172.16.16.1 through 172.16.224.254 would be named .16.172.in-addr.arpa. Whenever possible, create reverse-lookup zones before adding host data so that you can use the automatic Create PTR Record option in the Add Host dialog box.

After you have created the primary zone, you can create secondary zones by using the same procedure.

To add a Secondary zone

1. Right-click the secondary server icon, and click New Zone to start the zone wizard.

2. Click Secondary, and enter the requested information.

3. Click Next.

The zone wizard will prompt you for additional information and then automatically create the zone, zone file, and the SOA, NS, and server A data records.

After a zone is created, you can further subdivide that zone as described in the following procedure.

To create a subdomain (a domain contained within a zone)

1. Right-click the appropriate zone folder.

2. Click New Domain.

3. Type the domain name in Domain Name, and then click OK.

After you have successfully added a zone, you can configure and modify the zone properties. To do this, select and right-click the zone icon to display the Zone Properties dialog box. You can use the Zone Properties dialog box to perform the following actions:

  • Change the zone from a primary to secondary, or vice versa, by using the General tab.
  • Modify the default server TTL values and the values used to determine refresh and zone transfer rates by using the SOA Record tab.
  • Identify the secondary DNS servers that should be notified of changes in the zone by using the Notify tab.
  • Configure the zone server to use WINS for host name resolution by using the WINS Lookup tab (on a reverse-lookup zone, this tab is labeled WINS Reverse Lookup.)

The following figure illustrates the Zone Properties dialog box for a normal zone.

Figure 9.5 Zone Properties dialog box

The only difference in the Zone Properties dialog box for a reverse-lookup zone is the text on the WINS Lookup tab, as illustrated in the following figure.

Figure 9.6 Zone Properties dialog box for Reverse-Lookup Zone


Adding and Modifying DNS Resource Records

DNS Manager makes it easy to add data to both local and remote Microsoft DNS servers because you can create and edit all DNS resource records by using DNS Manager. After you create a zone, you can select and right-click the zone to display a menu of actions that you can perform on the zone. The following figure illustrates this menu.

Figure 9.7 Zone menu

The two menu choices that you use to add information about the computers in the zone are New Host and New Record.

You will want to use the New Host option to add the A and PTR records for the computers in the zone that are not DHCP- or WINS-enabled. The following figure illustrates the Add New Host dialog box.

Figure 9.8 New Host dialog box

Additionally you will want to use New Resource Record to add other DNS information about a computer, such as alias (Cname), mail server, and so on. (Refer back to Table 9.2 for descriptions of the different types of resource records you can create.)

The following figure illustrates the New Resource Record dialog box.

Figure 9.9 New Resource Record dialog box

Note

You can use existing resource records in the DNS database files from other DNS servers. For more information about this topic, see "Porting Data Files from Other DNS Servers" in the section "Troubleshooting DNS Server" later in this chapter.


The Zone Transfer

How often zone transfers should occur is a function of how often names and IP address mappings change within your domain. Note that unnecessary zone transfer could cause unnecessary network and server loads.

A zone transfer is nothing more than a file copy procedure. The entire contents of the database are copied from the primary (or master) to the secondary each time the secondary is 'notified' by the primary (or master) that there has been a change in the zone data.

You configure primary and secondary zones with the information needed to initiate and request zone transfers by using the SOA Record and Notify tabs of the Zone Properties dialog box. You can change the default zone transfer timers by using the SOA Record tab. You can change the following values that affect zone transfer:

  • Serial Number
  • Refresh Interval
  • Retry Interval
  • Expire Time
  • Minimum Default TTL

The following figure illustrates the SOA Record tab.

Figure 9.10 SOA Record tab

On the primary zone, use the Notify tab of the Zone Properties dialog box to identify the secondary or secondaries to notify for the zone transfer. The following figure illustrates the Notify tab.

Figure 9.11 Notify Tab


Troubleshooting DNS Server

The following sections provide information about problems you might encounter when using Microsoft DNS server and the tools or procedures that you can use.


Using Nslookup

Nslookup is a TCP/IP utility that you can use at the command prompt. Use the nslookup command to get information about hosts in a domain or to set configuration parameters on a Microsoft DNS server.

For more information on how to use the nslookup command, see the topic "TCP/IP Procedures Help" in Control Panel Help.


Clearing DNS Server Statistics

DNS Manager displays statistics about the traffic received on the computer running Microsoft DNS server. These statistics are automatically started and displayed in the right pane of DNS Manager after you add a server and create at least one zone on that server. By default, these statistics are cumulative and are not normally cleared until the computer running Microsoft DNS server is stopped.

You can use the dnsstat.exe utility provided in the Windows NT Server version 4.0 Resource Kit to clear the statistics without stopping the Microsoft DNS server.

This command-line utility provides a dump of statistics about traffic received on a computer running Microsoft DNS server. You can also use dnsstat to clear these statistics without stopping the DNS server. By default, these statistics are cumulative and are not normally cleared until the computer running Microsoft DNS server is stopped.

dnsstat syntax

dnsstat {servername | IP address} [{-c | /c | -clear | /clear}]

Where servername returns all DNS server statistics on the server named servername. IP address returns all DNS server statistics on the server with the IP address indicated. The options -c or /c or -clear or /clear clear clearable DNS statistics on the server indicated.

To clear the Microsoft DNS server statistics by using the dnsstat command

1. Click Start, and then click Run.

2. In Open, type dnsstat <servername> -c or dnstat <servername> /c, and then click OK.

This will reset the value the DNS statistics to zero. Open DNS Manager to verify that the statistics have been cleared and restarted.

For detailed information about using this utility, see Resource Kit Tools Help.


Resolving Slow DNS Zone Transfer to non-Microsoft DNS Servers

Slow DNS zone transfers may occur when your secondary DNS server is a non-Microsoft DNS server. By default, the Microsoft DNS server performs zone transfers to non-Microsoft DNS secondaries by sending one resource record per message. This behavior enables Microsoft DNS server to work with DNS servers running under an implementation of BIND earlier than BIND version 4.9.4. (Only BIND version 4.9.4 and later use a faster, high compression method that allows multiple resource records to be sent per message.)

If you are running a secondary non-Microsoft DNS server under BIND version 4.9.4 or higher, you can increase the speed of the zone transfer by creating a new parameter BindSecondaries of type DWORD with Value=0 in the following Registry key:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

To add the BindSecondaries parameter

1. Click Start, and then click Run.

2. In Open, type regedit, and then click OK.

3. Open the following key folder:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

4. On the Edit menu, click New, and then click Key.

5. Type BindSecondaries, and then press enter.

6. On the Edit menu, click New, and then click DWORD Value.

7. Type 0 or 1 in the value box, and press enter.

Note

Use value = 0 if you have no BIND secondaries or if all BIND secondaries are running under BIND version 4.9.4 or later. Use value = 1 if you have BIND secondaries running under a BIND implementation earlier than BIND version 4.9.4.

8. Stop and restart the Microsoft DNS server by using Services in Control Panel.

Note

Zone transfers between computers running Microsoft DNS server are automatically performed using the faster, high compression transfer method and are not affected by the BindSecondaries parameter.


Zone Wizard Did Not Correctly Autocreate SOA, NS, or a Record

The DNS zone wizard retrieves information from your user logon information and the TCP/IP configuration on the DNS server in order to create a zone. For example, the DNS zone wizard uses your logon name in the Responsible Party Mailbox Name field of the SOA Record dialog box.

If you are creating a zone that has the same name as your domain and you do not enter the domain name on the DNS page in the Microsoft TCP/IP Properties dialog box, the DNS zone wizard cannot create the A record. To add the domain name, use the Network applet in Control Panel to display and configure TCP/IP properties. Type the domain name on the DNS page of the Microsoft TCP/IP properties dialog box and then stop and restart the Microsoft DNS server by using the Services applet in Control Panel.

Note

If you are creating a zone whose name is not the same as your domain name, you must manually add the SOA, A, and NS records in order to create the records with the new domain name and not the domain name configured on the local DNS server.


Porting Data Files from Other DNS Servers

You can use the boot, zone, cache, and other files from non-Microsoft RFC-compliant DNS servers. To do this, you must install these files in the \%systemroot\System32\DNS directory, and then stop and restart the DNS server.

Before installing files from other DNS servers on a Microsoft DNS server, you must edit the file name and directory location text in the ported files and make additional changes as described in this section.

The boot file will be used to load the data files you want to port into a Microsoft DNS server. A boot file is actually a file that controls the startup behavior of DNS servers running under a BIND implementation of DNS. It is a BIND-specific feature and not a requirement of the DNS RFCs. Microsoft DNS server's ability to use a boot file on initial startup is provided to support migration of data from BIND-based DNS servers to Microsoft DNS servers.

Although Microsoft DNS server will support a boot file, you must install the edited boot file before using DNS Manager. Starting DNS Manager configures the Microsoft DNS server to use the Windows NT Server Registry instead of the boot file.

If you need port data files after starting DNS Manager, you must change the value of the EnableRegistryBoot parameter from 1 to 0. The EnableRegistryBoot parameter is located in the following key:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

To change the value of the EnableRegistryBoot parameter

1. Click Start, and then click Run.

2. In Open, type regedit, and then press ENTER.

3. Open the following key folder:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

4. Select the EnableRegistryBoot parameter in the right pane of the Registry Editor, and then select Edit.

5. Click Modify, and type 0.

6. Click OK, and return to the menu bar and click Edit.

7. Select New, and then click DWORD Value.

8. Type 0 in the value box, and press enter.

9. Stop and restart the Microsoft DNS server by using Services in Control Panel.

The following table describes the format of boot file commands. You can use any text editor to edit or create a boot file. Commands must start at the beginning of a line and no spaces may precede the commands. This table shows the order in which the Microsoft DNS server supported boot commands must appear in the file, and gives the syntax for each command.

Table 9.4 BIND Boot File Commands

Description | Syntax
Specifies a directory where other files referred to in the boot file can be found. | directory <directory>
Specifies a file used to help the DNS service contact DNS servers for the root domain. This command and the file it refers to must be present. | cache <filename>
Specifies a domain for which this DNS server is authoritative, and a database file which contains the resource records for that domain in the zone file. Multiple primary command records can be entered in the boot file. | primary <domain> <filename>
Specifies a domain for which this DNS server is authoritative, and a list of master server IP addresses from which to attempt downloading the zone information. | secondary <domain> <hostlist> <local filename>


Chapter 10 - Using LMHOSTS Files

Windows NT supports several different name resolution services to locate, communicate with, and connect to resources on the network. For example, a command to connect to an application server by using the server name must be resolved to an IP address in TCP/IP networks before the command can be successfully completed. This is referred to as name resolution.

If WINS servers are available on the network, the LMHOSTS file can be used to support the subnets that do not have a WINS server, and to provide a backup name resolution service in case the WINS server is not available. The LMHOSTS file provides a NetBIOS name resolution method that can be used for small networks that do not use a WINS server.

This chapter provides information about the following topics:

  • Using LMHOSTS files to find remote computers and services
  • Creating the LMHOSTS file
  • Configuring TCP/IP to use LMHOSTS name resolution
  • Maintaining the LMHOSTS file
  • Troubleshooting the LMHOSTS file


Using LMHOSTS File to Find Computers and Services

Windows NT versions 4.0 and 3.5x provide name resolution services for both NetBIOS computer names and Domain Name System (DNS) host names on TCP/IP networks. For an overview of all the Windows NT name resolution services for TCP/IP networks, refer to the chapter "Implementation Considerations" in the Windows NT Server Networking Supplement.

The LMHOSTS file is one method of name resolution for NetBIOS name resolution for TCP/IP networks. The other NetBIOS over TCP/IP (NetBT) name resolution methods that are used, depending on the computer's configuration, are:

  • NetBIOS name cache
  • IP subnet broadcasts
  • WINS NetBIOS name server

Note

NetBT is defined by RFCs 1001 and 1002. These RFCs define the different configurations¾b-node, p-node, m-node, and h-node¾that define how a computer attempts to resolve NetBIOS names to IP addresses.

By installation default, a Windows NT-based computer not configured as a WINS client or WINS server, is a b-node computer. A b-node computer is one that uses IP broadcasts for NetBIOS name resolution.

IP broadcast name resolution can provide dynamic name resolution. However, the disadvantages of broadcast name queries include increased network traffic and ineffectiveness in routed networks. Resources located outside the local subnet do not receive IP broadcast name query requests because, by definition, IP-level broadcasts are not passed to remote subnets by the router (default gateway) on the local subnet.

As an alternate method to IP broadcasts, Windows NT enables you to manually provide NetBIOS name and IP address mappings for remote computers by using the LMHOSTS file. Selected mappings from the LMHOSTS file are maintained in a limited cache of NetBIOS computer names and IP address mappings. This memory cache is initialized when a computer is started. When the computer needs to resolve a name, the cache is examined first and, if there is no match in the cache, Windows NT uses b-node IP broadcasts to try to find the NetBIOS computer. If the IP broadcast name query fails, the complete LMHOSTS file (not just the cache) is parsed to find the NetBIOS name and the corresponding IP address. This strategy enables the LMHOSTS file to contain a large number of mappings, without requiring a large chunk of static memory to maintain an infrequently used cache.

The LMHOSTS file can be used to map computer names and IP addresses for computers outside the local subnet (an advantage over the b-node broadcast method). You can use the LMHOSTS file to find remote computers for network file, print, and remote procedure services and for domain services such as logons, browsing, replication, and so on.

The Windows NT-based LMHOSTS method of name resolution is compatible with Microsoft LAN Manager 2.x TCP/IP LMHOSTS files.


Locating Remote Computers

Computer names can be resolved outside the local broadcast subnet if the remote computer name and IP address mappings are specified in the LMHOSTS file. For example, suppose your computer, named ClientA, is configured without the WINS client service, but you want to use TCP/IP to connect to a computer, named ServerB, that is located on another TCP/IP subnet. By default, your computer is a b-node computer that uses NetBIOS cache and IP broadcasts, and is enabled for LMHOSTS file lookup, by using an LMHOSTS file provided by your network administrator.

At system startup, the name cache on ClientA is preloaded only with entries from the LMHOSTS file, defined as preloaded by a special keyword, the #PRE keyword. For this example, ServerB is on a remote subnet outside of your local subnet IP broadcast area and is not one of the entries in preloaded cache. A strict b-node IP broadcast (as defined in RFCs 1001 and 1002) fails by timing out when no response is received. In this example, ClientA's IP broadcast to locate ServerB will time out, because ServerB is located on a remote subnet and does not receive ClientA's broadcast requests.

This example is summarized in the following steps:

1. ClientA enters a Windows NT command, such as a print file command, using the NetBIOS name of ServerB.

2. The NetBIOS name cache on ClientA is checked for the IP address that corresponds to the NetBIOS name of ServerB.

3. Because ServerB was not preloaded, its NetBIOS name is not found in the name cache, and ClientA broadcasts a name request with the NetBIOS name of ServerB.

4. Because ServerB is on a remote network, ClientA does not receive a reply to its name request broadcast because IP broadcasts are not routed to remote subnets. (If ServerB were on the local network, ClientA would receive a response to its broadcast and the response would contain the IP address of ServerB.)

5. Because the LMHOSTS method has been enabled on ClientA, Windows NT continues to attempt to resolve the NetBIOS name to an IP address. The LMHOSTS file in the %systemroot%\System32\Drivers\Etc directory is examined to find the NetBIOS name, ServerB, and its corresponding IP address. If the NetBIOS name is not found in the LMHOSTS file, and no other name resolution method is configured on ClientA, an error message appears.


Specifying Domain Controllers

The most common use of the LMHOSTS file is to locate remote servers for file and print services. But the LMHOSTS file can also be used to find domain controllers providing domain services on routed TCP/IP networks. Examples of such domain controller activities include domain controller pulses (used for account database synchronization), logon authentication, password changes, master browser list synchronization, and other domain management activities.

Windows NT primary domain controllers (PDCs) and backup domain controllers (BDCs) maintain the user account security database and manage other network-related services. Because large Windows NT domains can span multiple IP subnets, it is possible that routers could separate the domain controllers from one another or separate other computers in the domain from the domain controllers. In a network that does not use WINS servers, LMHOSTS name resolution can be used to allow client computers to connect to domain controllers located across routers on different subnets.


Using Centralized LMHOSTS Files

The primary LMHOSTS file on each computer is always located in the %systemroot%\System32\Drivers\Etc directory. With Microsoft TCP/IP, you can include other LMHOSTS files from local and remote computers.

Network administrators can manage the LMHOSTS files used by computers on the network by providing one or more global LMHOSTS files on a central server. Windows NT-based computers on the network can be configured to import the correct and up-to-date computer name-to-IP-address mappings.

Users can import the LMHOSTS file from remote computers on the network by using #INCLUDE statements in the LMHOSTS file or by clicking Import LMHOSTS on the WINS Address tab of the Microsoft TCP/IP Properties dialog box. See Figure 10.1 in the section "Configuring TCP/IP to Use LMHOSTS Name Resolution" later in this chapter.

Alternatively, an administrator can use the replicator service to distribute multiple copies of the global LMHOSTS file to multiple servers.

Note

If network clients access a central LMHOSTS file, the computer on which the file is located must include the Registry parameter NullSessionShares for the LMHOSTS location. The NullSessionShares parameter is in the Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\ Parameters

For detailed information on Registry parameters, see online Help.


Creating the LMHOSTS File

Before configuring a computer to use the LMHOSTS file, you must create the primary LMHOSTS file on each computer, name the file LMHOSTS, and save the file in the %systemroot%\System32\Drivers\Etc directory.

You can create the file by using a text editor—for example, Notepad—to create, and change the LMHOSTS file because it is a simple text file. (An example of the LMHOSTS format is provided in the file named LMHOSTS.sam in the Windows NT %systemroot%\System32\Drivers\Etc directory. This is only an example file; do not use this file as the primary LMHOSTS file.)

The following sections describe the different types of entries that can be created and edited in the LMHOSTS file.


Creating Entries in the LMHOSTS File

Use the following rules to create and to edit entries in the LMHOSTS file:

  • Each entry must be on a separate line. The final entry in the file must be terminated by a carriage return.
  • Enter the IP address in the first column, followed by the corresponding computer (NetBIOS) name.

Caution You cannot add an LMHOSTS entry for a computer that is a DHCP client, because the IP addresses of DHCP clients change dynamically. To avoid problems, make sure that the computers whose names are entered in the LMHOSTS files are configured with static IP addresses.

  • The address and the computer name must be separated by at least one space or tab.
  • NetBIOS names can contain uppercase and lowercase characters and special characters. If a name is placed between double quotation marks, it is used exactly as entered. For example, "AccountingPDC" is a mixed-case name, and "HumanRscSr\0x03" generates a name with a special character.
  • Every NetBIOS name is 16 characters long. The user-definable portion of the NetBIOS name is the first 15 characters. The16th character is reserved to identify the network client service that registered the name. The most familiar example of a NetBIOS name is the computer name on any Windows-based computer. When the computer is started, the Microsoft Network Client services are started and register their names, which consist of the computer name plus a unique 16th character. For example, the name <computer_name[0x00]> is the Microsoft Workstation service; the name <computer_name[0x20]> is the Microsoft Server service. As you can see, the only difference between these two names is the 16th character. The 16th character makes it possible to uniquely identify each of the Network Client services running on the computer. For more information, see Appendix G, "NetBIOS Names."
  • Entries in the LMHOSTS file can represent Windows NT Server computers, Windows NT Workstation computers, Windows 95 computers, LAN Manager servers, or Windows for Workgroups 3.11 computers running Microsoft TCP/IP. There is no need to distinguish between different platforms in LMHOSTS.
  • The number sign (#) character is usually used to mark the start of a comment. However, it can also designate special keywords, as described in Table 10.1.

The keywords listed in the following table can be used in the LMHOSTS file for Windows NT-based computers. (LAN Manager 2.x, which also uses LMHOSTS for NetBT name resolution, treats these keywords as comments.)

Table 10.1 LMHOSTS Keywords

Keyword

Description

\0xnn

Support for nonprinting characters in NetBIOS names. Enclose the NetBIOS name in double quotation marks and use \0xnn notation to specify a hexadecimal value for the character. This enables custom applications that use special names to function properly in routed topologies. However, LAN Manager TCP/IP does not recognize the hexadecimal format, and so you surrender backward compatibility if you use this feature.

Note that the hexadecimal notation applies only to one character in the name. The name should be padded with blanks so that the special character is last in the string (character 16).

#BEGIN_ALTERNATE

Used to group multiple #INCLUDE statements. Any single successful #INCLUDE statement causes the group to succeed.

#END_ALTERNATE

Used to mark the end of an #INCLUDE statement grouping.

#DOM:<domain>

Part of the computer name-to-IP-address mapping entry that indicates that the IP address is a domain controller in the domain specified by <domain>. This keyword affects how the Browser and Logon services behave in routed TCP/IP environments. To preload a #DOM entry, you must first add the #PRE keyword to the line. #DOM groups are limited to 25 members.

#INCLUDE <filename>

Forces the system to seek the specified <filename> and parse it as if it were local. Specifying a Uniform Naming Convention (UNC) <filename> allows you to use a centralized LMHOSTS file on a server. If the server on which the specified <filename> exists is outside of the local broadcast subnet, you must add a preloaded entry for the server before adding the entry in the #INCLUDE section.

#MH

Part of the computer name-to-IP-address mapping entry that defines the entry as a unique name that can have more than one address. The maximum number of addresses that can be assigned to a unique name is 25. The number of entries is equal to the number of network cards in a multihomed computer.

#PRE

Part of the computer name-to-IP-address mapping entry that causes that entry to be preloaded into the name cache. (By default, entries are not preloaded into the name cache but are parsed only after WINS and name query broadcasts fail to resolve a name.) The #PRE keyword must be appended for entries that also appear in #INCLUDE statements; otherwise, the entry in the #INCLUDE statement is ignored.

#SG

Part of the computer name-to-IP-address mapping entry that associates that entry with a user-defined special (Internet) group specified by <name>. The #SG keyword defines Internet groups by using a NetBIOS name that has 0x20 in the 16TH byte. A special group is limited to 25 members.

The following example shows how all of these keywords are used:

102.54.94.102 "appname \0x14" #special app server 102.54.94.123 printsrv #PRE #source server 102.54.94.98 localsrv #PRE 102.54.94.97 primary #PRE #DOM:mydomain #PDC for mydomain #BEGIN_ALTERNATE #INCLUDE \\localsrv\public\lmhosts #adds LMHOSTS from this server #INCLUDE \\primary\public\lmhosts #adds LMHOSTS from this server #END_ALTERNATE

In the preceding example:

  • The servers named printsrv, localsrv, and primary are defined by using the #PRE keyword as entries to be preloaded into the NetBIOS cache at system startup.
  • The servers named localsrv and primary are defined as preloaded and also identified in the #INCLUDE statements as the location of the centrally maintained LMHOSTS file.
  • Note that the server named "appname \0x14" contains a special character after the first 15 characters in its name (including the blanks), and so its name is enclosed in double quotation marks.

The following sections further explain the use of the keywords #PRE, #DOM, #INCLUDE, and #SG.


Adding Remote System Names by Using #PRE

Using #PRE entries improves access to the identified computers because name and IP address mappings are contained in the computer's cache memory. However, by default, Windows NT limits the preload name cache to 100 entries. (This limit affects only entries marked with the #PRE keyword.)

If you specify more than 100 #PRE entries, only the first 100 #PRE entries are preloaded into the computer's cache. Any additional #PRE entries are ignored at startup and are used only if name resolution by the cache and IP broadcast fails. Windows NT then parses the complete LMHOSTS file which contains all the entries, including the #PRE entries that exceeded the cache limit of 100.

You can change the default maximum allowed #PRE entries by adding a MaxPreLoads value entry to the Registry. This value entry must be added to the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters

For example, the LMHOSTS file could contain the following information:

102.54.94.91 accounting #accounting server

102.54.94.94 payroll #payroll server

102.54.94.97 stockquote #PRE #stock quote server

102.54.94.102 printqueue #print server in Bldg 7

In this example, the server named stockquote is preloaded into the name cache, because it is tagged with the #PRE keyword. The servers named accounting, payroll, and printqueue would be resolved only after the cache entries failed to match and after broadcast queries failed to locate them. After non-preloaded entries are resolved, their mappings are cached for a period of time for reuse.


Adding Domain Controllers by Using #DOM

The #DOM keyword can be used in LMHOSTS files to distinguish a Windows NT domain controller from other computers on the network. To use the #DOM tag, follow the name and IP address mapping in LMHOSTS with the #DOM keyword, a colon, and the domain in which the domain controller participates. For example:

102.54.94.97 primary #PRE #DOM:mydomain #The mydomain PDC

Using the #DOM keyword to designate domain controllers adds entries to a domain name cache that is used to contact available controllers for processing domain requests. When domain controller activity such as a logon request occurs, the request is sent to the domain group name. On the local subnet, the request is broadcast and is picked up by any local domain controllers. However, if you use the #DOM keyword to specify domain controllers in the LMHOSTS file, Microsoft TCP/IP uses datagrams to also forward the request to domain controllers located on remote subnets. Adding more domain controllers in the LMHOSTS file will help distribute the load on all the controllers.

The following list contains guidelines for mapping important members of the domain by using the #DOM keyword.

  • It is recommended that the #DOM entries be pre-cached by using the #PRE keyword. Note that the #PRE keyword must precede the #DOM keyword.
  • For each local LMHOSTS file on a Windows NT computer that is a member in a domain, there should be #DOM entries for all domain controllers in the domain that are located on remote subnets. This ensures that logon authentication, password changes, browsing, and so on, all work properly for the local domain. These are the necessary minimum entries.
  • For local LMHOSTS files on all servers that can be backup domain controllers, there should be mappings for the primary domain controller's name and IP address, plus mappings for all other backup domain controllers. This ensures that promoting a backup to primary domain controller status does not affect the ability to offer all services to members of the domain.
  • If trust relationships exist between domains, all domain controllers for all trusted domains should also be listed in the local LMHOSTS file.
  • For domains that you want to browse from your local domain, the local LMHOSTS files should contain at least the name and IP address mapping for the primary domain controller in the remote domain. Again, backup domain controllers should also be included so that promotion to primary domain controller does not impair the ability to browse remote domains.

Names that appear with the #DOM keyword in the LMHOSTS file are placed in a special domain name list in NetBT. When a datagram is sent to this domain using the DOMAIN<1C> name, the name is resolved first by using WINS or IP broadcasts. The datagram is then sent to all the addresses contained in the list from LMHOSTS, and there is also a broadcast on the local subnet.


Adding User-defined Special Groups by Using #SG

You can group resources such as printers, or computers that belong to groups on the intranet, for easy reference, browsing, or broadcasting, by using the #SG keyword to define a special group in the LMHOSTS file. Special groups are limited to a total of 25 members. (If you are using WINS, they can also be defined by using the WINS Manager.)

Specify the name just as you would a domain name except that the keyword portion of the entry is #SG. For example:

102.54.94.99 printsrvsg #SG:mycompany #Specialgroup of computers

The preceding example results in a special group being created. In some cases you may want to just specify the name of a special group without specifying an IP address. This can be done by giving the name of the group preceded by #SG. For example:

printsrvsg #SG:mycompany #Specialgroup of computers

Addresses entered by using the LMHOSTS file become permanent addresses in the special group and can be removed only by using the WINS Manager.


Adding Multihomed Devices by Using #MH

A multihomed device is a computer with multiple network interface cards (NICs). A multihomed device can be defined by a single, unique name with which multiple IP addresses are associated.

You can provide multihomed name-to-IP-address mappings in the LMHOSTS file by creating entries that are specified by using the keyword #MH. An #MH entry associates a single, unique NetBIOS computer name to an IP address. You can create multiple entries for the same NetBIOS computer name for each NIC in the multihomed device, up to a maximum of 25 different IP addresses for the same name.

The format of the LMHOSTS entry that is used to specify name-to-IP-address mappings for multihomed devices is the same as the other keyword entries. For example, the entries required to map name to IP address for a multihomed device with two NICs are:

102.54.94.91 accounting #accounting server NIC 1 102.54.94.91 accounting #accounting server NIC 2


Defining a Central LMHOST File by Using #Include

For small- to medium-sized networks with fewer than 20 domains, a single common LMHOSTS file usually satisfies all workstations and servers on the intranet. An administrator can:

  • Use the Windows NT Replicator service to maintain synchronized local copies of the global LMHOSTS file.
  • Use centralized LMHOSTS files, as described in this section.

Use the #BEGIN_ALTERNATE and #END_ALTERNATE keywords to provide a list of servers maintaining copies of the same LMHOSTS file. This is known as a block inclusion, which allows multiple servers to be searched for a valid copy of a specific file. The following example shows the use of the #INCLUDE and #_ALTERNATE keywords to include a local LMHOSTS file (in the C:\Private directory):

102.54.94.97 primary #PRE #DOM:mydomain #primary DC 102.54.94.99 backupdc #PRE #DOM:mydomain #backup DC 102.54.94.98 localsvr #PRE #DOM:mydomain #INCLUDE c:\private\lmhosts #include a local lmhosts #BEGIN_ALTERNATE #INCLUDE \\primary\public\lmhosts #source for global file #INCLUDE \\backupdc\public\lmhosts #backup source #INCLUDE \\localsvr\public\lmhosts #backup source #END_ALTERNATE

Important

This feature should never be used to include a remote file from a redirected drive because the LMHOSTS file is shared between local users who have different profiles and different logon scripts. Even on single-user systems, redirected drive mappings can change between logon sessions.

In the preceding example, the servers primary and backupdc are located on remote subnets from the computer that owns the file. The local user has decided to include a list of preferred servers in a local LMHOSTS file located in the C:\Private directory. During name resolution, the Windows NT computer first includes this private file, then gets the global LMHOSTS file from one of three locations: primary, backupdc, or localsvr. All names of servers in the #INCLUDE statements must have their addresses preloaded using the #PRE keyword; otherwise, the #INCLUDE statement is ignored.

The block inclusion is satisfied if one of the three sources for the global LMHOSTS file is available and none of the other servers is used. If no server is available, or for some reason the LMHOSTS file or path is incorrect, an event is added to the event log to indicate that the block inclusion failed.


Configuring TCP/IP to Use LMHOSTS Name Resolution

By default, the LMHOSTS name resolution method is enabled when TCP/IP is installed on a computer. You can disable LMHOSTS name resolution by clicking to clear the Enable LMHOSTS Lookup check box on the WINS Address tab of the Microsoft TCP/IP Properties dialog box. It is recommended that you do not disable LMHOSTS name resolution because it provides a backup name service for WINS servers that are off-line or unavailable.

To use an LMHOSTS file from a remote computer or different directory on the local computer, click Import LMHOSTS as illustrated in the following figure.

Figure 10.1 Configuring TCP/IP to Enable LMHOSTS Lookup


Maintaining the LMHOSTS File

When you use an LMHOSTS file, be sure to keep it up-to-date and organized. Use the following guidelines:

  • Update the LMHOSTS file whenever a computer is changed or removed from the network.
  • Because LMHOSTS files are searched one line at a time from the beginning, list remote computers in priority order, with the ones used most often at the top of the file, followed by remote systems listed in #INCLUDE statements.
  • Use #PRE statements to preload into the local computer's name cache frequently accessed workstations and servers listed in the #INCLUDE statements. #PRE keyword entries should be entered at the end of the file, because these are preloaded into the cache at system startup time and are not accessed later. This increases the speed of searches for the entries used most often. Because each line is processed individually, any comment lines that you add will increase the parsing time.
  • Use the nbtstat command to remove or correct preloaded entries that might have been typed incorrectly or any names cached by successful broadcast resolution. You can reprime the name cache by using the nbtstat -R command to purge and reload the name cache, reread the LMHOSTS file, and then insert entries tagged with the #PRE keyword. For more information about using the nbtstat command, see the Help topic "TCP/IP Procedures Help" or refer to Appendix A, "TCP/IP Utilities Reference."


Troubleshooting LMHOSTS Files

When using the LMHOSTS file, problems such as failure to locate a remote computer can occur because one or more of the following errors are present in the LMHOSTS file:

  • The LMHOSTS file does not contain an entry for the remote server.
  • The computer (NetBIOS) name in the LMHOSTS file is misspelled. (Note that LMHOSTS names are automatically converted to uppercase.)
  • The IP address for a computer name in the LMHOSTS file is not valid.
  • The required carriage return at the end of the last entry in the LMHOSTS file is missing.


Chapter 11 - Using SNMP for Network Management

Simple Network Management Protocol (SNMP) is a network management standard widely used in TCP/IP networks and, more recently, with Internet Package Exchange (IPX) networks. Windows NT Server and Windows NT Workstation 4.0 include an SNMP service that allows Windows NT– based computers to be managed by using SNMP network management programs.

The information in this chapter is for the administrator who needs to understand SNMP and the SNMP-based service running under Windows NT 4.0.

This chapter begins with a review of basic SNMP concepts, and provides a glossary of the network management terms that are used throughout this chapter. The next two sections describe the SNMP network management standard and the Windows NT implementation of SNMP. The remaining sections in the chapter provide information about using and troubleshooting the SNMP service running under Windows NT. At the end of the chapter there is a list of reference materials that provide detailed information about SNMP, TCP/IP, and IPX.


Overview of SNMP

Simple Network Management Protocol (SNMP) is a network management protocol frequently used in TCP/IP networks to monitor and manage computers and other devices (such as printers) connected to the network. SNMP is supported in Windows NT Server and Windows NT Workstation by the SNMP service.

As part of the Internet TCP/IP protocol suite, SNMP is defined in the Internet Engineering Task Force (IETF) Request for Comments (RFCs) 1155, 1157, and 1213. The following table describes these RFCs.

Table 11.1 Titles and Descriptions of RFCs Defining SNMP

RFC # | Title | Description
1155 | Structure and Identification of Management Information for TCP/IP-based Internets | Defines the structure used to define data objects in a MIB.
1157 | Simple Network Management Protocol (SNMP) | Defines SNMP communication formats and operations.
1213 | Management Information Base for Network Management of TCP/IP-based Internets: MIB-II | Defines basic and industry-common types of managed-objects.


Requirements for Network Management

The term network management generally refers to specific administrative functions and the ability to perform these functions from a centralized computer, often referred to as a management console.

To perform centralized network management, the managing computer must be able to get data from other computers on the network, including the following:

  • Network protocol identification and statistics
  • Dynamic identification of computers attached to the network (referred to as discovery)
  • Hardware and software configuration data
  • Computer performance and usage statistics
  • Computer event and error messages
  • Program and application usage statistics


How SNMP Uses the Registry

The Registry, the operating system database on each Windows NT-based computer, contains information that is needed for network management. The SNMP service accesses the Registry and converts the information into a format that can be used by third-party SNMP network management programs.

Figure 11.1 The Windows NT Registry

The following sections — "Management Information Base," "Agents," and "Managers" — provide a high-level overview of the major software components of SNMP. Windows NT implements SNMP-based MIBs and an SNMP agent component to provide the necessary framework for SNMP network management.

SNMP uses a glossary of network management terms that may be unfamiliar to some readers. The following SNMP network management terminology is used in this chapter.

  • A host is any network device, including workstation and server computers.
  • Managed-objects are host hardware and software resources, such as a computer disk partition, that can be monitored (managed) by a network administrator at another computer on the network.
  • Each SNMP host (computer) has one or many management information bases (MIBs) that contain information about the managed-objects on that computer.
  • A manager is a software program that sends requests for data to other computers on the network. Typically, the manager includes a user interface (UI) for displaying status and data retrieved from the network computers and devices.
  • An SNMP management console is any computer running SNMP manager software.
  • An agent is a software program that processes manager requests for data by retrieving data from managed-objects on the computer. The agent program is part of the SNMP service running under Windows NT.


Management Information Base

A management information base (MIB) is a data file containing the managed-object descriptions and object values. Each host that is to be managed by SNMP must have a MIB that describes the manageable objects on that host.

Basically, a MIB will define the following for every object contained within that MIB:

  • the association between (1) the host hardware or software component (object) and (2) an object name and an object identifier.
  • A definition of the data type used to define the object.
  • A textual description of the object.
  • An index method used for objects that are a complex data type.
  • The read or write access that is allowed on the object.

RFC 1213 defines an industry-standard SNMP MIB referred to as MIB-II. Industry vendors, such as Microsoft, can define additional MIBs that allow unique hardware or software services developed by the vendor to be monitored and managed by SNMP management consoles.

Note

Additional MIBs that are supported by Windows NT Server are described in Appendix C, "MIB Object Types for Windows NT."


Object Identifiers

Each object in a MIB is identified by a universally unique label referred to as an object-identifier (OID). The object name space is implemented as a multi-part, hierarchical, naming scheme. A hierarchical naming scheme can be viewed as an inverted tree with the branches pointing downward. Each point where a new branch is added is referred to as a node. This OID is internationally accepted and allows developers and vendors to create new components and resources and assign a unique OID to each new component or resource.

The OID naming scheme is governed by the Internet Engineering Task Force (IETF). The IETF grants authority for parts of the name space to individual organizations, such as Microsoft. For example, Microsoft has the authority to assign the OIDs that can be derived by branching downward from the node in the MIB name tree that starts at 1.3.6.1.4.1.311.

Figure 11.2 A Managed-object Name Hierarchy

SNMP programs use the OID to identify the objects on each computer that can be managed by using SNMP. For example, when a network administrator requires information about managed-objects from some computer on the network, the SNMP management program sends a message over the network that requests information about the object as identified by the OID. The computer that receives the message can use the OID to retrieve information from the specific object on the computer and send the information back to the SNMP management program.


Agents

An agent is an SNMP program that must be installed on each managed computer in an SNMP-managed network. The Windows NT-based SNMP service includes an SNMP agent.

The agent program provides an interface to the MIBs and managed-objects installed on the computer. SNMP management programs send management requests to the computers on the network. The agent program on the computer receives the requests and processes them by retrieving information from the MIBs on the computer. The agent then sends the requested information back to the SNMP manager program that initiated the request.

The Windows NT-based SNMP service is an optional service that is installed after TCP/IP is installed on a Windows NT-based computer. After the SNMP service is installed on a computer, it automatically starts each time the computer is started.

When the agent program is started on a computer, it waits for SNMP requests from a manager program on the network management console (computer). When an agent program receives an SNMP message, it performs the requested get, get-next, and set operations.

The only operation that an agent spontaneously starts is a trap operation to alert the SNMP manager program that the computer has started, stopped, or is experiencing an extraordinary event (such as disk-full) on some managed-object on the computer.

In summary, the agent program performs the following operations:

  • The get operation retrieves a specific value about a managed-object, such as available hard disk space, from the host MIB.
  • The get-next operation returns the "next" value by traversing the MIB database of managed-object variables.
  • The set operation changes the value of a managed-object variable. Only variables whose object definitions allow read/write access can be set.
  • The trap operation sends messages to the SNMP management console when a change or error occurs in a managed-object.

Note

By installation default, the computer software port 161 is used to listen for SNMP messages and port 162 is used listen for SNMP traps. If you need to run multiple SNMP agents, you can change these port settings in the \systemroot\ System32\Drivers\Etc\Service\Service file.


Managers

SNMP management programs are referred to as managers. Managers obtain data about network devices and make this information available to a network administrator through textual, graphical, or object-oriented user interfaces. The manager program sends SNMP messages to network hosts. These messages are received by the agent on the host, and initiate the get, get-next, and set operations. The manager program waits (listens) for the SNMP messages from the agent that contain the results of the operation, and displays the information on the SNMP-management console or saves the data in a specified file or database.

As noted earlier, the SNMP service running under Windows NT is an SNMP agent, which is the necessary framework needed for network management. However a separate SNMP manager program is needed to perform management operations.

There are several SNMP manager utilities provided with the Windows NT Server Resource Kit compact disc. Other network management software can be obtained from Microsoft or from third-party vendors.


Windows NT-based Implementation of SNMP

The SNMP service running under Windows NT implements SNMP version 1 and provides an SNMP agent that allows remote, centralized SNMP management of:

  • Windows NT Server computers
  • Windows NT Workstation computers
  • Windows NT-based WINS server computers
  • Windows NT-based DHCP server computers
  • Windows NT-based Internet Information Server computers
  • LAN Manager server computers

Note

Network Driver Interface Specification (NDIS) 4.0-compliant peripheral devices attached to a Windows NT-based computer are also manageable by using the Windows NT-based SNMP service. If the device is to be managed by using SNMP, the device vendor must provide a device .inf file that can be registered in the Windows NT-based Registry.

The Windows NT-based SNMP agent is implemented as a service and can be installed on Windows NT-based computers that use the TCP/IP and IPX protocols. The TCP/IP protocol must be installed before installing SNMP. For more information about installing SNMP, see TCP/IP Help.

Note

You must install TCP/IP to be able to install the SNMP service, even if IPX is installed as the main network protocol.

The SNMP service is implemented as a Windows 32-bit service by using Windows Sockets over both TCP/IP and IPX/SPX. The additional Microsoft MIBs for DHCP, WINS, and the Internet Information Server, extend SNMP management to these Windows NT-based services. The agent programs that implement these additional MIBs are referred to as extension-agents. The extension-agent programs work with the master Windows NT-based agent program. These Windows NT-based extension-agents are implemented as Windows 32-bit dynamic-link libraries (DLLs).

The following diagram shows a simple interaction between an SNMP manager computer and a Windows NT-based computer with an SNMP agent program.

Figure 11.3 SNMP Manager and SNMP Agent Interaction


Windows NT SNMP Files

The following table describes the files that are installed on a Windows NT computer with the SNMP service installed.

Table 11.2 SNMP Service Files

File name | Description
Dhcpmib.dll | DHCP MIB extension-agent DLL is available only when the DHCP server is installed on a computer running Windows NT Server.
Iis.dll | Internet Information Server DLL is available only if the Internet Information Server is installed on a computer running Windows NT Server.
Inetmib1.dll | MIB-II extension-agent DLL.
Lmmib2.dll | LAN Manager extension-agent DLL.
Mgmtapi.dll | A Windows NT-based SNMP manager API that listens for manager requests, and sends the requests to and receives responses from SNMP agents.
Mib.bin | Installed with the SNMP service and used by the management API, Mgmtapi.dll, to map text-based object names to numerical OIDs.
Snmp.exe | SNMP agent service, a master (proxy) agent that accepts manager program requests and forwards the requests to the appropriate sub-agent-extension DLL for processing.
Snmptrap.exe | Receives SNMP traps from the SNMP agent and forwards them to the SNMP manager API on the management console. A background process, Snmptrap.exe is started only when the SNMP manager API receives a manager request for traps.
Winsmib.dll | WINS MIB extension-agent DLL, available only when the WINS server is installed on a computer running Windows NT Server.


MIB Implementation Notes

The Windows NT-based SNMP service includes MIB-II, based on RFC 1213, LAN Manager MIB-II, and Microsoft proprietary MIBs for DHCP, Internet Information Server, and WINS servers. Appendix C, "MIB Object Types for Windows NT," contains information about the Windows NT-based MIBs, and a description of each object in the MIB.

The Windows NT-based SNMP service supports multiple MIBs through an agent application programming interface (API). The separate extension-agent DLL is used to access the Windows NT-based MIBs. When the SNMP service is started, it loads the SNMP extension-agent DLLs. The extension-agent DLLs must be defined in the Registry in order to be loaded.

This use of DLLs in the SNMP service architecture allows new MIBs to be easily added. Microsoft and third-party developers can develop MIBs for new hardware and software components and easily integrate the new functionality by using SNMP.

The MIB name space assigned to Microsoft by the IETF starts at the node labeled 1.3.6.1.4.1.311. Microsoft has the authority to assign objects and OIDs to all objects that are developed below that node.

The following table identifies the Windows NT-based MIBs and top-most object (base object) from which all other objects in the MIB are derived. When the SNMP service is started, each extension-agent sends the OID for the base object in its MIB to the master agent program. This process identifies to the master agent the MIBs and managed objects that are actually installed on the computer.

Table 11.3 Base Object Identifiers

MIB name | Base object name | Base object identifier (OID) | Description
Internet MIB-II | iso.org.dod.internet. mgmt.mib-2 | 1.3.6.1.2.1 | Defines objects essential for either configuration or fault analysis. Internet MIB-II is defined in RFC 1213.
LAN Manager MIB-II | iso.org.dod.internet. private.enterprise. lanmanager | 1.3.6.1.4.1.77 | Defines objects that include such items as statistical, share, session, user, and logon information.
Microsoft DHCP server MIB | iso.org.dod.internet. private.enterprise. microsoft.software. dhcp | 1.3.6.1.4.1.311.1.3 | Contains statistics for the DHCP server, and DHCP scope information.
Microsoft Internet Information Server MIB | iso.org.dod.internet. private.enterprise. microsoft.software. iis | 1.3.6.1.4.1.311.1.7 | The FTP, Gopher, and HTTP server MIBs are derived from the Internet Information Server base object.
Microsoft WINS server MIB | iso.org.dod.internet. private.enterprise. microsoft.software. wins | 1.3.6.1.4.1.311.1.2 | Contains information about the WINS server, including statistics, database information, and push and pull data.


SNMP Security Implementation Notes

The SNMP security service is referred to as an authentication service. Simply put, a management request contained within an authenticated SNMP message is processed; a message that cannot be authenticated is not processed.

SNMP uses community names to authenticate messages. The community name can be thought of as a password shared by the SNMP management consoles and the SNMP managed hosts. All SNMP messages must contain a community name. The SNMP agent that receives an SNMP message checks (authenticates) the community name with the community name or names with which the SNMP service is configured. If the message contains a known community name, the message is processed. If the message contains a community name that is not configured on the host, the message is rejected and the host (optionally) sends a trap message to an SNMP management console. The trap message alerts the SNMP management console that a message authentication failure occurred at that host.

The default community name when the SNMP service is installed on a Windows NT-based computer is "public." Additional community names can be added or removed by selecting SNMP Service from the Network Services tab.

If you remove all the community names, including the default name, Public, the SNMP service on that Windows NT-based computer will authenticate and process SNMP messages containing any community name. This may or may not be desirable, but is expected behavior, as described in RFC 1157:

An SNMP message originated by an SNMP application entity that in fact belongs to the SNMP community named by the community component of said message is called an authentic SNMP message. The set of rules by which an SNMP message is identified as an authentic SNMP message for a particular SNMP community is called an authentication scheme. An implementation of a function that identifies authentic SNMP messages according to one or more authentication schemes is called an authentication service.

Clearly, effective management of administrative relationships among SNMP application entities requires authentication services that (by the use of encryption or other techniques) are able to identify authentic SNMP messages with a high degree of certainty. Some SNMP implementations may wish to support only a trivial authentication service that identifies all SNMP messages as authentic SNMP messages.

When there are no community names identified, the SNMP service implements the behavior as described in the preceding selection from RFC 1157.


Planning for SNMP Installation

Before installing the SNMP service, an administrator must identify the following information:

  • The contact person and location for the administrator of the local computer.
  • Community names that can be shared by hosts on the network.
  • IP address, IPX address, or network computer name of the SNMP management console, or consoles, that will be the destination for trap messages generated by computers within a specific community. (Not all SNMP management consoles must also be trap destinations.)


Agent Configuration

You configure the SNMP agent by selecting the Agent tab on the Microsoft SNMP Properties page. By default, the optional agent configuration options are checked, as illustrated in the following figure. You only need to add the name of the person to contact, such as the network administrator, and the location of the contact.

Figure 11.4 Configuring the SNMP Agent


Community Names

Community names provide a rudimentary security scheme for the SNMP service. You can add and delete community names by using the Security tab on the Microsoft SNMP Properties page. You can also filter the type of packets that the computer will accept. The following figure shows the Security tab.

Figure 11.5 Configuring SNMP Security

You must configure the SNMP service with at least one community name. The installation default is the Public community name. You can delete or change the default community name and add multiple community names.

There is no relationship between community names and domain or workgroup names. Community names serve as a shared password for groups of hosts on the network and should be selected and changed as you would any other password. Members of a community (hosts that share the same community name) are typically grouped by their physical proximity.

When the SNMP agent receives an SNMP request that does not contain the correct community name or that came from an unknown host, the SNMP agent can send a trap to one or more trap destinations (SNMP manager programs). The trap message indicates that the request failed authentication.

In the following example, there are two communities — Terraflora and Public.

Figure 11.6 SNMP Community Names

Only the agents and managers that are configured with the same community name can communicate with each other.

  • Agent 1 can send traps and other messages to Manager 2 because they are both members of the Terra Flora community.
  • Agent 2 through Agent 4 can send traps and messages to Manager 1 because they are all members of the Public (default) community.

The community names that are configured by using the Security tab are used when configuring Trap Destinations.


Trap Destinations

The SNMP agent generates trap messages, which are sent to an SNMP management console, the trap destination. Trap messages can be generated for changes such as host system startup, shutdown, or password violation. Trap destinations can be configured by a user, but the occurrences which generate a trap message are internally defined by the SNMP agent.

Trap destinations are identified by a computer name, IP address, or IPX address of the host or hosts on the network to which you want the trap messages sent. The trap destination must be a host that is running an SNMP manager program.

You configure the trap destination on a Windows NT-based computer by using the Traps tab on the Microsoft SNMP Properties page to enter the host name, IP address, or IPX address of the computer or computers running an SNMP manager program. The following figure shows the Traps tab of the Microsoft SNMP Properties page.

Figure 11.7 Configuring SNMP Traps


Using SNMP

When the SNMP service is installed, a network administrator can:

  • View and change parameters in the LAN Manager and MIB-II MIBs by using SNMP manager programs.
  • Monitor and configure parameters for any WINS servers on the network by using SNMP manager programs.
  • Monitor DHCP servers by using SNMP manager programs.
  • Use Performance Monitor to monitor TCP/IP-related performance counters which are ICMP, IP, Network Interface, TCP, UDP, DHCP, FTP, WINS, and Internet Information Server performance counters.
  • Use the Windows NT Server Resource Kit utilities to perform simple SNMP manager functions.

The following table describes SNMP-related utilities and files provided on the Resource Kit compact disc.

Table 11.4 SNMP-related Utilities and Files on theWindows NT Server Resource Kit Compact Disc

File name | Description
Dhcp.mib | DHCP server objects. See Appendix C, "MIB Object Types for Windows NT."
Wins.mib | Microsoft WINS server managed-objects. See Appendix C, "MIB Object Types for Windows NT."
Inetsrv.mib | Internet Information Server managed-objects. See Appendix C, "MIB Object Types for Windows NT."
FTP.mib | FTP server managed-objects. See Appendix C, "MIB Object Types for Windows NT."
Gopherd.mib | Gopher server managed-objects. See Appendix C, "MIB Object Types for Windows NT."
Http.mib | HTTP server managed-objects. See Appendix C, "MIB Object Types for Windows NT."
Lmmib2.mib | LAN Manager MIB-II. See Appendix C, "MIB Object Types for Windows NT."
Mib_ii.mib | MIB-II. See Appendix C, "MIB Object Types for Windows NT."
Smi.mib | Structure of Management Information MIB, as specified in RFC 1155. This file contains the global definitions used to define the objects in the other MIBs.
Mibcc.exe | SNMP MIB compiler used to produce a new Mib.bin that includes additional MIBs, for example, the Wins.mib.
Perf2mib.exe | MIB builder tool. See the section "Using Performance Monitor Counters with SNMP" later in this chapter.
Snmputil.exe | A simple SNMP browser manager application that implements Get, Get Next, Walk, and Trap network management operations to obtain information from Windows NT-based hosts. This application is also provided in the Windows 32-bit SDK.
Snmpmon.exe | SNMP Monitor is a utility that can monitor SNMP MIB objects on any number of remote hosts, and optionally log the results in an ODBC database. Snmpmon.exe uses an .ini file, for example Perfmib.ini.

For information on how to use any of the Windows NT-based Resource Kit utilities, see Resource Kit Tools Help.


Starting and Stopping the SNMP Service

After the SNMP service has been installed, it automatically starts when the computer is started and so you will usually not need to start the SNMP service. However, if you stop SNMP, you must then restart it because it does not automatically restart. Stopping a service cancels any network connections the service is using.

You can start and stop the SNMP service at the command prompt by typing the commands net start snmp and net stop snmp. You can also point to Control Panel and double-click the Services icon, then select SNMP and click the Start or Stop service buttons.

You must stop and restart the SNMP service to add new extension-agent DLLs and MIBs.

Note

The syntax for the net start snmp and net stop snmp commands has changed in Windows NT 4.0. SNMP error logging parameters are not supported and have been replaced by improved SNMP error handling in the Windows NT Event Log. The syntax for these commands is:

net start snmp

net stop snmp


Using SNMP to Manage DHCP, WINS, and Internet Information Servers

Using SNMP to Manage DHCP, WINS, and
Internet Information Servers

If you have installed the DHCP server, Internet Information Server, or WINS server software on a Windows NT-based computer on the network, you can monitor the DHCP, Internet Information Server, or WINS services by using an SNMP manager program.

The Windows NT-based DHCP server objects and Internet Information Server server objects can be monitored, but not configured, using SNMP.

WINS server objects can be configured and monitored by using SNMP. All but a few of the WINS configuration parameters that can be set by editing the Registry can also be set by using SNMP. For information about which WINS parameters can be set by using SNMP, refer to the description of the WINS MIB in Appendix C, "MIB Object Types for Windows NT." WINS objects that are defined with Access read-write can be configured by using SNMP.


Using Performance Monitor Counters with SNMP

All Performance Monitor counters installed on a computer can be viewed by using SNMP. To do this, use the Perf2MIB utility provided on the Windows NT Server Resource Kit compact disc to create a new MIB file which enumerates the counters in which you are interested. For additional information on how to use the Perf2mib.exe utility, see Resource Kit Tools Help.


Troubleshooting SNMP

This section discusses problems that you might encounter using SNMP, and what to do to resolve them.


Using the Event Viewer to Find SNMP Errors

SNMP error handling has been improved in Windows NT Server and Windows NT Workstation version 4.0. Manual configuration of SNMP error-logging parameters has been replaced by improved error handling that is integrated with the Event Viewer. Use the Event Viewer if you suspect a problem with the SNMP Service.

Note

Refer to the Windows NT Server Resource Guide for detailed information about using the Event Viewer.

To use Event Viewer

1. From the Start menu, point to Programs.

2. Click Administrative Tools on the Programs menu.

3. Double-click Event Viewer to display the System Log.

4. If any is any event is identified as SNMP in the Source column, double-click that row to display the Event Detail.

The following figure illustrates an SNMP event display in the Event Viewer.

Figure 11.8 SNMP Event Message


Modifying SNMP Parameters in the Registry

SNMP parameters and information about the SNMP extension-agent DLLs are contained in the Registry. You can view or change this information by using the Registry Editor (Regedt32.exe).

To start the Registry Editor

1. Click the Start button and click Run.

2. Type regedt32 in the command line box.

Warning Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the incorrect use of the Registry Editor can be solved.

Windows NT-based SNMP parameters are contained in the Registry in the following key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SNMP\Parameters

The following table describes the SNMP parameters contained in the Registry.

Table 11.5 SNMP Parameters Contained in the Registry

Registry parameter | Description
EnableAuthenticationTraps Units: Boolean Range: 0 (Off) or 1 (On) Default: On | A value of On (1) indicates that the SNMP service sends a trap whenever it receives a request that does not match any community name or host filter in its lists. Off (0) indicates that the SNMP service does not send a trap when this occurs.
ExtensionAgents | Contains information about each of the extension-agent DLLs to load.
ValidCommunities Units: names Range: — Default: public | Specifies one or more community names defining groups of hosts from which the SNMP service will accept requests.
TrapConfiguration Units: name Range: — Default: — | Specifies one or more host names, IP addresses, or IPX addresses defining hosts to which the SNMP service sends traps. Under the TrapConfiguration key, there is a key for each community. Under the ValidCommunities key, there are trap destination values for that community.


Timeout on WINS Server Queries

When querying a WINS server, it might be necessary to increase the SNMP timeout period on the SNMP management system. If some WINS queries work and others time out, increase the timeout period.


No Counters Appear in Performance Monitor

You must install the SNMP service to see any of the TCP/IP, Internet Control Message Protocol (ICMP), Network Interface, or UDP performance counters in Performance Monitor. When the SNMP service is installed, the following TCP/IP-related counters are added to Performance Monitor:

  • ICMP
  • IP
  • Network Interface
  • TCP
  • UDP

SNMP is not automatically installed when you install TCP/IP. See TCP/IP Help for information about installing and configuring SNMP on your local computer.

For more information about Performance Monitor and counters, refer to the Windows NT Server Resource Guide.

Note

When the IPX protocol is used as the main network protocol, the TCP/IP objects that can be monitored by using SNMP are null.


Error Using an IPX Address as a Trap Destination

If you enter an IPX address as a trap destination when installing the SNMP service, the following error message may appear when you restart your computer:

Error 3

This problem occurs if the IPX address has been entered incorrectly, using a comma or hyphen to separate a network number and a MAC address. For example, an SNMP manager program such as HP OpenView may normally accept an address such as this: 00008022,0002C0-F7AABD. However, the Windows NT-based SNMP agent does not recognize an address using a comma or hyphen between the network number and MAC address.

The address used for a trap destination must use the "8.12" format for the network number and Media Access Control (MAC) address.

To correct this problem, enter the IPX address for the trap destination in the 8.12 format. For example, the following format is valid:

xxxxxxxx.yyyyyyyyyyyy

where xxxxxxxx is the network number and yyyyyyyyyyyy is the MAC address.


Reference Materials

The following books contain more information about SNMP.

Network Management: A Practical Perspective

by Allan Leinwand and Karen Fang
Addison-Wesley Publishing Company, Inc 1993
ISBN 0-201-52771-5

SNMP, SNMPv2, and CMIP: The Practical Guide to Network-Management Standards

by William Stallings
Addison-Wesley Publishing Company, Inc 1993
ISBN 0-201-63331-0

The Simple Book: An Introduction to Management of TCP/IP-based Internets

by Marshall T. Rose
Prentice-Hall, Inc., 1994
ISBN 0-13-177254-6

Internetworking with TCP/IP

Volume 1: Principles, Protocols, and Architecture (third edition)
by Douglas E. Comer
Prentice-Hall, Inc., 1991
ISBN 0-13-468505-9

The following Requests for Comments (RFCs) are published by the Internet Engineering Task Force (IETF) and other working groups. The RFCs that define SNMP are listed in the following table.

Table 11.6 RFC Specifications about SNMP

RFC | Title
1155 | Structure and Identification of Management Information for TCP/IP-based Internets
1157 | Simple Network Management Protocol
1213 | Management Information Base for Network Management of TCP/IP-based internets: MIB-II

RFCs can be obtained via FTP from:

  • nis.nsf.net
  • nisc.jvnc.net
  • venera.isi.edu
  • wuarchive.wustl.edu
  • src.doc.ic.ac.uk
  • ftp.concert.net
  • ds.internic.net, or
  • nic.ddn.mil


Chapter 12 - Troubleshooting Tools and Strategies

Many excellent network troubleshooting tools are available for Windows NT Server and Windows NT Workstation. Most are included with the product or in the Windows NT Server and Windows NT Workstation Resource Kits. Microsoft Network Monitor is an excellent network tracing tool that is included in the Microsoft Systems Management Server product.

When troubleshooting any problem, it is helpful to use a logical approach. Some questions to ask are:

  • What does work?
  • What doesn't work?
  • How are the things that do and don't work related?
  • Have the things that don't work ever worked on this computer and network?
  • If so, what has changed since they last worked?

Troubleshooting a problem "from the bottom up" is often a good way to quickly isolate it. The troubleshooting tasks discussed in this chapter are organized using this "bottom up" approach.

The first section of this chapter gives an overview of TCP/IP troubleshooting tools. The next section discusses various TCP/IP troubleshooting tasks, followed by a section on using Performance Monitor and Network Monitor to analyze network behavior. The final section of this chapter provides information about common TCP/IP networking problems.


Overview of TCP/IP Troubleshooting Tools

The following table lists the diagnostic utilities included with Microsoft TCP/IP that can be used to identify or resolve TCP/IP networking problems.

Table 12.1 TCP/IP Diagnostic Utilities

Utility | Used to
arp | View the ARP (address resolution protocol) table on the local computer to detect invalid entries.
hostname | Print the name of the current host.
ipconfig | Display current TCP/IP network configuration values, and update or release TCP/IP network configuration values.
nbtstat | Check the state of current NetBIOS over TCP/IP connections, update the LMHOSTS cache, and determine the registered name and scope ID.
netstat | Display protocol statistics and the state of current TCP/IP connections.
nslookup | Check records, domain host aliases, domain host services, and operating system information by querying Internet domain name servers.
ping | Verify whether TCP/IP is configured correctly and that a remote TCP/IP system is available.
route | Print the IP route table, and add or delete IP routes.
tracert | Check the route to a remote system.

For complete details about the TCP/IP utilities, see Appendix A, "TCP/IP Utilities Reference."

These additional Windows NT tools can be used for TCP/IP troubleshooting:

  • Microsoft SNMP service — provides statistical information to SNMP management systems
  • Event Viewer — tracks errors and events
  • Performance Monitor — analyzes TCP/IP and WINS server performance
  • Registry Editor — allows viewing and editing of Registry parameters

In general, when troubleshooting it is usually best to first verify that the computer TCP/IP configuration is correct, and then verify that a connection and route exist between the computer and network host by using ping, as described in the section "Test Connection to the TCP/IP Network by Using Ping" later in this chapter.

Compile a list of what works and what doesn't work, and then study the list to help isolate the failure. If link reliability is in question, try a large number of pings of various sizes at different times of the day, and plot the success rate. When all else fails, using a protocol analyzer, such as Microsoft Network Monitor, can be helpful.


Identify the TCP/IP Configuration by Using IPConfig

When troubleshooting a TCP/IP networking problem, begin by checking the TCP/IP configuration on the computer experiencing the problem. Use the ipconfig command to get the host computer configuration information, including the IP address, subnet mask, and default gateway. Ipconfig is a command-line utility that prints out the TCP/IP-related configuration of the local computer.

Note

Windows 95 users use winipcfg in place of ipconfig.

When ipconfig is used with the /all switch, it produces a detailed configuration report for all interfaces, including any configured serial ports (RAS). Ipconfig output may be redirected to a file and pasted into other documents. This output of ipconfig can be reviewed to find any problems in the computer network configuration. For example, if the computer has been configured with an IP address that is a duplicate of an existing IP address, the subnet mask will appear as 0.0.0.0.

The following example illustrates the results of an ipconfig/all command on a computer that is configured to use a DHCP server for automatic TCP/IP configuration, and WINS and DNS servers for name resolution:

Windows NT IP Configuration Host Name . . . . . . . . . : davemac1.terraflora.com DNS Servers . . . . . . . . : 172.16.48.03 Node Type . . . . . . . . . : Hybrid NetBIOS Scope ID. . . . . . : IP Routing Enabled. . . . . : No WINS Proxy Enabled. . . . . : No NetBIOS Resolution Uses DNS : No Ethernet adapter Elnk31: Description . . . . . . . . : ELNK3 Ethernet Adapter. Physical Address. . . . . . : 00-20-AF-1D-2B-91 DHCP Enabled. . . . . . . . : Yes IP Address. . . . . . . . . : 172.16.48.10 Subnet Mask . . . . . . . . : 255.255.248.0 Default Gateway . . . . . . : 172.16.48.03 DHCP Server . . . . . . . . : 172.16.48.03 Primary WINS Server . . . . : 172.16.48.03 Secondary WINS Server . . . : 172.16.48.03 Lease Obtained. . . . . . . : Sunday, June 25, 1996 11:43:01 PM Lease Expires . . . . . . . : Wednesday, June 28, 1996 11:43:01 PM Ethernet adapter NdisWan5: Description . . . . . . . . : Physical Address. . . . . . : 00-00-00-00-00-00 DHCP Enabled. . . . . . . . : No IP Address. . . . . . . . . : 0.0.0.0 Subnet Mask . . . . . . . . : 0.0.0.0 Default Gateway . . . . . . :

If no problems appear in the TCP/IP configuration, the next step is to test the ability to connect to other host computers on the TCP/IP network.


Test Connection to the TCP/IP Network by Using Ping

Ping is a tool that helps to verify IP-level connectivity. When troubleshooting, the ping command is used to send an ICMP echo request to a target host name or IP address. Use ping whenever you need to verify that a host computer can connect to the TCP/IP network and network resources. You can also use the ping utility to isolate network hardware problems and incompatible configurations.

It is usually best to verify that a route exists between the local computer and a network host by first using ping and the IP address of the network host to which you want to connect. First try pinging the IP address of the target host to see if it will respond, because this is the simplest case. The command syntax is:

ping IP_address

Perform the following steps when using ping:

1. Ping the loopback address to verify that TCP/IP is installed and configured correctly on the local computer.

Ping 127.0.0.1

2. Ping the IP address of the local computer to verify that it was added to the network correctly.

Ping IP_address_of_local_host

3. Ping the IP address of the default gateway to verify that the default gateway is functioning and that you can communicate with a local host on the local network.

Ping IP_address_of_default_gateway

4. Ping the IP address of a remote host to verify that you can communicate through a router.

Ping IP_address_of_remote_host

Ping uses Windows Sockets-style name resolution to resolve a computer name to an IP address, so if pinging by address succeeds, but fails by name, then the problem lies in address or name resolution, not network connectivity. Refer to the section "Test IP-address-to-MAC-address Resolution by Using ARP" later in this chapter.

If you cannot use ping successfully at any point, check the following:

  • The computer was restarted after TCP/IP was installed and configured.
  • The local computer's IP address is valid and appears correctly in the IP Address tab of the Microsoft TCP/IP Properties dialog box.
  • IP routing is enabled and the link between routers is operational.

Type ping -? to see what command-line options are available. For example, ping allows you to specify the size of packets to use, how many to send, whether to record the route used, what time-to-live (TTL) value to use, and whether to set the "don't fragment" flag.

The following example illustrates how to send two pings, each 1450 bytes in size, to address 172.16.48.10:

C:\>ping -n 2 -l 1450 172.16.48.10 Pinging 172.16.48.10 with 1450 bytes of data: Reply from 172.16.48.10: bytes=1450 time=10ms TTL=32 Reply from 172.16.48.10: bytes=1450 time=10ms TTL=32

By default, ping waits only 750 ms for each response to be returned before timing out. If the remote system being pinged is across a high-delay link such as a satellite link, responses could take longer to be returned. The -w (wait) switch can be used to specify a longer timeout.


Understanding Address and Name Resolution

TCP\IP under Windows NT allows a computer to communicate over a network with another computer by using any of the following:

  • IP address
  • Host name
  • NetBIOS name

If you get the correct response when using ping with an IP address but an incorrect response when using ping with the host name or NetBIOS name, you have a name resolution problem. The following sections describe the processes that occur when using a host name or a NetBIOS name, instead of an IP address, to connect with hosts on a TCP/IP network.


Host Name Resolution

A DNS server or the HOSTS file is used when you use the TCP/IP utilities, such as ping. You can find the HOSTS file in the winnt\system32\drivers\etc directory. This file is not dynamic; entries are made manually. The format of the file is the following:

IP Address Friendly Name

172.16.48.10jsmith_nt # Remarks are denoted with a #.

Host Name Resolution Using a HOSTS File

The general process that occurs when using the HOSTS file for name resolution is summarized in the following steps.

1. Computer A enters a command using the host name of Computer B.

2. The HOSTS file on Computer A (in the \Systemroot\System32\Drivers\Etc directory) is parsed. When the host name of Computer B is found, it is resolved to an IP address.

3. The Address Resolution Protocol (ARP) is then used to resolve the IP address of Computer B to its hardware address. If Computer B is on the local network, its hardware address will be obtained by using the ARP cache or by sending a local broadcast asking for a reply from Computer B with its hardware address. If Computer B is on a remote network, ARP will determine the hardware address of the default gateway for routing to Computer B.

Note

Host name resolution using a Domain Name System (DNS) server is similar to the preceding steps. Instead of parsing the HOSTS file in Step 2, the DNS server looks up the host name of Computer B in its database and resolves it to an IP address.

The following types of problems can occur because of errors related to the HOSTS file:

  • The HOSTS file or the DNS server does not contain the particular host name.
  • The host name in the HOSTS file or in the command is misspelled or uses different capitalization. (Host names are case-sensitive.)
  • An invalid IP address is entered for the host name in the HOSTS file.
  • The HOSTS file contains multiple entries for the same host on separate lines; if so, the first entry is the one that is used.
  • A mapping for a computer name-to-IP-address was mistakenly added to the HOSTS file (rather than LMHOSTS).


Troubleshoot NetBIOS Name Resolutionby Using NBTStat

Troubleshoot NetBIOS Name Resolution
by Using NBTStat

NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. TCP/IP provides many options for NetBIOS name resolution, including local cache lookup, WINS server query, broadcast, DNS server query, and LMHOSTS and HOSTS lookup.

Nbtstat is a useful tool for troubleshooting NetBIOS name resolution problems. The nbstat command allows for removing or correcting preloaded entries.

  • nbtstat -n displays the names that were registered locally on the system by applications such as the server and redirector.
  • nbtstat -c shows the NetBIOS name cache, which contains name-to-address mappings for other computers.
  • nbtstat -R purges the name cache and reloads it from the LMHOSTS file.
  • nbtstat -a <name> performs a NetBIOS adapter status command against the computer specified by name. The adapter status command returns the local NetBIOS name table for that computer plus the MAC address of the adapter card.
  • nbtstat -S lists the current NetBIOS sessions and their status, including statistics, as shown in the following example:

    NetBIOS Connection Table Local Name State In/Out Remote Host Input Output ------------------------------------------------------------------ DAVEMAC1 <00> Connected Out CNSSUP1<20> 6MB 5MB DAVEMAC1 <00> Connected Out CNSPRINT<20> 108KB 116KB DAVEMAC1 <00> Connected Out CNSSRC1<20> 299KB 19KB DAVEMAC1 <00> Connected Out STH2NT<20> 324KB 19KB DAVEMAC1 <03> Listening


Test IP-address-to-MAC-address Resolutionby Using ARP

Test IP-address-to-MAC-address Resolution
by Using ARP

TCP\IP under Windows NT allows a computer to communicate over a network with another computer by using either an IP address, a host name, or a NetBIOS name. However, when one computer attempts to communicate with another computer using one of these three naming conventions, that name must ultimately be resolved to a hardware address, the medium access control (MAC) address.

The Address Resolution Protocol (ARP) allows a host to find the MAC address of a destination host on the same physical network, given the destination host's IP address. To make ARP efficient, each computer caches IP-to-MAC address mappings to eliminate repetitive ARP broadcast requests.

The arp command allows a user to view and modify the ARP table entries on the local computer. The arp command is useful for viewing the ARP cache and resolving address resolution problems.


Understanding IP Routing for Windows NT

Windows NT supports routing on both single- and multi-homed computers with, and without, the Multi-Protocol Router (MPR). MPR includes Routing Information Protocol (RIP) for TCP/IP and RIP for IPX. Routers use RIP to dynamically exchange routing information. RIP routers broadcast their routing tables every 30 seconds by default. Other RIP routers will listen for these RIP broadcasts and update their own route tables.

This section provides information about the Windows NT-based route table as used on single- and multi-homed computers with, and without, MPR. This background information will help with TCP/IP troubleshooting.


The Route Table

Even a single-homed TCP/IP host has to make routing decisions. The route table controls these routing decisions. You can display the route table by typing route print at the command prompt. The following is an example route table from a single-homed machine. Windows NT automatically builds this simple route table based on the IP configuration of your host.

Network Address Netmask Gateway Address Interface Metric 0.0.0.0 0.0.0.0 172.16.16.1 172.16.48.169 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 172.16.16.0 255.255.248.0 172.16.16.169 172.16.16.169 1 172.16.48.169 255.255.255.255 127.0.0.1 127.0.0.1 1 172.16.255.255 255.255.255.255 172.16.48.169 172.16.48.169 1 224.0.0.0 224.0.0.0 172.16.48.169 172.16.48.169 1 255.255.255.255 255.255.255.255 172.16.48.169 172.16.48.169 1

Network Address

The network address in the route table is the destination address. The network address column can contain:

  • Host address
  • Subnet address
  • Network address
  • Default gateway

Netmask

The netmask defines which portion of the network address must match in order for that route to be used. When the mask is written in binary, a 1 is significant (must match) and a 0 need not match. For example, a 255.255.255.255 mask is used for a host entry.

The mask of all 255s (all 1s) means that the destination address of the packet to be routed must exactly match the network address in order for this route to be used. For another example, the network address 172.16.48.0 has a netmask of 255.255.192.0. This netmask means that the first two octets must match exactly, the first 2 bits of the third octet must match (192=11000000), and the last octet does not matter. Because 18 in the decimal number system is equivalent to 00110000 in binary, a match would have to start with 0011. Thus, any address of 172.16 and the third octet of 48 through 255 (255=11111111) will use this route. This is a netmask for a subnet route and is therefore called the subnet mask.

Gateway Address

The gateway address is where the packet needs to be sent. This can be the local network card or a gateway (router) on the local subnet.

Interface

The interface is the address of the network card over which the packet should be sent out. 127.0.0.1 is the software loopback address.

Metric

The metric is the number of hops to the destination. Anything on the local LAN is one hop, and each router crossed after that is an additional hop. The metric is used to determine the best route.

Multihomed Router

The following is the default route table of a multihomed Windows NT host:

Network Address | Netmask | Gateway Address | Interface | Metric
0.0.0.0 | 0.0.0.0 | 172.16.24.1 | 172.16.24.193 | 1
0.0.0.0 | 0.0.0.0 | 172.16.40.1 | 172.16.40.139 | 1
127.0.0.0 | 255.0.0.0 | 127.0.0.1 | 127.0.0.1 | 1
172.16.24.0 | 255.255.248.0 | 172.16.24.193 | 172.16.24.193 | 1
172.16.24.193 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 1
172.16.40.0 | 255.255.255.0 | 172.16.40.139 | 172.16.40.139 | 1
172.16.40.139 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 1
172.16.40.255 | 255.255.255.255 | 172.16.40.139 | 172.16.40.139 | 1
224.0.0.0 | 224.0.0.0 | 172.16.24.193 | 172.16.24.193 | 1
224.0.0.0 | 224.0.0.0 | 172.16.40.139 | 172.16.40.139 | 1
255.255.255.255 | 255.255.255.255 | 172.16.40.139 | 172.16.40.139 | 1

To enable routing, check Enable IP Forwarding on the Routing tab of the Microsoft TCP/IP Properties dialog box. At this point, Windows NT will route between these two subnets.

A note on default gateways: in the TCP/IP configuration, you can add a default route for each network card. This will create a 0.0.0.0 route for each. However, only one default route will actually be used. In this case, the 199.199.40.139 is the first card in the TCP/IP bindings, and therefore the default route for this card is used. Because only one default gateway will be used, configure only one card to have a default gateway. This will reduce confusion and ensure the results you intended.

If the Windows NT router does not have an interface on a given subnet, it will need a route to get there. This can be done by adding static routes or by using MPR.

Adding a Static Route

The following is an example route.

Route Add 199.199.41.0 mask 255.255.255.0 199.199.40.1 metric 2

The route in this example means that to get to the 199.199.41.0 subnet with a mask of 255.255.255.0, use gateway 199.199.40.1, and that the gateway is 2 hops away. A static route will also need to be added on the next router, telling it how to get back to subnets reachable by the first router. With a network of a few routers or more, static routes can become very complicated.


Examine the Route Between Network Connectionsby Using Tracert

Examine the Route Between Network Connections
by Using Tracert

Tracert is a route tracing utility. Tracert uses the IP TTL field and ICMP error messages to determine the route from one host to another through a network. Sample output from the tracert command is shown in the ICMP section of this chapter.


Examine the Route Table by Using Route

Route is used to view or modify the route table. Route print displays a list of current routes known by IP for the host, including routes that Windows NT creates by default and routes learned by running RIP. Sample output is shown in the IP section of this chapter. Route add is used to add routes to the table, and route delete is used to delete routes from the table. Note that routes added to the table are not made permanent unless the -p switch is specified. Non-persistent routes last only until the computer is restarted.

In order for two hosts to exchange IP datagrams, they must both have a route to each other, or use default gateways that know of a route. Normally, routers exchange information with each other using a protocol such as RIP.


Display Current TCP/IP Connections and Statisticsby Using Netstat

Display Current TCP/IP Connections and Statistics
by Using Netstat

Netstat displays protocol statistics and current TCP/IP connections. Netstat -a displays all connections, and netstat -r displays the route table plus active connections. The -n switch tells netstat not to convert addresses and port numbers to names. The following is sample output:

C:\>netstat -e Interface Statistics Received Sent Bytes 3995837940 47224622 Unicast packets 120099 131015 Non-unicast packets 7579544 3823 Discards 0 0 Errors 0 0 Unknown protocols 363054211 C:\>netstat -a Active Connections Proto Local Address Foreign Address State TCP davemac1:1572 172.16.48.10:nbsession ESTABLISHED TCP davemac1:1589 172.16.48.10:nbsession ESTABLISHED TCP davemac1:1606 172.16.105.245:nbsession ESTABLISHED TCP davemac1:1632 172.16.48.213:nbsession ESTABLISHED TCP davemac1:1659 172.16.48.169:nbsession ESTABLISHED TCP davemac1:1714 172.16.48.203:nbsession ESTABLISHED TCP davemac1:1719 172.16.48.36:nbsession ESTABLISHED TCP davemac1:1241 172.16.48.101:nbsession ESTABLISHED UDP davemac1:1025 *:* UDP davemac1:snmp *:* UDP davemac1:nbname *:* UDP davemac1:nbdatagram *:* UDP davemac1:nbname *:* UDP davemac1:nbdatagram *:* C:\>netstat -s IP Statistics Packets Received = 5378528 Received Header Errors = 738854 Received Address Errors = 23150 Datagrams Forwarded = 0 Unknown Protocols Received = 0 Received Packets Discarded = 0 Received Packets Delivered = 4616524 Output Requests = 132702 Routing Discards = 157 Discarded Output Packets = 0 Output Packet No Route = 0 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0 ICMP Statistics Received Sent Messages 693 4 Errors 0 0 Destination Unreachable 685 0 Time Exceeded 0 0 Parameter Problems 0 0 Source Quenchs 0 0 Redirects 0 0 Echos 4 0 Echo Replies 0 4 Timestamps 0 0 Timestamp Replies 0 0 Address Masks 0 0 Address Mask Replies 0 0 TCP Statistics Active Opens = 597 Passive Opens = 135 Failed Connection Attempts = 107 Reset Connections = 91 Current Connections = 8 Segments Received = 106770 Segments Sent = 118431 Segments Retransmitted = 461 UDP Statistics Datagrams Received = 4157136 No Ports = 351928 Receive Errors = 2 Datagrams Sent = 13809


Using Performance Monitor

The Windows NT Server and Windows NT Workstation Performance Monitor can be used to view many different TCP/IP-related counters. Because it accesses statistics that have been gathered by the SNMP service, the SNMP service must be installed on Windows NT-based computers where TCP/IP statistics are to be monitored. Performance Monitor counters are available for NIC, IP, ICMP, UDP, TCP, and NetBT.

One of the features of Performance Monitor is that it allows counters from various systems to be monitored from a single management window. It also supports setting alert levels for the counters being monitored.


Using the Microsoft Network Monitor

Microsoft Network Monitor is a tool developed by Microsoft to make the task of troubleshooting complex network problems much easier and more economical. It is packaged as part of the Microsoft Systems Management Server product but can be used as a stand-alone network monitor.

In addition, Windows NT Server, Windows NT Workstation, and Windows 95 distribution media include the Network Monitor Agent software. Stations running Network Monitor can attach to stations running the agent software over the network or using dial-up (RAS) to perform monitoring or tracing of remote network segments. This can be a very useful troubleshooting tool.

Network Monitor works by setting the NIC to allow you to capture traffic to and from the local computer. Capture filters can be defined so that only specific frames are saved for analysis. Filters can be defined based on source and destination NIC addresses, source and destination protocol addresses, and pattern matches. Once a capture has been obtained, display filtering can be used to further narrow down a problem. Display filtering allows specific protocols to be selected as well.

Once a capture has been obtained and filtered, Network Monitor protocol parsing interprets the binary trace data into readable terms using parsing DLLs. The following sample Server Message Block (SMB) frame is shown fully parsed:

************************************************************************ Frame Time Src Other Addr Dst Other Addr Protocol Description 7 0.020 172.16.48.36 172.16.48.10 SMB C get attributes, File = \temp FRAME: Base frame properties FRAME: Time of capture = Jun 27, 1995 8:11:11.636 FRAME: Time delta from previous physical frame: 3 milliseconds FRAME: Frame number: 7 FRAME: Total frame length: 106 bytes FRAME: Capture frame length: 106 bytes FRAME: Frame data: Number of data bytes remaining = 106 (0x006A) ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol ETHERNET: Destination address : 00608C0E6C6A ETHERNET: .......0 = Individual address ETHERNET: ......0. = Universally administered address ETHERNET: Source address : 0020AF1D2B91 ETHERNET: .......0 = No routing information present ETHERNET: ......0. = Universally administered address ETHERNET: Frame Length : 106 (0x006A) ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 92 (0x005C) IP: ID = 0x4072; Proto = TCP; Len: 92 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0) IP: Precedence = Routine IP: ...0.... = Normal Delay IP: ....0... = Normal Throughput IP: .....0.. = Normal Reliability IP: Total Length = 92 (0x5C) IP: Identification = 16498 (0x4072) IP: Flags Summary = 2 (0x2) IP: .......0 = Last fragment in datagram IP: ......1. = Cannot fragment datagram IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 32 (0x20) IP: Protocol = TCP - Transmission Control IP: CheckSum = 0xC895 IP: Source Address = 09.48.16.172 IP: Destination Address = 172.16.48.10 IP: Data: Number of data bytes remaining = 72 (0x0048) TCP: .AP..., len: 52, seq: 344830227, ack: 2524988, win: 8166, src: 1677 dst: (NBT Session) TCP: Source Port = 0x068D TCP: Destination Port = NETBIOS Session Service TCP: Sequence Number = 344830227 (0x148DB113) TCP: Acknowledgment Number = 2524988 (0x26873C) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8166 (0x1FE6) TCP: CheckSum = 0xC072 TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 52 (0x0034) NBT: SS: Session Message, Len: 48 NBT: Packet Type = Session Message NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 48 (0x30) NBT: SS Data: Number of data bytes remaining = 48 (0x0030) SMB: C get attributes, File = \temp SMB: SMB Status = Error Success SMB: Error class = No Error SMB: Error code = No Error SMB: Header: PID = 0xCAFE TID = 0x0800 MID = 0x43C0 UID = 0x0800 SMB: Tree ID (TID) = 2048 (0x800) SMB: Process ID (PID) = 51966 (0xCAFE) SMB: User ID (UID) = 2048 (0x800) SMB: Multiplex ID (MID) = 17344 (0x43C0) SMB: Flags Summary = 24 (0x18) SMB: .......0 = Lock & Read and Write & Unlock not supported SMB: ......0. = Send No Ack not supported SMB: ....1... = Using caseless pathnames SMB: ...1.... = Canonicalized pathnames SMB: ..0..... = No Opportunistic lock SMB: .0...... = No Change Notify SMB: 0....... = Client command SMB: flags2 Summary = 32771 (0x8003) SMB: ...............1 = Understands long filenames SMB: ..............1. = Understands extended attributes SMB: ..0............. = No paging of IO SMB: .0.............. = Using SMB status codes SMB: 1............... = Using UNICODE strings SMB: Command = C get attributes SMB: Word count = 0 SMB: Byte count = 13 SMB: Byte parameters SMB: Path name = \temp 00000: 00 60 8C 0E 6C 6A 00 20 AF 1D 2B 91 08 00 45 00 .`..lj. ..+...E. 00010: 00 5C 40 72 40 00 20 06 C8 95 9D 39 09 8A 9D 39 .\@r@. ....9...9 00020: 0D 98 06 8D 00 8B 14 8D B1 13 00 26 87 3C 50 18 ...........&.<P. 00030: 1F E6 C0 72 00 00 00 00 00 30 FF 53 4D 42 08 00 ...r.....0.SMB.. 00040: 00 00 00 18 03 80 00 00 00 00 00 00 00 00 00 00 ................ 00050: 00 00 00 08 FE CA 00 08 C0 43 00 0D 00 04 5C 00 .........C....\. 00060: 74 00 65 00 6D 00 70 00 00 00 t.e.m.p...

The preceding parsed output example consists of three sections:

  • summary window
  • detailed description window
  • hex output

If you are sending traces to support personnel at Microsoft, they are most useful in electronic form rather than printed form, because they can be manipulated and scanned electronically. Large printed traces are time-consuming to read.


Using the Microsoft Knowledge Base

The Microsoft Knowledge Base (KB) is an excellent source of information on all aspects of Windows NT Server and Windows NT Workstation. It contains thousands of articles written by the support professionals in the Corporate Network Systems unit at Microsoft. Articles are updated daily, and topics include:

  • Installation and configuration information
  • Status on known problems and fixes
  • Service Pack updates
  • Technology discussions
  • Troubleshooting tips
  • Hardware-specific information

For example, to find additional information about the LMHOSTS file in Windows NT, query on the following words in the Microsoft Knowledge Base:

lmhosts and windows and nt

The Microsoft KB is available from many different sources, including the Internet (full-text search capabilities for WWW browsers on www.microsoft.com), several on-line services, and CD-ROM subscription services, such as Microsoft TechNet.


Troubleshooting Other Connection Problems

This section presents some possible TCP/IP symptoms with recommendations for using the diagnostic utilities to determine the source of the problems.


Error 53

To determine the cause of Error 53 when connecting to a server

1. If the computer is on the local subnet, confirm that the name is spelled correctly and that the target computer is running TCP/IP as well. If the computer is not on the local subnet, be sure that its name and IP address mapping are available in the LMHOSTS file or the WINS database.

Error 53 is returned if name resolution fails for a particular computer name.

2. If all TCP/IP elements appear to be installed properly, use ping with the remote computer to be sure that its TCP/IP software is working.


Long Connect Times When Using LMHOSTS for Name Resolution

To determine the cause of long connect times after adding an entry to LMHOSTS

· Because this behavior can occur with a large LMHOSTS file with an entry at the end of the file, mark the entry in LMHOSTS as a preloaded entry by following the mapping with the #PRE tag. Then use the nbtstat -R command to update the local name cache immediately.

Or, place the mapping higher in the LMHOSTS file.

As discussed in Chapter 10, "Using LMHOSTS Files," the LMHOSTS file is parsed sequentially to locate entries without the #PRE keyword. Therefore, you should place frequently used entries near the top of the file and place the #PRE entries near the bottom.


Cannot Connect to a Specific Server

To determine the cause of connection problems when specifying a server name

· Use the nbtstat -n command to determine what name the server registered on the network.

The output of this command lists several names that the computer has registered. A name resembling the computer's computer name should be present. If not, try one of the other unique names displayed by nbtstat.

The nbtstat utility can also be used to display the cached entries for remote computers from either #PRE entries in LMHOSTS or recently resolved names. If the name the remote computers are using for the server is the same, and the other computers are on a remote subnet, be sure that they have the computer's mapping in their LMHOSTS files.


Cannot Connect to Foreign Systems When Using Host Name

To determine why only IP addresses but not host names work for connections to remote computers

1. Make sure that the appropriate HOSTS file and DNS setup have been configured for the computer by checking the host name resolution configuration using the Network icon in Control Panel and then choosing the DNS tab in the Microsoft TCP/IP Properties dialog box.

2. If you are using a HOSTS file, make sure that the name of the remote computer is spelled the same and capitalized the same in the file and by the application using it.

3. If you are using DNS, be sure that the IP addresses of the DNS servers are correct and in the proper order. Use ping with the remote computer by typing both the host name and IP address to determine whether the host name is being resolved properly.


TCP/IP Connection to Remote Host Appears To Be Hung

To determine why a TCP/IP connection to a remote computer is not working properly

· Use the netstat -a command to show the status of all activity on TCP and UDP ports on the local computer.

The state of a good TCP connection is usually established with 0 bytes in the send and receive queues. If data is blocked in either queue or if the state is irregular, there is probably a problem with the connection. If not, you are probably experiencing network or application delay.


Troubleshooting Telnet

To determine why the banner displayed with Telnet identifies a different computer, even when specifying the correct IP address

1. Make sure the DNS name and HOSTS table are up to date.

2. Make sure that two computers on the same network are not mistakenly configured with the same IP address.

The Ethernet and IP address mapping is done by the ARP module, which believes the first response it receives. Therefore, the impostor computer's reply sometimes comes back before the intended computer's reply.

These problems are difficult to isolate and track down. Use the arp -g command to display the mappings in the ARP cache. If you know the Ethernet address for the intended remote computer, you can easily determine whether the two match. If not, use arp -d to delete the entry; then use ping with the same address (forcing an ARP), and check the Ethernet address in the cache again by using arp -g.

Chances are that if both computers are on the same network, you will eventually get a different response. If not, you might have to filter the traffic from the impostor host to determine the owner or location of the system.


Troubleshooting Gateways

To determine the cause of the message, "Your default gateway does not belong to one of the configured interfaces..." during Setup

· Find out whether the default gateway is located on the same logical network as the computer's network adapter by comparing the network ID portion of the default gateway's IP address with the network ID(s) of any of the computer's network adapters.

For example, a computer with a single network adapter configured with an IP address of 102.54.0.1 and a subnet mask of 255.255.0.0 would require that the default gateway be of the form 102.54.a.b because the network ID portion of the IP interface is 102.54.


Troubleshooting TCP/IP Database Files

The following table lists the UNIX-style database files that are stored in the \systemroot\System32\Drivers\Etc directory when you install Microsoft TCP/IP:

Table 12.2 UNIX-style Database Files

File name | Use
HOSTS | Provides host name-to-IP-address resolution for Windows Sockets applications
LMHOSTS | Provides NetBIOS name-to-IP-address resolution for Windows-based networking
Networks | Provides network name-to-network ID resolution for TCP/IP management
Protocols | Provides protocol name-to-protocol ID resolution for Windows Sockets applications
Services | Provides service name-to-port ID resolution for Windows Sockets applications

To troubleshoot any of these files on a local computer:

  • Make sure the format of entries in each file matches the format defined in the sample file originally installed with Microsoft TCP/IP.
  • Check for spelling or capitalization errors.
  • Check for invalid IP addresses and identifiers.


Reinstalling TCP\IP

When you attempt to reinstall a TCP\IP service, the following error message may appear:

The Registry Subkey Already Exists.

To correct this problem, ensure that all the components of a given TCP\IP service are properly removed and then remove the appropriate registry subkeys.

Warning Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the incorrect use of Registry Editor can be solved. Use this tool at your own risk.

Connectivity Utilities

If you have removed the TCP/IP service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE\Software\Microsoft\NetBT HKEY_LOCAL_MACHINE\Software\Microsoft\Tcpip HKEY_LOCAL_MACHINE\Software\Microsoft\TcpipCU HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\DHCP HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\LMHosts HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\'NetDriver'\Parameters\Tcpip HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\NetBT

SNMP Service

If you have removed the SNMP service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE\Software\Microsoft\RFC1156Agent HKEY_LOCAL_MACHINE\Software\Microsoft\Snmp HKEY_LOCAL_MACHINE\System\CCS\Services\Snmp

TCP\IP Network Printing Support

If you have removed the LPDSVC line printer service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Lpdsvc HKEY_LOCAL_MACHINE\Software\Microsoft\TcpPrint HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\LpdsvcSimple TCP\IP Services

If you have removed the simple TCP/IP services components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE\Software\Microsoft\SimpTcp HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\SimpTcp

DHCP Server Service

If you have removed the DHCP Server service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE\Software\Microsoft\DhcpMibAgent HKEY_LOCAL_MACHINE\Software\Microsoft\DhcpServer HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\DhcpServer

WINS Server Service

If you have removed the WINS Server service components, you must also remove the following registry subkeys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Wins HKEY_LOCAL_MACHINE\Software\Microsoft\WinsMibAgent HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Wins


Cannot Ping Across a Router when Using TCP/IP as a RAS Client

This problem occurs if you have Use default gateway on remote network selected under TCP/IP settings in the RAS Phonebook. This feature adds a route to the route table, and the new route allows IP addresses that are not resolved by other entries in the route table to be routed to the gateway on the RAS link. However, to use Internet utilities, such as a WEB browser or FTP, this feature must be enabled.

To ping or otherwise connect to computers in a remote subnet across a router while you are connected as a RAS client to a remote Windows NT RAS Server

· Use the route add command to add the route of the subnet you are attempting to use and tie that route to the local LAN gateway by adding the appropriate subnet mask.


Chapter 13 - Using NetBEUI with Windows NT

The NetBEUI protocol was one of the earliest protocols available for use on networks composed of personal computers. In 1985, IBM introduced NetBEUI to provide a protocol that could be used with software programs designed around the Network Basic Input/Output System (NetBIOS) interface.

NetBEUI was designed as a small, efficient protocol for use in department-sized local area networks (LANs) of 20 to 200 computers that do not need to be routed to other subnets. Today, NetBEUI is used almost exclusively on small, non-routed networks composed of computers running under a variety of operating systems that can include Microsoft Windows NT Server 3.5 and later, Windows NT Workstation version 3.5 and later, Microsoft LAN Manager, Windows for Workgroups, Windows 3.1, Windows NT version 3.1, and LAN Manager for UNIX as well as IBM PCLAN and LAN Server.

Windows NT-based NetBEUI, also referred to as NBF because it uses NetBEUI Frame (NBF), implements the IBM NetBIOS Extended User Interface (NetBEUI) 3.0 specification. This protocol provides compatibility with existing LANs that use the NetBEUI protocol and is compatible with the NetBEUI protocol driver shipped with past Microsoft networking products.

This chapter describes Windows NT-based NetBEUI and how it interfaces with the architecture of Windows NT Server and Windows NT Workstation to support connection-oriented and connectionless data transfer and to support a virtually infinite number of network sessions (logical connections between networked computers).

The information presented in this chapter is intended for the network administrator and support personnel who need to understand NetBEUI and to manage computers that connect to the network by using the NetBEUI protocol. You should be familiar with the architecture of Windows NT Server and Windows NT Workstation to understand the information discussed in this chapter. For information about the architecture of Windows NT Server, refer to Chapter 1,"Windows NT Networking Architecture" in this book. For information about the architecture of Windows NT Workstation, refer to the Windows NT Workstation Resource Guide.


Overview of Windows NT NetBEUI

The Windows NT-based implementation of NetBEUI, referred to as NBF throughout the remainder of this chapter, does the following:

  • Uses the Windows NT-based Transport Driver Interface (TDI) which provides an emulator for interpretation of NetBIOS network commands.
  • Uses the Windows NT-based Network Device Interface Specification (NDIS) version 3.0 with improved transport support and a full 32-bit asynchronous interface.

Note

Developers who require detailed information about the NDIS 4.0 specification should see the Windows NT Device Driver Kit (DDK).

  • Removes the NetBIOS session number limit.
  • Uses memory dynamically to provide automatic memory tuning.
  • Supports dial-up client communications with Remote Access Service (RAS) services.
  • Provides connection-oriented and connectionless data transfer services.


Interoperability Using NBF

NBF provides compatibility with computers running under the earlier operating systems of Microsoft LAN Manager and MS-Net, and IBM LAN Server. NBF can be used to connect LAN workstation and server computers, and to connect remote and dial-up clients, including laptop computers, to computers running the Windows NT-based RAS.

NBF can be used with programs that implement a variety of services based on the following application programming interfaces (APIs):

  • NetBIOS
  • Named Pipes
  • Mailslot
  • Network DDE (dynamic data exchange)
  • Remote Procedure Call (RPC) over NetBIOS
  • RPC over Named Pipes

NBF is most efficient when used for computers connecting to small to medium-sized, single-location networks. NBF is not a routable protocol like TCP/IP or IPX, although NBF does support a form of routing known as Token Ring routing, available only on IBM Token Ring networks. Additionally, NBF uses a single part naming scheme that does not support network segmentation used in most large networks.


Architecture of NBF

NBF is a transport driver that is composed of the following layers:

LLC802.2 Protocol

Corresponds to the Open Systems Interconnect (OSI) Logical Link Control (LLC) layer. It performs code, address, and control frame flow, and provides connectionless data transfer.

NetBIOS Frame Protocol (NBFP)

Corresponds to the OSI Transport and Session layers. It performs session establishment, multiplexing, and termination. It also performs message segmentation, delimiting, assembly, and acknowledgment.

Figure 13.1 shows the components of NBF and their relation to the OSI model.

Figure 13.1 The OSI Model and the Architecture of NBF

Notice that the upper edge of NBF, the NBFP component, connects to the bottom edge of the Windows NT-based Transport Driver interface (TDI). The lower edge of NBF, the LLC component, connects to the Network Driver Interface (NDIS).

Note

In the preceding illustration, the Network layer between NBFP and LLC is intentionally empty. In the OSI model, the Network layer lies between the Transport and LLC layers. However, NetBEUI uses IBM Token Ring source routing to perform network layer functions. Token Ring source routing conforms to a different standard, the IEEE 802.5 standard, and logically corresponds to the OSI Physical layer, not the OSI Network layer.

The following sections describe the NBF functions at its upper and lower edges:

  • "NBF's Interface to the Upper OSI Layers—The TDI Interface"
  • "NBF's Interface to the Lower OSI Layers—The NDIS Interface"


NBF's Interface to the Upper OSI Layers - The TDI Interface

Software programs that rely on NBFP for network communication require a transport driver that exposes the NetBIOS interface. However, the Windows NT-based transport drivers for NBF, IPX, and TCP/IP do not expose a NetBIOS interface; instead they expose the more flexible Windows NT TDI, as illustrated in both Figure 13.1 and Figure 13.2.

The Windows NT TDI provides a NetBIOS emulator that maps NetBIOS commands to TDI commands to support applications designed for use with NBFP. Note that Figure 13.2 illustrates how both NetBIOS-based and Windows Sockets-based applications use the TDI.

Figure 13.2 The Transport Driver Interface (TDI) and NBF

Note

In the preceding figure, the term "transport providers" refers to the binding of a specific transport driver, such as NBF, to a specific underlying NIC driver. Computers in which multiple NIC cards are installed will have multiple bindings.

This is how the TDI supports NetBIOS-based applications: NetBIOS commands are formatted as network control blocks (NCBs). When a program running on a Windows NT-based computer creates an NCB, the NetBIOS command is first processed by the Windows NT-based NetBIOS driver (Netbios.sys). Netbios.sys processes the NCB by mapping it to the corresponding TDI command or commands, and sends the TDI command to the Windows NT-based NetBEUI driver (Nbf.sys). (TDI calls implement the same general semantics as NetBIOS NCBs, but are optimized for a 32-bit kernel interface.)

In other words, unlike 16-bit Windows and MS-DOS transport clients which send NCBs directly to a NetBEUI driver, the NetBIOS network applications running on a Windows NT-based computer must direct the NCBs to a NetBIOS emulator. The NetBIOS emulator creates TDI requests and sends the TDI requests to the NBF transport driver.


NBF's Interface to the Lower OSI Layers - The NDIS Interface

The NBF transport driver processes the TDI requests as frames that are to be sent out on the network in the Logical Link Control (LLC) layer. This lower edge, the LLC layer, is the NBF layer that receives frames sent from a remote computer on the network.

NBF conforms to the IEEE 802.2 LLC protocol standard and performs the following functions:

  • Link establishment (connection-oriented data transfer)
  • Maintenance and termination
  • Frame sequencing and acknowledgment
  • Frame flow control
  • Connectionless data transfer

At the LLC layer, NBF binds, receives, and sends packets to the underlying NIC drivers by using the NDIS 4.0 interface. (See the earlier note about the term "transport providers.")

Communication within the LLC layer is based on service access points, links, and link stations. Each LLC client program identifies itself by registering a unique service access point (SAP). A SAP is actually a mechanism by which the layer above can programmatically access a particular service implemented by the layer below. A SAP can also be thought of as the address of a software port as defined by the OSI model. There are well-known SAPs, similar to the well-known ports of TCP/IP. Because NBF is a NetBIOS implementation, it uses the well-known NetBIOS SAP (0xF0). This is illustrated in Figure 13.3, which shows the relationship of the SAP to the LLC Layer.

Figure 13.3 The NBF LLC Layer and NDIS Interface to the Physical Layers

When a network client program uses LLC to send a frame on to the network, LLC specifies the client SAP as well as the destination SAP in the header of the LLC frame. The header of an LLC frame thus identifies the:

  • Source service access point (SSAP)¾the LLC client on the sending computer that created the frame.
  • Destination service access point (DSAP)—the LLC client on the receiving computer that should receive the frame.

The SSAP, DSAP, and NIC address of the destination client are all that is needed for unreliable connectionless data transfer, in which NBF transmits the message once or a specified number of times and is responsible only for ensuring that the frame is properly transmitted on the network medium. No acknowledgment from the destination client is required.

Reliable connection-oriented data transfer service requires establishment of a link between the sending and receiving LLC clients in which NBF is responsible for transferring the frame from the source client to the destination client and which requires an acknowledgment from the destination client that the frame is received. The link is established by using the sending client SAP, the destination client SAP, and the NIC address of the remote computer. Note that the NIC address of the receiving client can be specified as:

  • An individual computer's NIC address where the LLC frame is received by a single LLC client that registered the destination SAP.
  • A NetBIOS multicast address where the LLC frame is received by all LLC clients that have registered the multicast destination SAP.


NBF Removes the NetBIOS Session Limit

Early versions of NetBEUI used a 1- byte (8-character binary) number with a maximum decimal value of 254 to identify NetBIOS sessions. Session numbers were assigned per computer. That is, a computer using NetBEUI could support a maximum of 254 network connections.

NBF is not constrained by the session limitation of earlier versions of NetBEUI. NBF uses the TDI and a TDI 32-bit handle composed of the session number and the network address of the remote computer. This allows a virtually limitless range of unique numbers that can be used to uniquely identify sessions.

Using NBF, it is possible for a Windows NT Server with a single network adapter card to support simultaneous sessions that exceed the previous NetBEUI session limit of 256. For example, a Windows NT Server running NBF with a single network adapter card is able to support sessions with more than 1,000 clients.

The following figure illustrates the differences between NBF and other non-Windows implementations of NetBEUI.

Figure 13.4 Comparison between NetBEUI and Windows NT NBF Session Limits


NBF Dynamically Allocates Memory

A Windows NT-based computer running NBF automatically allocates the memory necessary to process the requests made by session clients. This means that NBF uses memory only when needed. For example, on a Windows NT-based computer that does not have an active network connection, very little memory will be used by the NBF protocol stack.

Because of this dynamic memory management, installing NBF on a Windows NT-based computer is easily done. It does not require additional configuration for number of sessions, packets, or buffers.


NBF Supports RAS Clients

NBF is used by remote computers that need to connect to a computer running Windows NT Server with RAS server. Because NBF dynamically allocates memory and is self-tuning, no configuration is required on the computer running the RAS client service. However, the WanNameQueryRetries parameter in the Registry can be changed to fine-tune RAS name query performance by using the Registry Editor. (This parameter is the WAN equivalent of the NameQueryRetries parameter.)


Connection-oriented and Connectionless Data Transfer

NBF supports both unreliable connectionless and reliable connection-oriented data transfer. Unreliable connectionless data transfer is also called datagram, or Type 1, operation.

Unreliable connectionless communication is similar to sending a letter in the mail. No response is generated by the receiver of the letter to tell the sender that the letter made it to its destination.

Note

Connectionless communications can be either unreliable or reliable. NBF provides only unreliable connectionless communications. Reliable connectionless communications is like a registered letter whose sender is notified that the letter arrived.

In unreliable connectionless communicaton, the transport protocol driver transmits the message once or a specified number of times, ensuring only that the message was properly transmitted to the network medium. The message can only be a single frame. Acknowledgment from the destination computer is not required.

Note

If reliable connectionless communication is required, NBF can be configured for certain communication commands to send a number of frames that will allow time for the destination computer to respond to the message. The number is based on retry Registry value entries, such as NameQueryRetries. The time between sending each frame is determined by timeout Registry entries, such as NameQueryTimeout.

Reliable connection-oriented communication is also called session, or Type 2, operation. Reliable connection-oriented communication provides reliable communications between two computers in a way that is analogous to a phone call where two callers connect, a conversation occurs, and then the connection is dropped when the conversation ends. A reliable connection requires more overhead than connectionless communications do.

In reliable connection – oriented communications, the transport protocol driver assumes responsibility for transferring the entire message from source to destination, and within an acceptable time period. Sequencing is provided; a message that is larger than the maximum transmit frame size can be broken down into multiple frames, sent across the network, and properly reassembled at the receiving computer.


Connectionless Traffic

Three types of NetBIOS commands generate connectionless traffic:

  • Name claim and resolution
  • Datagrams
  • Miscellaneous commands

These commands are sent as Unnumbered Information (UI) frames at the LLC sublayer.

To understand how Windows NT Server and Windows NT Workstation use retry and timeout values, consider what happens when the Windows NT-based computer running NBF registers its NetBIOS computer name. The Windows NT-based computer sends a multicast message containing an ADD_NAME_QUERY frame on to the network. Other computers on the network running NBF can retrieve and process the ADD_NAME_QUERY message. The multicast frames are sent a total of AddNameQueryRetries times at time intervals of AddNameQueryTimeout. This allows computers on the network enough time to inform the sending computer whether the name is already registered as a unique computer name or as a group name on the network.

Note

All Registry values discussed in this chapter are found under the following Registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbf


Connection-oriented Traffic

The net use command is an example of a connection-oriented communication, as illustrated in Figure 13.5.

Figure 13.5 Connection-oriented Network Traffic

When a user types net use at the command line to connect to a shared resource, NBF must first locate the server by sending UI-frames, and then initialize the link. This is handled by the redirector when it makes a connection to the NBF drivers by using the TDI interface. NBF begins the sequence by generating a NetBIOS Find Name frame. Once the server is found, a session is set up with Class-II frames which contain timing parameters following the 802.2 protocol standard (802.2 governs the overall flow of data).

The client computer sends a Set Asynchronous Balance Mode Extended (SABME) frame, and the server returns an Unnumbered Acknowledgment (UA) frame. Then the client sends a Receive Ready (RR) frame, notifying the server that it is ready to receive Informational (I) frames whose sequence number is currently 0. The server acknowledges this frame.

Once the LLC-level session is established, additional NetBEUI-level information is exchanged. The client sends a Session Initialize frame, and then the server responds with a Session Confirm frame. At this point, the NetBEUI-level session is ready to handle application-level frames (Server Message Blocks, or SMBs).

Reliable transfer is achieved with link-oriented frames by numbering the I-frames. This allows the receiving computer to determine whether the frames were lost and in what order they were received.

NBF improves performance for connection-oriented traffic through two techniques: use of adaptive sliding windows and use of link timers. The next two sections describe these techniques.

Adaptive Sliding Window Protocol

NBF uses an adaptive sliding window algorithm to improve performance while reducing network congestion and providing flow control. A sliding window algorithm allows the Windows NT-based computer using NBF to dynamically tune the number of LLC frames sent before an acknowledgment is requested. Figure 13.6 shows frames traveling through a two-way pipe.

Figure 13.6 Adaptive Sliding Window

If the sending computer could send only one frame on to the network and then had to wait for an acknowledgment (ACK), the sending computer would be underused. The frames would travel forward, and then ACKs for the received frames would have to travel back to the sending computer before it could send another frame. The number of frames that the sender is allowed to send before it must wait for an ACK is referred to as the send window.

The number of frames that a receiving computer is allowed to receive before sending an ACK to the sending computer is referred to as a receive window. In general, NBF has no receive window, unless it detects that the remote sending computer is running a version of IBM NetBEUI which does not support polling; in this case, NBF uses a receive window based on the value of MaximumIncomingFrames in the Registry.

The default value for MaximumIncomingFrames is 2 and this value does not dynamically change. It must be manually changed by using the Registry Editor. For additional information about the receive window, refer to "Using Windows NT NetBEUI in IBM LAN Server Networks" in the section "Troubleshooting NetBEUI" later in this chapter.

The adaptive sliding window protocol tries to determine the best sizes for the send window based on current network conditions. Ideally, the windows should be big enough so that maximum throughput can be realized. However, if the window gets too big, the receiving computer could get overloaded and drop frames.

Dropped frames cause significant network traffic because more frames have to be retransmitted. Dropped frames might be a problem on slow links or when frames have to pass over multiple hops to find the destination computer. Dropped frames coupled with large send windows generate multiple retransmissions. This traffic overhead might make an already congested network worse. Limiting the send window size can improve performance by reducing network traffic.

Link Timers

NBF uses three timers to help regulate network traffic: the response timer (T1), the acknowledgment timer (T2), and the inactivity timer (Ti). These timers are controlled by the values of the Registry parameters DefaultT1Timeout, DefaultT2Timeout, and DefaultTiTimeout, respectively.

The response timer is used to determine how long the sender should wait before it assumes that the I-frame is lost. After T1 milliseconds, NBF sends an RR frame and doubles the value for T1. If the RR frame is not acknowledged after the number of retries defined by the value of LLCRetries, the link is dropped.

Where the return traffic does not allow the receiver to send an I-frame within a legitimate time period, the acknowledgment timer begins, and then the ACK is sent. The value for this timer is set by the T2 variable, with a default value of 150 milliseconds. If the sender has to wait until the T2 timer starts in order to receive
a response, the link might be underused while the sender waits for the ACK. This rare situation can occur over slow links. On the other hand, if the timer value is too low, the timer starts and sends unnecessary ACKs, generating excess traffic. NBF is optimized so that the last frame that the sender wants to send is sent with the POLL bit turned on. This forces the receiver to send an ACK immediately.

The inactivity timer, Ti, is used to detect whether the link has gone down. The default value for Ti is 30 seconds. If Ti milliseconds pass without activity on the link, NBF sends an I-frame for polling. This is then ACKed, and the link is maintained.

Note

Remember that T2 is less than or equal to T1, which is less than or equal to Ti.

The T1 parameter is tuned dynamically on a per-link basis, based on link conditions and throughput. The value of the T1 parameter as specified in the Registry is used as the starting value for how long the process should wait for a response. This registry parameter can be changed. For example, if you know that the computer connects to the network on a slow link, the T1 registry parameter value can be increased. However, even if this parameter is not changed, NBF can detect the slow link quickly and automatically tune the T1 registry parameter value.

T2 and Ti are not adapted dynamically.


NBF Sessions

Each process that uses Windows NT-based NetBIOS can communicate with up to 254 different computers. Earlier implementations of NetBIOS supported only 254 sessions for the entire computer, including the workstation and server components.

The implementation of NetBIOS under Windows NT requires that an application do a few more things than have traditionally been required in other NetBIOS implementations, but the capacity for maintaining up to 254 sessions from within each process by using Windows NT-based NetBIOS is well worth the price.

Note that the 254-session limit does not apply to the default workstation or server components of Windows NT. The workstation and server services avoid the session limit problem completely by writing directly to the TDI, which is a 32-bit handle-based interface, instead of writing directly to the NetBIOS interface.

NBF also has a unique method of handling resources to create a virtually infinite (local computer memory permitting) number of connections, as described in the next section.


Session Limits

The 254-session limit is based on a key variable in the NetBIOS architecture called the Local Session Number (LSN). This is a 1-byte number (0 to 255) with several numbers reserved for system use. When two computers establish a session via NBF, there is an exchange of LSNs.

The LSNs on the two computers might be different. They do not have to match, but a computer always uses the same LSN for a given session. This number is assigned when a program issues a call for a Network Control Block (CALL NCB). The number is actually shared between the two computers in the initial frame sent from the calling computer to the listening computer. Figure 13.7 shows this session-creation frame exchange.

Figure 13.7 Multicast of NameQuery

The initial frame is a NameQuery frame. In earlier implementations of NBF, this frame was broadcast onto the network. All computers read the frame and check to see if they have the name in their name space and if there is a LISTEN NCB pending on the name. If there is a LISTEN NCB pending, the computer assigns a new LSN for itself. It adds the LSN to the response frame, satisfying the LISTEN NCB which now contains just the LSN used on that computer. Even though each computer knows the LSN of the other, the information is not used. The more important information for the two communicating partners is the network addresses that are part of the frames. As the frames are exchanged, each partner picks up the address of the other in the source address component of the frame received. The NBF protocol keeps the network address of the remote partner so that subsequent frames can be addressed directly.

Note

This process applies only to NBF connections. NetBIOS connections established by using NetBIOS over TCP/IP (NetBT) are handled differently.

Windows NT has to use the same NameQuery frame to establish connections with remote computers via NBF; otherwise, it would not be able to talk to existing workstations and servers. The NameQuery frame transmitted must contain the 1-byte-wide LSN to be used.

For example, suppose a computer running Windows NT Server and NBF assigns a session number of 1 to identify the session between itself and Computer A and also assigns the number 1 for the simultaneous session with Computer B. The computer running Windows NT Server can identify the different sessions because it uses the computer network address as part of the TDI handle to further identify each session. When the computer running Windows NT Server sends a session frame to either Computer A or Computer B, it uses the network address to direct the frame across the network. Therefore, Computer A does not receive the frames addressed to Computer B, and vice versa. However, if the computer running Windows NT Server and NBF establishes another session with Computer A, it must use a session number other than 1 to uniquely identify the second session.

A Windows NT Server computer running NBF can do this only when it is able to determine beforehand which adapter the session connection is going to be made to. Consider the following three scenarios:

1. A client connecting to a Windows NT computer running NBF.

When a client connects to a computer running NBF, NBF can inspect the incoming frame to determine the remote adapter's address and assign a session number for that adapter.

2. NBF connecting to a remote client with a unique NetBIOS name.

When NBF is connecting to a remote client, it first sends a FINDNAME frame. A response from the remote client means that the name is a unique name. NBF can then look at the remote adapter address in the response and assign a session number for that adapter because it knows that only that remote client owns this name.

3. NBF connecting to a remote client with a group NetBIOS name.

If the FINDNAME response indicates that the connection is being made to a group name, NBF has no way of knowing which adapter belonging to the group will respond when it tries to connect, and so it has to assign a session number on a global basis, just as NetBEUI did for all connections.

These scenarios show that NBF has no limit on sessions, unless it is establishing connections to group names, in which case the old NetBEUI limit still applies. To be accurate, if you have n group name connections, then you can have 254-n connections to any given remote client. If n is 0, then you can have a full 254 connections to a remote. If n is 253, you can still have 1 connection to each remote, but if n is 254, then no connections can be made until one of the existing ones is disconnected.


Breaking the 254-session Limit

NBF breaks the 254-session barrier by using a combination of two matrices, one maintained by NBF and one maintained by NetBIOS.

The matrix maintained by NBF is two-dimensional, as shown in Figure 13.8.

Figure 13.8 NBF and Its LSN Matrix

Along the side of this matrix are the LSN numbers 1 to 254. Across the top are the network addresses for the different computers that it has sessions with. In the cell defined by the intersection of the LSN and network address is the TDI handle, which relates back to the process that established the connection (either the CALL or LISTEN).

Note

The matrix concept and its contents are for illustration purposes only. The physical storage algorithm and exact contents are beyond the scope of this chapter.

The NameQuery frame from Windows NT contains the LSN number associated with the TDI handle that satisfies either the NCB CALL or the LISTEN. In the case of a CALL, it is not broadcast but is addressed directly to the remote computer.

The remaining question is how NBF gets the network address of the remote computer to add to its matrix to be used when doing the CALL. (It's easy on the LISTEN side because the address is in the NameQuery frame received.)

Figure 13.9 illustrates the NCB CALL and NCB LISTEN frames.

Figure 13.9 NameQuery Frames in NBF

The numbered items in Figure 13.9 represent the following:

1. The first frame (1) is the FindName frame of the NameQuery. However, an LSN of 0 is special; it indicates that it is a FindName frame. The FindName frame is broadcast on the network; when a remote computer responds to the frame, NBF on the local computer receives the network address of the remote computer.

2. The second frame (2) of the NameQuery is then sent directly to the remote computer by using the network address and a LSN value that indicates it is a CALL command. The remote client returns a successful FindName frame, even if no LISTEN NCB is posted against the name.

3. If no LISTEN NCB is posted against the name, frame (3) is sent.

4. The same frame is responded to by frame (4).

NBF must also address another problem—the LSN from the NBF matrix cannot be the one returned to the process issuing the CALL or LISTEN commands. NBF may have established connections with multiple remote computers with LSN=5, for example. Windows NT must return to each process an LSN number that uniquely defines its session.

As stated earlier, NBF uses the TDI handle to know which LSN and network address to send frames to, and each process has its own set of LSNs available to it. Therefore, there must be a component between the originating process and the TDI interface of NBF that translates a process ID and an LSN into a TDI handle. The component in the middle is Netbios.sys.

Figure 13.10 illustrates the Netbios.sys matrix, which is 254 LSNs per LAN adapter number per process. (In Windows NT, the LANA number identifies a unique binding of a protocol driver and one network adapter (NIC) driver.) In reality, each process can have up to 254 sessions per LANA number, not just a total of 254 sessions.

Figure 13.10 Netbios.sys Matrix

Netbios.sys builds a second matrix that has LSNs down the side, process IDs along the top, and TDI handles in the cells. It is the LSN from this table that is passed back to the originating process.

To further understand how Netbios.sys uses this matrix, suppose a process needs to establish a session with a remote computer. Before the process can issue the CALL NCB, it must issue a RESET NCB. This command signals Netbios.sys to allocate space in its TDI handle table, among other things. Once the RESET is satisfied, the process issues a CALL NCB to make a connection with a specific remote computer. This NCB is directed down to the Netbios.sys device driver. The driver opens a new TDI handle to NBF and sends the command to NBF.

NBF issues the first NAME_QUERY with LSN=0 to find the remote computer. When the remote computer responds, the network address is extracted from the frame, and a column in the NBF table is created. The second NAME_QUERY with an LSN is sent directly to the remote computer. When that frame is returned successfully, NBF returns from the TDI call to the Netbios.sys driver with a successful status code.

Netbios.sys then fills in the LSN from its table into the NCB and sends it back to the calling process.


Limited Network Routing Using NBF

Multi-location networks, such as a wide area network (WAN), require routing capabilities, while single-location, small- to medium-sized local area networks (LANs) generally do not require the overhead of a routing protocol.

NBF is not a routable protocol. It uses a single-part naming scheme which cannot be used to differentiate between computers belonging to multiple interconnected networks. NBF can provide a simple form of routing known as Token Ring source routing, and it can only be implemented on Token Ring networks.

Token Ring source routing occurs when NBF broadcasts a name query frame on a local token ring; if it doesn't receive a response in a set period of time, it enables source routing fields in the name query ring frame that force source routing bridges to receive and process the frame. The source routing bridges add additional routing information to the frame and send it to all other rings to which the bridge is connected. When the name query frame reaches the desired computer, that computer sends its computer name in the return message frame, using the routing information from the query to send the message directly to the originating computer. The originating computer caches the routing information and uses the cache to address subsequent frames.


Troubleshooting NetBEUI

This section discusses problems that you might encounter on a Windows NT-based computer on which the NetBEUI protocol is installed and running.

Note

NBF is the underlying implementation of the NetBEUI protocol installed on a computer running Windows NT Server or Windows NT Workstation. Most users are more familiar with the term NetBEUI. When troubleshooting, it is more common to use the term NetBEUI, rather than NBF.


Tuning NetBEUI Using Registry Parameters

When NetBEUI is installed on a Windows NT-based computer, it is installed with default configurations. Because NBF is largely self-tuning, no configuration is required when installing NetBEUI on a Windows NT–based computer.

If desired, however, you can change the default values for NetBEUI registry parameters. The NetBEUI startup parameters are found under the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\Services\NBF\Parameters

Warning Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the incorrect use of Registry Editor can be solved. Use this tool at your own risk.


Changing a NetBEUI Binding

You can manually change the NetBEUI bindings. The changes you can make are:

  • Enable a binding
  • Disable a binding
  • Move the order (priority) of the bindings up or down

To change a NetBEUI binding

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Bindings tab.

4. In Show Bindings for, click all protocols.

5. Double-click NetBEUI Protocol to display a list of bindings.

6. Select the binding you want to change and then click the appropriate action button.

7. Click OK.


Source Routing Not Supported in FDDI Network

Source routing is only supported for Token Ring networks. A network using a fiber data distributed interface (FDDI) for network communications cannot use NBF for source routing. To correct this problem, use transparent source routing or transparent bridging.


No Session Alive Frames

NBF does not use NetBIOS session alive frames to determine if the remote client is up. Instead, it sends LLC poll frames, which serve the same purpose. NBF will respond correctly to session alive frames, so this should cause no interoperability problems with other implementations of NetBEUI.


Using Windows NT NetBEUI in IBM LAN Server Networks

In general, NBF has no receive window, unless it detects that the remote sending computer is running a version of IBM NetBEUI which does not use network polling—for example, IBM LAN Server. NBF initiates a link with a remote computer in the same manner as IBM NetBEUI; however, NBF looks for a poll bit in received frames. If a frame is received that does not have the poll bit set, the Windows NT-based computer will wait until T2 expires before sending a frame ACK.

Note

When the poll bit is set in a received frame, NBF ignores the receive window and immediately sends an ACK.

For example, an IBM LAN Server computer is a non-polling system that may have a send window set to 1. If this the case, the registry parameter MaxIncomingFrames should be decreased from its default of 2 to 1. If not, the non-Windows NT-based computer will wait for an ACK from the Windows NT-based computer, which in this case will be sent only when the T2 time limit expires.

NBF uses a receive window based on the value of MaximumIncomingFrames in the Registry. The default value for MaximumIncomingFrames is 2, and this value does not dynamically change. It must be manually changed by changing the parameter default value in the Registry.

Note

When a Windows NT-based computer is using the MaxIncomingFrames receive window, it may not always send an acknowledgment frame after receiving exactly MaxIncomingFrames packets. This is because NBF will also wait until it receives an NDIS ProtocolReceiveComplete before sending the ACK. However, when the Windows NT-based computer receives POLL frames, it will ACK immediately (typically on return from NdisTransferData (synchronous communications) or within ProtocolTransferDataComplete (asynchronous communications).


NetBEUI Browser Does Not See TCP/IP Clients

Browsing on a computer running under Windows NT is based on a per protocol basis. In other words, there is a master browser for each protocol. Computers running only the NetBEUI protocol register with the master browser computer running the NetBEUI protocol. Computers running only NetBEUI get the master browser list from the master browser running NetBEUI. Because computers running only the TCP/IP protocol register with a master browser running TCP/IP, these computers will not be on the master browser list from a computer running only NetBEUI.


Chapter 14 - Using DLC with Windows NT

A Data Link Control (DLC) protocol interface device driver is included in Windows NT Workstation and Windows NT Server version 4.0. The DLC protocol is traditionally used to provide connectivity to IBM mainframes. It is also used to provide connectivity to local area network print devices that are directly attached to the network instead of to a specific computer. The DLC protocol is not designed to be a primary protocol for use between personal computers, and it needs to be installed only on computers performing the above-mentioned tasks and not on other computers on the network.

This chapter provides information for the network administrator and support personnel who need information about using the DLC protocol device driver for Windows NT to connect to IBM mainframes or to use print devices that are directly attached to the network. The following topics are discussed in this chapter:

  • Overview of Data Link Control (DLC) protocol
  • Installing the DLC protocol
  • DLC driver parameters in the Registry
  • Communicating with System Network Architecture (SNA) hosts using DLC
  • Changing the locally administered address
  • Using DLC to connect to Hewlett-Packard print devices


Overview of Data Link Control

The Data Link Control (DLC) protocol is a special purpose, non-routable protocol provided with Windows NT. Windows NT –based DLC provides applications only with direct access to the data link layer.

Windows NT–based DLC does not support the TDI interface as do other Windows NT–based transport protocols. Because DLC does not support the TDI, it cannot be used for communication with TDI client applications, such as the Windows NT redirector and server. Because the redirector cannot use DLC, this protocol is not used for normal session communication between Windows NT–based computers.

The DLC protocol driver provided with Windows NT enables the computer to communicate with other computers running the DLC protocol stack (for example, an IBM mainframe) and other network peripherals (for example, print devices such as a Hewlett-Packard HP 4Si that use a network adapter card (NIC) to connect directly to the network.)

The DLC protocol driver provides access to IEEE 802.2 class I and class II services. It also provides the direct interface to send and to receive raw 802.5, 802.3, and Ethernet type network frames. The interface consists of a dynamic-link library and a device driver.

Windows NT DLC contains an 802.2 Logical Link Control (LLC) Finite State Machine, which is used when transmitting and receiving type 2 connection-oriented frames. DLC can also transmit and receive type 1 connectionless frames, such as Unnumbered Information (UI) frames. Type 1 and 2 frames can be transmitted and received simultaneously.

Windows NT–based DLC works with either token ring or Ethernet Media Access Control (MAC) drivers and can transmit and receive Digital.Intel.Xerox (DIX) format frames when bound to an Ethernet MAC.

The DLC interface can be accessed from 32-bit Windows NT–based programs and from 16-bit MS-DOS-based and 16-bit Windows–based programs. The 32-bit interface conforms largely to the CCB2 interface, the segmented 16-bit pointers being replaced with flat 32-bit pointers. The 16-bit interface conforms to the CCB1 interface.

Note

For definitions of the CCB interfaces, see the IBM Local Area Network Technical Reference.


Installing the DLC Protocol

By default, the DLC protocol is not installed during Windows NT Setup. The DLC driver can be loaded when the system is first installed, or at any time thereafter.

To install DLC

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Protocols tab, and then click Add.

You also can configure network bindings for DLC. Network bindings are connections between network cards, protocols, and services. The order of the bindings is significant to DLC because an adapter is specified at the DLC interface as a number—typically 0 or 1 (although Windows NT DLC can support up to 16 physical adapters). The number corresponds to the index of the adapter in the DLC bindings section.

If you have only one NIC installed, DLC applications use a value of 0 to refer to this adapter, and you need not make any changes to the bindings. If you have more than one adapter card, you might want to modify the bindings.

You can manually change DLC bindings by clicking Network in Control Panel and selecting the Bindings tab. The changes you can make are to:

  • Enable a binding
  • Disable a binding
  • Move the order (priority) of the bindings up or down

To change a DLC binding

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Network, and then click the Bindings tab.

3. In Show Bindings for, enter All Protocols.

4. Double-click DLC Protocol.

5. Select the binding you want to change and click the appropriate button.

6. Click OK.


DLC Driver Parameters in the Registry

Unlike other Windows NT protocol drivers, DLC does not bind to a medium access control (MAC) driver until an adapter open command is issued. When an adapter is opened for the first time, the DLC protocol driver writes some default values into the Registry for that adapter. These values control the various timers that DLC uses, whether DIX frames should be used over an Ethernet link, and whether bits in a destination address should be swapped (that is, used when going over a bridge that swaps destination addresses).

The timer entries in the Registry are supplied because program-supplied timer values might not be sufficient. There are three timers used by DLC link communication:

  • T1¾the response timer
  • T2¾the acknowledgment delay timer
  • Ti¾the inactivity timer

Each timer is split into two groups—T x TickOne and T x TickTwo, where x is 1, 2, or i.

Typically, these timer values are set when a program opens an adapter and/or creates a Service Access Point (SAP).

The Registry contains entries used to modify timer values. Registry entries for DLC are found in the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DLC\Parameters
\<Adapter Name>

When you edit a timer entry value, the change takes effect the next time the adapter is opened (for example, by rerunning the application).


Communicating with SNA Hosts Using DLC

One of the major uses of the DLC protocol is connecting personal computers to Systems Network Architecture (SNA) hosts¾that is, IBM mainframe or midrange computers such as the AS/400.

SNA provides equivalent functionality to the OSI Network, Transport, Session, and Presentation levels (although functionality might differ at each level). Because the DLC layer and the OSI Data Link layer are almost identical in functionality, a programming interface was developed for the DLC layer and passed on to programmers wanting to use this level of interface. The interface is described in the IEEE 802.2 standard.

Note

DLC is not robust enough to handle multi-threaded programming.

Figure 14.1 compares the SNA and OSI models.

Figure 14.1 Comparison of SNA and OSI Models

With the Token Ring Interface Connection (TIC), any SNA host can communicate with a token ring network. With the LAN Interface Connection (LIC), an AS/400 computer can communicate with an Ethernet network.

Figure 14.2 illustrates a mainframe connectivity path using token ring.

Figure 14.2 Mainframe Connectivity Path Using Token Ring

The Microsoft SNA Server uses the DLC protocol device driver when communicating to mainframes by using the token ring interface. Detailed configuration and installation information is provided in the Microsoft SNA Server Installation Guide and the Microsoft SNA Server Administration Guide.


Changing the Locally Administered Address

There might be times when you want to change or override the network address of the NIC when running the DLC protocol. You might want to do this, for example, when communicating directly to a mainframe. Certain configurations of mainframe software require the network address of the devices connecting to it to follow a set format, and so it might be necessary to change the card's network address. You can do this through the Registry Editor.

The following example is for an IBM Token Ring adapter. This parameter is supported on other NICs as well, but not necessarily on all.

To change the address of an adapter card

1. Click Start, and then click Run.

2. Type regedit, and click OK.

3. When the Registry Editor starts, select the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ibmTOKMC01

4. On the Edit menu, click Add Value.

5. Type NetworkAddress in Value, select REG_SZ for data, and then click OK.

6. Type the 12-digit Locally Administered Address (LAA) that you need to communicate to the mainframe.

If you don't know this address, see your network administrator or operations group.

7. Close the Registry Editor and restart your computer for the modification to take effect.

8. From the command prompt, run the following command to report the active MAC address:

net config rdr

If the MAC address is the same as the LAA you entered in the Registry Editor, the LAA has taken effect.

For information about running the Registry Editor, use online Help and the keyword Registry.


Using DLC to Connect to Print Devices

You can also use DLC to provide connectivity to Hewlett-Packard local area network print devices that are directly attached to the network, not to a specific computer. The DLC protocol must be installed on the Windows NT-based print server that is used to configure and administer the network-attached print device.

To connect to and configure the Hewlett-Packard print device, you must install the DLC protocol and the Hewlett-Packard Network Port monitor on the Windows NT-based print server. Install the DLC protocol before using the Add Printer Wizard. Use the Add Printer Wizard to install the Hewlett-Packard Network Port and configure the print device.

Before starting the Add Printer Wizard:

  • Run self-test on the Hewlett-Packard print device to obtain the network adapter card address. The card address is a unique 12-byte number that is supplied by the card manufacturer.
  • Choose a logical name for the printer. This logical name will be used to identify the printer and will be associated to the card address.

To configure a Hewlett-Packard print device that is directly connected to the network

1. Click Start, point to Settings, and click Printers.

2. Double-click Add Printer.

3. Select My Computer, and click Next.

4. Click Add Port.

5. Select the Hewlett-Packard Network Port and click OK.

6. In Name, type the printer name.

7. If the print device is already attached to the network, select the appropriate card address in Card Address.

If the Hewlett-Packard print device is already attached to the network, the number you obtained from the print device self-test appears in the Address list box. If it does not appear, make sure that the print device is correctly attached and is connected on the same subnet as the Windows NT-based print server. DLC cannot be used to connect to printers on the far side of a router.

8. If the print device is not attached, or you are working off-line, type the card address number in Card Address.

9. Click OK.

The Add Printer Wizard will complete the configuration of the print device.

For more information about using the Print Wizard, see Help.


Chapter 15 - Remoteboot

The Remoteboot service is a Windows NT Server feature that starts MS-DOS, Microsoft Windows 3.1, and Microsoft Windows 95 clients over the network. You install and configure the Remoteboot service on the server and then customize it to be more effective for your particular network and for your users' needs.

For updated information about the Remoteboot service, see the <systemroot>\Rpl\Readme.txt file. The default location of the remoteboot directory is \systemroot<systemroot>\Rpl. If you choose a different location to install the remoteboot directory, substitute that location for <systemroot>\Rpl throughout this chapter.


Understanding the Remoteboot Service

This section describes the architecture and operation of the Windows NT Server Remoteboot service.

For complete information about Windows NT file systems, security, and network planning issues, see Windows NT Server Concepts and Planning. This information will help you take best advantage of Windows NT Server at your site.


The Remoteboot Process

When you start, or boot, a computer, the operating system is loaded into its memory. The Windows NT Remoteboot service supports personal computers running MS-DOS, Windows 3.1, and Windows 95 (also called clients or workstations) that boot using software on the server's hard disk instead of the client's hard disk. Each of these clients has a network adapter, with a Remote Initial Program Load (RPL) ROM chip, that retrieves startup and configuration software from the server when the client starts. The client does not need a hard disk. This process is known as booting remotely or the remoteboot process.

Figure 15.1 shows a possible configuration of remoteboot clients and servers.

Figure 15.1 The remoteboot process


How Does Remoteboot Work?

The Remoteboot service works by providing two kinds of resources at the server:

  • A boot block, which contains all the information needed to start the client when it boots
  • The remoteboot profile, which defines the operating system environment of the client after it boots

The boot block and remoteboot profile are sent across the network in frames. A frame is a chunk of data, with some extra information. Sending a frame can be thought of as mailing a package of data, with the address and instructions for its use written on it.

When a remoteboot client is powered up, the network adapter is initialized and broadcasts a FIND frame (a boot request), as shown in Figure 15.2. The Remoteboot service receives the FIND frame, which contains the client's adapter ID.

Figure 15.2 The remoteboot process: boot request

The Remoteboot service checks the remoteboot database on the server to see if a workstation record (a remoteboot database entry) already exists with this adapter ID. If it doesn't, the Remoteboot service records this adapter ID but does not boot the client. To boot the client, the administrator must convert this adapter ID record to a workstation record using Remoteboot Manager.

If a workstation record does exist with this adapter ID, the Remoteboot service sends a FOUND frame, containing the server's adapter ID, to the RPL ROM on the client. This is called a boot acknowledgment and is illustrated in Figure 15.3.

Figure 15.3 The remoteboot process: boot acknowledgment

The RPL ROM accepts the first FOUND frame it receives (it may receive more than one if several servers are running the Remoteboot service), and returns the SEND.FILE.REQUEST frame to the adapter ID of the server that sent the first FOUND frame. The following Figure shows the remoteboot client sending a boot block request.

Figure 15.4 The remoteboot process: boot block request

When the Remoteboot service receives the SEND.FILE.REQUEST frame, it uses FILE.DATA.RESPONSE frames to send a boot block to the RPL ROM (as shown in Figure 15.5). The workstation record in the remoteboot database specifies which boot block to send (either MS-DOS or Windows 3.1). When the RPL ROM receives the last FILE.DATA.RESPONSE frame, it transfers execution to the entry point of the boot block.

Figure 15.5 The remoteboot process: boot block transfer

The RPL ROM boots the operating system specified by the boot block as appropriate for the client. For a client running MS-DOS or Windows 3.1, this completes the basic boot process.

For a client intended to run Windows 95, the boot process continues. The client is now running Windows 95 real-mode (also identified as MS-DOS 7.0), using files on the remoteboot server. To complete the boot to Windows 95, the client does the following:

1. Creates a RAM disk. A RAM disk is an area of the computer's RAM memory set aside to operate as if it were a disk drive.

2. Copies Windows 95 real-mode files from the remoteboot server to the RAM disk.

3. Loads the Windows 95 real-mode network drivers and establishes a connection to a Server-Based Setup (SBS) server. The SBS server can be the same computer as the remoteboot server. An SBS server, described in the Microsoft Windows 95 Resource Kit, supports over-the-network installation of Windows 95 as well as shared installations (where some or all Windows 95 files reside on the server). For Windows NT remoteboot, the SBS server provides the Windows 95 files which the client uses to complete the Windows 95 boot process.

4. Connects to a server that has a machine directory with files specific to this client.


Why Use Remoteboot?

The Remoteboot service promotes the use of diskless clients by eliminating the need for a hard disk on each client. This has several advantages:

  • Increased network security by using clients that do not have disk drives that can be used to illegally copy data and to introduce viruses
  • Greater control over the distribution of information and software resources
  • Ease of updating software centrally
  • Reduced cost in buying and maintaining client computers

Using the Remoteboot service has advantages for clients with hard disks as well:

  • Easy upgrading of software and operating systems on many clients
  • Greater flexibility in standardizing clients while allowing custom configurations

In general, the Remoteboot service offers greater control to the network administrator.


Setting Up and Starting the Remoteboot Service

Before you can use the Remoteboot service, you must install a network adapter containing an RPL ROM chip on each client computer you plan to boot remotely. These adapters are available directly from network adapter manufacturers or from independent vendors. For more information about network adapters and RPL ROMs, contact your solution provider. A list of supported network adapters is provided in the next section of this chapter.

To set up the Remoteboot service (summary)

1. Install Windows NT Server on a computer that will be the remoteboot server.

There are three special considerations for the Remoteboot service:

  • The server's computer name must not have spaces in it.
  • It is strongly recommended that you install remoteboot files on a disk partition formatted with NT File System (NTFS) so that permissions are correctly set. Users will be able to read and write their own files in the remoteboot directory but not write to shared files or system configuration files. Also, the File Allocation Table (FAT) file system does not support more than approximately 100 remoteboot clients.
  • Install the Data Link Control (DLC) and NetBIOS Extended User Interface (NetBEUI) protocols and ensure that clients can communicate with the server using these protocols (arrange proper routing, bridging, etc.).

2. Install the Remoteboot service on the remoteboot server.

Or, convert an existing Microsoft LAN Manager for OS/2 remoteboot installation to run on Windows NT Server, and then install the Remoteboot service.

Note

Windows NT Server does not support remote booting of OS/2 clients, Windows for Workgroups clients, Windows NT Workstation clients, or Windows NT Server clients.

3. Install MS-DOS and/or Windows 3.1 operating system files on the remoteboot server.

If you are converting from LAN Manager remoteboot, this may not be necessary.

4. If you will have Windows 95 remoteboot clients, install Windows 95 real-mode (also identified as MS-DOS 7.0) files on the remoteboot server.

5. Start the Remoteboot service.

6. Check the installation for errors, including checking the Event Viewer log.

7. Create profiles (these define the working environment shared by one or more clients).

8. If you will have Windows 95 remoteboot clients, install a Server-Based Setup (SBS) server.

This can be the same computer as the remoteboot server or it can be a separate server on the network. The SBS server must run the NetBEUI protocol.

9. If you will have Windows 95 remoteboot clients, create a location for machine directories.

This can be on the same computer as the remoteboot server or SBS server, or it can be on a separate server on the network. The server containing machine directories must run the NetBEUI protocol.

This section provides step-by-step instructions for these actions. For instructions on managing remoteboot clients, see "Managing Remoteboot Clients" later in this chapter.


Disk Space Requirements

The first step in preparing to use the Remoteboot service is to ensure that the server has enough disk space for the files needed by the remote clients. Use the values in the following table as a guideline.

Table 15.1 Disk Space Requirements

Component | Disk space required
Microsoft Network Client version 2.2 for MS-DOS (LAN Manager version 2.2)¾ required for all client configurations | 5.1 MB
MS-DOS 3.30 | 0.7 MB
MS-DOS 4.01 | 1.5 MB
MS-DOS 5.00 | 2.8 MB
MS-DOS 6.x | 5.9 MB
Windows 3.1 | 12.4 MB
Windows 95 | 2.0 MB

Use this table to calculate the amount of disk space you need on the remoteboot server. For example, to install the Remoteboot service for a configuration of clients running MS-DOS 6.22, some with Windows 3.1, you need 23.4 MB of disk space, broken down as follows:

  • 5.1 MB for the Network Client 2.2 for MS-DOS files
  • 5.9 MB for the MS-DOS 6.22 files
  • 12.4 MB for the Windows 3.1 files

In addition, you need room for personal copies of remoteboot profiles (if needed) and for directories for each client, where people store their own data. The amount of space to allot per client is up to you. You can also define a separate server (or servers) to contain machine directories for Windows 95 clients, to distribute the load of storing client-specific data. Each Windows 95 client needs its own machine directory with a minimum of 8 MB of disk space; more if users install additional software.

Windows 95 remoteboot clients require 8 MB of RAM and must be 386-based or higher. The server you use as a Server-Based Setup server requires 90 MB of disk space to store Windows 95 files.


Supported Network Adapters

These specific network adapters are supported by the Remoteboot service for Windows 95, Windows 3.1, and MS-DOS on the client (for the latest list see <systemroot>\Rpl\Readme.txt):

Note

Only the ISA versions of these network adapter cards are supported for Windows 95 remoteboot clients. Note especially that the Remoteboot service does not support PCI, Token-Ring, or PNP adapters for Windows 95 remoteboot clients:

3Com EtherLink II

3Com EtherLink III

AMD Series 2100 Ethernet

Intel EtherExpress 16

Intel EtherExpress PRO

Novell NE2000

Western Digital/SMC EtherCard Plus (8000 series) (see Readme.txt for information about using the 8000 series with Windows 95)

The following network adapters are supported by the Remoteboot service for Windows 3.1 and MS-DOS on the client (for the latest list see <systemroot>\Rpl\Readme.txt):

3Com EtherLink

3Com EtherLink Plus

3Com EtherLink /MC

3Com EtherLink II

3Com EtherLink III

3Com TokenLink

3Com TokenLink III

3Com 3Station

AMD Series 2100 Ethernet

HP Ethertwist

IBM Token Ring

IBM Ethernet

Intel EtherExpress 16

Intel EtherExpress PRO

Madge Token-Ring

Nokia/ICL Ethernet IIe

Novell NE1000

Novell NE2000

Racal Interlan NI 5210

Racal Interlan NI 6510

Western Digital/SMC Ethernet

Western Digital/SMC EtherCard Plus (8000 series)

Most network adapters work best with the Remoteboot service when using their default settings. However, if you need to modify these default settings in the Protocol.ini files, these files are located in <systemroot>\Rpl\Bblock\Netbeui\adapter\Protocol.ini, where adapter is the name of the particular network adapter. For example, a Windows 95 client can have conflicts with interrupt 3 (IRQ3) for the network adapter.


Installing the Remoteboot Service on the Remoteboot Server

Have on hand the Windows NT Server compact disc. You will also need original product disks for any operating system that you want the remoteboot clients to run, such as MS-DOS or Windows 95 disks.

The installation procedure differs depending on whether you are installing a new remoteboot directory or converting an existing LAN Manager for OS/2 remoteboot directory. Use one of the two following procedures.

To install the Remoteboot service (with a new remoteboot directory)

1. If they are not already installed, install the DLC and NetBEUI protocols on the server. The Remoteboot service requires DLC and NetBEUI.

2. Click Start, point to Settings, and click Control Panel.

3. Double-click Network.

4. In the Network Settings dialog box, click Add Software.

5. In the Add Network Software dialog box, select the Remoteboot Service.

6. In the Remoteboot Setup dialog box, type the full path and directory name where you want to install the remoteboot directory.

The default value is <systemroot>\Rpl. This is the directory shown in descriptions and examples.

7. Click OK.

8. Complete the dialog boxes that appear.

For help with any dialog box, press F1.

See the post-installation information after the next procedure.

To install the Remoteboot service (converting a LAN Manager for OS/2 remoteboot directory)

1. Use the Windows NT Server Upgrade for LAN Manager tools to convert the LAN Manager server's user accounts and file permissions. Then the remoteboot conversion can properly assign permissions and user account properties.

2. On the Windows NT Server computer, delete the RPLUSER global group (it is created by the Upgrade for LAN Manager tools). The Fix Security command of Remoteboot Manager will create an RPLUSER local group.

Note that users who administer the Windows NT Remoteboot service must be members of the Administrators local group. The Upgrade for LAN Manager tools convert the LAN Manager RPLADMIN group to a Windows NT RPLADMIN global group, but it has no function under Windows NT.

3. Copy the entire remoteboot directory from the OS/2 server to the Windows NT Server computer.

For example, if the LAN Manager remoteboot directory is \\SERVER3\C$\LANMAN\RPL and the Windows NT remoteboot directory is C:\Winnt\Rpl, type the following command at the Windows NT Server computer:

xcopy /e \\server3\c$\lanman\rpl c:\winnt\rpl

Keep a copy of the Rpl directory for later reference. Be especially sure to keep backup copies of any .ini, .cnf, and .fit files that were modified from their default state.

4. If they are not already installed, install the DLC and NetBEUI protocols on the server.

The Remoteboot service requires DLC and NetBEUI.

5. In Control Panel, double-click Network.

6. In the Network Settings dialog box, click Add Software.

7. In the Add Network Software dialog box, click the Remoteboot Service.

8. In Remoteboot Setup, make the following choices:

  • In the Remoteboot Directory box, type the full path and directory name of the remoteboot directory on the Windows NT Server (for example, C:\Winnt\Rpl).
  • Select the Migrate Remoteboot Directory From LAN Manager 2.2 check box.

9. Click OK.

10. Complete the dialog boxes that appear.

For help with any dialog box, press F1.

11. Copy the new LAN Manager client software to locations in the Windows NT Server computer's Rpl directory, using the following commands:

xcopy /e d:\clients\rpl\bblock c:\systemroot\rpl\bblock
xcopy /e d:\clients\rpl\fits c:\systemroot\rpl\fits
xcopy /e d:\clients\rpl\rplfiles c:\systemroot\rpl\rplfiles

where d: is the computer's compact disc drive.

12. Run the rplcnv conversion program after remoteboot installation.

The rplcnv program converts the RPL.MAP and RPLMGR.INI files used by the LAN Manager Remoteboot service into the System.mdb and Rplsvc.mdb files used by the Windows NT Remoteboot service database.

This is the syntax for rplcnv:

rplcnv [path]

where path specifies an absolute path to the directory containing the RPL.MAP and RPLMGR.INI files. If this parameter is omitted, it is assumed that the files are in the current directory or in <systemroot>\Rpl.

13. Compare the new .ini, .cnf, and .fit files in the remoteboot directory to the backup copies you made before conversion.

If you had modified the OS/2 versions of these files, you may want to transfer those modifications to the Windows NT versions. Do not simply copy the OS/2 versions over the Windows NT versions, because you might overwrite new data.

14. In Step 11 you installed new configurations. If you have profiles that you want to preserve from the LAN Manager installation, modify the profiles' Autoexec.bat and Config.sys files as follows:

  • Autoexec.bat: @Rpllink is no longer needed; this file has been replaced with Rpllnk.sys, which is loaded from Config.sys.
  • Config.sys: Add the following line as the first line in the file:

    DEVICE=C:\BINR\RPLLNK.SYS

Whether you install a new Rpl directory or migrate from OS/2, the installation process creates the following major directories:

  • Rpl (at the location you specify during installation and with a different name if you want). This is the remoteboot directory.
  • Rpl\Bblock. This directory contains boot blocks for each client configuration.
  • Rpl\Fits. This directory contains file index table (FIT) files that translate references to a file on the client to a true path to the file on the server. For example, for a client using a profile shared with other clients, the FIT file would map C:\Config.sys to \\server\Rplfiles\Profiles\profile\Config.sys, where server is the server's name and profile is the profile for this client.
  • Rpl\Rplfiles. This directory contains files specific to each client as well as shared files such as profiles and operating system files. This directory is shared with the name Rplfiles.
  • Rpl\Rplfiles\Binfiles\Dosxxx. These directories contain shared MS-DOS system files.
  • Rpl\Rplfiles\Binfiles\Lanman.dos. This directory contains Microsoft Network Client version 2.2 for MS-DOS, the network software used by all remoteboot clients.
  • Rpl\Rplfiles\Binfiles\Win95. This directory contains shared Windows 95 real-mode (also identified as MS-DOS 7.0) system files.

The first time you run Remoteboot Manager and choose the Fix Security command, it creates the RPLUSER local group and assigns permissions as appropriate throughout the Rpl directory.

For a complete explanation of the remoteboot directory structure, see "Directory, File Index, and Configuration File Details" later in this chapter.


Installing MS-DOS Files on the Remoteboot Server

When a client starts and requests an MS-DOS remoteboot, the remoteboot server gives it a boot block, which will load some version of the MS-DOS operating system. The server can also provide Windows 3.1 for the client. You must copy MS-DOS and Windows 3.1 files to the server; they are not shipped with Windows NT Server.

Note

You must have a separate, valid, software license for each client computer, including remoteboot clients, that runs MS-DOS, Microsoft Windows 3.1, or Microsoft Windows 95.

In the following procedure you install MS-DOS files on the server. For information about how to install Windows 3.1 files, see "Installing Windows 3.1 for MS-DOS Clients" later in this chapter. For information about how to install Windows 95 files, see "Installing Windows 95 for Windows 95 Clients" later in this chapter. You cannot install Windows 3.1 or Windows 95 until you have at least one MS-DOS remoteboot client running.

To copy MS-DOS 6.2x files to the server

1. Check that the <systemroot>\Rpl\Rplfiles directory is being shared on the remoteboot server. It should have the share name Rplfiles.

2. From an MS-DOS client (running a version of MS-DOS 6.2x that you want to support on the remoteboot server), connect to the remoteboot server's Rplfiles share by typing:

net use v: \\server\rplfiles

where server is the name of the remoteboot server.

3. Copy all the MS-DOS files to the <systemroot>\Rpl\Rplfiles\Binfiles\Dosxxx directory, where xxx is the version number (for example, Dos622), by typing:

copy c:\dos\*.* v:\binfiles\dos622
attrib -s -h c:\io.sys
attrib -s -h c:\msdos.sys
copy c:\io.sys v:\binfiles\dos622
copy c:\msdos.sys v:\binfiles\dos622
attrib +s +h c:\io.sys
attrib +s +h c:\msdos.sys

As shown, you may need to remove the hidden file attribute in order to copy these files and then reset the attribute after copying. You can do this with the MS-DOS attrib command.

Note

Do not set the hidden or system file attributes on the new copies of the files in the <systemroot>\Rpl\Rplfiles\Binfiles\Dosxxx directory.

Copy files to an existing Dosxxx directory only; do not create a new directory. For example, any version of MS-DOS 6.2x must be copied to the existing Dos622 directory.

4. If you copied DOS files other than MS-DOS (such as PC-DOS), you must rename the following files. From the <systemroot>\Rpl\Rplfiles\Binfiles\Dosxxx directory on the remoteboot server, type:

rename ibmdos.com msdos.sys
rename ibmbio.com io.sys


Starting and Stopping the Remoteboot Service

The Remoteboot service is installed as a manual service, meaning that you must start it intentionally each time you want it to run. If you want it to start automatically each time the server starts, see the instructions in online Help for the Services icon in Control Panel.

To start or stop the Remoteboot service

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Services.

3. Click the Remoteboot service.

You may need to scroll down the list of services to reach it.

4. Click Start or Stop.

Pause and Continue have no effect on the Remoteboot service.

5. In the Services dialog box, click Close.

You can also use the net start remoteboot command to start the Remoteboot service and net stop remoteboot to stop it.


Starting Remoteboot Manager

Remoteboot Manager is an administrative tool for controlling the remoteboot process and managing remoteboot clients.

To start Remoteboot Manager

1. At the Windows NT Server computer, log on to a user account that belongs to the Administrators local group.

2. From the Network Administration program group, click the Remoteboot Manager icon.

3. If you want to administer a remoteboot server other than the local computer, click Set Focus on the Remoteboot menu.

Type the name of the remoteboot server, or choose the name from the Select Computer box.

Or, from the command line, type rplmgr (or rplmgr \\server, where server is the name of a Windows NT Server computer).


Checking the Remoteboot Installation

After you start the Remoteboot service for the first time, check the server's event log for entries related to the Remoteboot service. Use Event Viewer in the Administrative Tools group.

You should also use Remoteboot Manager's configuration and security checking features after installation and after you add or remove support for an operating system.

To check the remoteboot configuration

1. On the Configure menu, click Check Configurations.

2. Click Yes.

This checks which operating systems are available for remoteboot clients. Remoteboot Manager offers these as choices for profiles.

To check security settings in the remoteboot directory

1. On the Configure menu, click Fix Security.

2. Click Yes.

This overwrites permissions throughout the <systemroot>\Rpl directory, creates accounts for remoteboot clients and the RPLUSER local account (if they don't already exist), and updates the domain entry in Lanman.ini files for remoteboot clients to match the server's own domain/workgroup.


Managing Profiles

When you use Remoteboot Manager for the first time, you must decide which profiles you need. A profile is the working environment shared by one or more clients. It consists of the operating system, the client computer and architecture type, the network adapter type, and all the other information needed to boot a client.

Note

Remoteboot profiles are completely different from user profiles, which are used elsewhere in Windows NT Server.

To establish and name profiles, you choose from a list of configurations. A configuration is actually a template profile; a profile is created as a copy of one of the base configurations. Generally, you can find a configuration for any profile you want to create. Once the profiles are defined, it's easy to add clients.

Clients use profiles in either of two ways: sharing a profile or using a personal copy of a profile. The profile is the same in either case; the difference is in how the client uses it.

A profile can be shared by a group of similar client computers that use the same startup information. (All of the clients have the same Config.sys, Lanman.ini, and other configuration files, and those files are read-only.) For example, you may want to have a common profile that is shared by accounting, and another profile for sales and marketing. Or, you may want to create a profile shared by all Windows 3.1 users. Keep in mind, however, that the client computer architecture must be similar enough that the clients can share startup files. Clients that share profiles get their environment from a <systemroot>\Rpl\Rplfiles\Profiles\profile directory (where profile is the name of the profile).

Sharing profiles is not practical in all cases. For example, a client may need customized system configuration files (like Config.sys). In this case, the client should use a personal copy of a profile. Changes to the startup information affect only the single client. Clients that have a personal copy of a profile get their environment from a <systemroot>\Rpl\Rplfiles\Machines\cname\profile\Pro directory (where cname is the computer name and profile is the name of the profile). Users can edit any of the files in that directory, such as Config.sys.

When you upgrade operating systems and make software changes, you need to install them separately to each profile and copy of a profile.

To create a profile

1. On the Remoteboot Manager Remoteboot menu, click New Profile.

2. In Profile Name, type a name for this profile [no more than 16 characters, with no spaces or backslashes(\)].

3. In Configuration, enter a configuration.

If the configuration you want is not present, you must install the appropriate operating system (see "Installing MS-DOS Files on the Remoteboot Server" earlier in this chapter) and check the configuration (on the Configure menu, click Check Configurations).

4. In Description, type a comment for the profile.

The description should summarize the profile for easy recognition, such as MS-DOS 6.22 VGA & 3Com 503 EtherLink II adapter.

5. Click OK.

To change a profile

1. Select an existing profile in Remoteboot Manager.

2. On the Remoteboot menu, click Properties.

3. Change the description of the profile, and then click OK.

You can change only the description. To change any other settings, you must create a new profile.

To delete a profile

1. Select an existing profile in Remoteboot Manager.

2. On the Remoteboot menu, click Delete.

3. If a message appears telling you that clients (workstation records) are still assigned to this profile, you can delete or reassign all of the clients at one time:

  • In the error message dialog box, click OK.
  • Select the profile.
  • On the View menu, click Workstations In Profile.
  • Select all of the workstation records (press CTRL and click all of the workstation records).
  • On the Remoteboot menu, click Delete.

Or, on the Remoteboot menu, click Properties. Choose a new profile for all of the clients, and then click OK.

4. In the Confirmation dialog box, click OK.

Once you have profiles set up, most remoteboot administration consists of managing the individual clients.


Managing Remoteboot Clients

When you have installed the Remoteboot service and the MS-DOS operating system files, and you have defined some profiles, you can use Remoteboot Manager to manage the remoteboot clients. You must boot at least one client on MS-DOS before you can install Windows 3.1 or Windows 95 remoteboot clients.

This section provides procedures for:

  • Enabling and disabling the hard disk on a client.
  • Adding a client to the Remoteboot service.
  • Removing a client from the Remoteboot service.
  • Installing Windows 95 for Windows 95 clients (includes setting up a Server-Based Setup server and, optionally, a server to hold machine directories).
  • Installing Windows 3.1 for MS-DOS clients.

When a user starts a remoteboot client, what appears as the client's C drive is actually mapped to various locations on servers, such as a personal directory on a separate server. For an MS-DOS or Windows 3.1 client, the remoteboot server maps directories and files from various locations to the virtual C drive using a File Index Table (FIT) file; for more information, see "File Index Tables" later in this chapter. If the remoteboot client has a hard disk, the hard disk appears as drive D. Floppy disk drives keep their original drive letters.

Before you can use the Remoteboot service, each remoteboot client must have a network adapter with an RPL ROM chip installed. For a list of supported network adapters, see "Setting Up and Starting the Remoteboot Service" earlier in this chapter.


Enabling Remoteboot on a Client's Hard Disk

Before a client with a hard disk can be booted remotely, its hard disk must be properly configured for the Remoteboot service. This does not prevent users from accessing the hard disk after the client is booted.

Use the Microsoft Network Client version 2.2 rplenabl utility to prepare the client to use the Remoteboot service. Later, if you want to boot the client using its hard disk, run the rpldsabl utility to disable the remoteboot configuration.

Note

Some RPL ROMs will take control of the client even though the hard drive is enabled, and so you may not need to run the rplenabl (or rpldsabl) utility on these clients. Try simply booting the computer, and then use rplenabl if needed.

To configure a client's hard disk for the Remoteboot service

1. Insert a formatted MS-DOS floppy disk in the remoteboot server's floppy disk drive.

2. Copy the Rplenabl.exe and Rpldsabl.exe programs to the floppy disk by typing:

copy c:\systemroot\rpl\rplfiles\binfiles\binr\rpl??abl.exe a:

where a: is the floppy disk drive.

3. Start the remoteboot client, booting MS-DOS from the local hard disk.

4. Put the disk with the Rplenabl.exe program in the client's floppy disk drive and type:

a:rplenabl

where a: is the client's floppy disk drive.

5. Remove the disk and press CTRL+ALT+DEL.

The Remote Program Load Module information is displayed as the RPL ROM chip initializes the network adapter.

For instructions on using the rpldsabl utility, see "Deleting a Client" later in this chapter.


Adding a New Client

As described earlier in "Setting Up and Starting the Remoteboot Service," you created profiles for clients. You can add a new remoteboot client in two ways:

  • Create a new remoteboot database record for the client and manually fill in the necessary data, including the client's network adapter ID number and the profile you want this client to use. This is only recommended when you know the network adapter ID number and you are copying an existing workstation record.

When you copy an existing workstation record, you also copy the personal configuration information. For example, if the original workstation record uses a personal copy of a profile and has a customized installation of Windows 3.1, the profile and the Windows installation will be copied for the new client.

  • Boot the client remotely with no special preparation on the server. This creates an adapter record on the server, which you can then convert to a workstation record by adding the client's name and profile. This is easier because you don't need to know the client's network adapter ID number.

To create a new workstation record manually

1. Start Remoteboot Manager.

Remember to log on to a user account that belongs to the Administrators local group.

2. On the Remoteboot menu, click New Workstation.

Or, select an existing workstation record. On the Remoteboot menu, click Copy.

3. In Adapter ID, type the client's network adapter ID number.

This is a unique number supplied by the network adapter firmware. The adapter ID is 12 hexadecimal digits; the first six digits identify the adapter type. If you don't know the adapter ID, stop this procedure and go to the next procedure.

4. In Wksta Name, type a name for the client.

The name can have no more than 15 characters [with no spaces or backslashes (\)]. The Remoteboot service will create a Windows NT user account with this name, not for the user but for the client computer itself.

If the server's Rpl directory is on a FAT file system, use standard MS-DOS 8.3 format (eight characters, with an optional period and three more characters).

5. In Description, type a comment that describes the client.

6. In Password, type a password for the client computer's account (not for the user using the client computer).

7. Choose a configuration type:

  • Click Shared if this client can share its profile with other clients.
  • Click Personal if this client must use a personal copy of a profile so that you can customize the environment for the client.

8. In Wksta In Profile, enter a profile for this client.

If none of the profiles are suitable, see "Setting Up and Starting the Remoteboot Service," earlier in this chapter, for instructions on creating profiles.

If you see a profile in the list that appears to be appropriate, but it is marked as incompatible (or you see an error message about it being incompatible), then you may need to create a new configuration for this adapter type. See "Creating Remoteboot Configurations for New Adapters" later in this chapter.

9. In TCP/IP Settings, enter appropriate addresses only if the client will use TCP/IP and will not use DHCP for automatic address handling.

10. Click Add.

To create a new workstation record automatically

1. Start Remoteboot Manager on the server.

Remember to log on to a user account that belongs to the Administrators local group.

2. Start the remoteboot client.

The client does not actually boot, but it does send a boot request to the server.

3. In Remoteboot Manager on the server, click Refresh on the View menu.

4. In Remoteboot Manager, select the adapter record that has appeared with the network adapter ID number in place of the client name.

5. On the Remoteboot menu, click Convert Adapters.

Or, select more than one adapter record (hold down the CTRL key while clicking with the mouse). On the Remoteboot menu, click Convert Adapters. You will convert each of the selected records, one at a time.

Or, do not select any adapter records. On the Remoteboot menu, click Convert Adapters. You will convert all of the adapter records to workstation records, one at a time.

6. In Wksta Name, type a name for the client.

The name can have no more than 15 characters [with no spaces or backslashes (\)]. The Remoteboot service will create a Windows NT user account with this name, not for the user but for the client itself.

If the server's Rpl directory is on a FAT file system, use standard MS-DOS 8.3 format (eight characters, with an optional period and three more characters).

7. In Description, type a comment that describes the client.

The box already contains a comment provided by the network adapter itself.

8. Choose a configuration type:

  • Click Shared if this client can share its profile with other clients.
  • Click Personal if this client must use a personal copy of a profile so that you can customize the environment for the client.

9. In Wksta In Profile, click a profile for this client.

Profiles that are unsuitable for this type of adapter (determined by the first six digits of the network adapter ID number) are marked with a red X.

If none of the profiles are suitable, see "Setting Up and Starting the Remoteboot Service," earlier in this chapter, for instructions on creating profiles.

10. In TCP/IP Configuration, enter appropriate addresses only if the client will use TCP/IP and will not use DHCP for automatic address handling.

11. Click Add.

If you are converting more than one adapter ID record, the next record appears in the dialog box.

What You See on an MS-DOS or Windows 3.1 Client

When you boot the client, a remoteboot logon prompt appears:

Type Remoteboot username, or press enter if it is <workstation>:

This asks for the account name and password associated with the client itself, not for the user's own account name and password.

Once the boot is complete, the user should type a net logon command to log on with his or her own username and password.

When the client has completed a remote boot, the current directory is C:\, and the C drive is a virtual hard drive, parts of which are mapped to various places on the remoteboot server by the FIT file. For information about FIT files and translation pairs, see "Directory, File Index, and Configuration File Details" later in this chapter.

The C:\Wksta directory contains client-specific and profile-specific configuration files (such as Win.ini) and is different for each profile to which the client is joined. The C:\Data directory will always be the same, regardless of the profile used; the user can create files and directories there.

The C:\Dos and C:\Lanman.dos directories provide access to MS-DOS and network utilities. The C:\Binr directory provides access to shared real-mode utilities.

Local hard disks, if present, are assigned drive letters starting with D, unlike the local boot case, where the drive letters start with C.

Note

If the server uses NTFS, a client assigned to a profile (rather than to a personal copy of a profile) can add or modify files only in certain directories on its virtual C drive. It cannot affect directories on the C drive that are shared with other clients (unless you explicitly grant permission to do so on the server).

A remoteboot client always runs the NetBEUI protocol. To run other protocols as well, see "Supporting Multiple Network Adapters and Protocols" later in this chapter.

Changing a Workstation Record

You can change any of the properties of a workstation record except the network adapter ID number.

To change a workstation record for a client

1. Start Remoteboot Manager on the server.

Remember to log on to a user account that belongs to the Administrators local group.

2. Select the workstation record.

Or, select more than one record (hold down CTRL while clicking) to change properties for a group of clients at once.

3. On the Remoteboot menu, click Properties.

4. Update the information as needed.

5. Click OK.


Deleting a Client

When you no longer want to boot a workstation remotely, you can remove it from the list of workstations in the Remoteboot service.

To remove a client from the Remoteboot service

1. Start Remoteboot Manager on the server.

Remember to log on to a user account that belongs to the Administrators local group.

2. Select the workstation record for the client.

Or, select more than one record (hold down CTRL while clicking) to delete a group of workstation records at once.

3. On the Remoteboot menu, click Delete.

4. Verify that you want to delete this workstation record.

If Remoteboot Manager originally created an account while creating a workstation record, removing the workstation record also removes the account associated with that client. If the account existed before the workstation record, then the account will remain after removing the workstation record.

If the client was a Windows 95 client, you may want to delete the client's machine directory.

If the client has a bootable hard drive, you need to disable the remoteboot process and allow the client to use the hard drive again.

To disable the Remoteboot process

1. Start the client, booting MS-DOS remotely or from a floppy disk.

2. Put the disk with the Rpldsabl.exe program in the client's floppy disk drive and type:

a:rpldsabl

where a: is the client's floppy disk drive.

(If you don't have the disk anymore, see the section "Enabling Remoteboot on a Client's Hard Disk," earlier in this chapter, for instructions on making this disk.)

3. Remove the disk and press CTRL+ALT+DEL.


Installing Windows 95 for Windows 95 Clients

To support Windows 95 remoteboot clients, you must install Server-Based Setup (SBS) on a server, install the first Windows 95 client, and then install subsequent clients.

Installing SBS for Windows 95 Clients

For greater technical detail about SBS servers, see the Microsoft Windows 95 Resource Kit. When you set up an SBS server, you can use the server for remoteboot and for other purposes described in the Microsoft Windows 95 Resource Kit.

You will need a Windows 95 installation compact disc (not floppies) and a Windows 95 client computer.

To install an SBS server

1. On the server that will contain SBS files, create a shared directory with 90 MB of space available. The shared directory can have any name.

As you share the directory, assign read-only permission for regular users and full access for administrators. For example, use Server Manager to focus on the shared directory and set read-only permission for the Users group and full permission for the Administrators group. In File Manager, click Share As on the Disk menu, not Permissions on the Security menu.

2. Install one regular Windows 95 client on the network or use an existing one.

You will use this client to configure the SBS server.

3. Log on to the Windows 95 client using an account that has write access to the shared directory on the SBS server.

4. Put the Windows 95 compact disc in the client's CD-ROM drive. In Windows Explorer, switch to the Admin\Nettools\Netsetup directory.

5. Double-click Netsetup.exe.

Note that you must run Netsetup.exe at a Windows 95 client. It will encounter errors on a computer running Windows NT.

6. In the Server-Based Setup dialog box, click Set Path, and specify the path to the SBS server; then click OK.

You can type a drive letter for a mapped drive, a network name for a server (for example, \\server1\sharedir), or a network path to a specific directory (for example, \\server1\sharedir\rpl\win95).

The button name becomes Change Path if a server was defined previously.

7. Click Install.

Server-Based Setup presents a series of dialog boxes so that you can complete these actions:

  • Specify an "install policy" for how users can install Windows 95 from the server. If you support only remoteboot clients, click Server. If you support other SBS functions as well, click User's choice. Do not click Local hard drive.
  • Set the source path for Windows 95 files.

This is the path to the compact disc on the client.

  • If asked, specify that you do not want to create a default setup script.

Setup scripts for Windows NT remoteboot installation require special settings.

  • Provide a CD Key number for product identification.

Server-Based Setup copies Windows 95 files to the SBS shared directory.

8. At the remoteboot server, put the compact disc or floppy disk containing the Windows NT remoteboot for Windows 95 files into a drive. Change to the drive and then change to the Update\Win95 directory. Run win95srv.bat to update the Windows 95 files for remotebooting. For example:

d: cd \update\win95 win95srv.bat <dest>

where <dest> is the shared directory on the SBS server.

9. If you are updating from version 3.51 or earlier of the Remoteboot service, start the Remoteboot service at the remoteboot server if it is not already started. Then, run the rbootsrv.bat program to update the remoteboot files and database for Windows 95 remotebooting. At the server's command prompt, type:

d: cd \update\win95 rbootsrv.bat <SBS_path> <RPL_path> [\\servername]

where:

  • <SBS_path> is the path to the installed SBS server's Windows 95 files.
  • <RPL_path> is the path to the remoteboot directory.
  • \\servername is the name of the remoteboot server ; you can omit this if you are typing at the remoteboot server.

10. At the remoteboot server, start Remoteboot Manager.

11. On the Configure menu, click Check Configurations to activate the new configurations.

Installing the First Windows 95 Client

Installing the first Windows 95 client requires booting that client first to MS-DOS 6.2x, running Windows 95 Setup on the client, and then copying selected files from the client's machine directory to the remoteboot server. Once you have installed this first client, you can easily install subsequent clients by using SBS to make a modified copy of the original machine directory without having to run Windows 95 Setup again.

Each remoteboot client has a "machine directory," a directory on a server that contains client-specific configuration information and data. For example, the machine directory contains the following:

  • Appropriate initialization and configuration files (including Win.ini and System.ini)
  • System.dat and User.dat (the Registry)
  • Files that define the Desktop, Start menu directories, and other programs
  • The spool directory for printing
  • The swap file and Temp directory

Machine directories can reside on the remoteboot server, on the SBS server, or on any designated server on the network. You may want to spread the load of machine directories across servers. The only qualifications for a machine directory server are sufficient disk space and running the NetBEUI protocol. To create a location for machine directories, simply make a shared directory on a server and share it with a name that does not contain spaces. For example, on a computer running Windows NT Server that will contain machine directories, type:

mkdir c:\rplmachines net share machines=c:\rplmachines

Note

The machine directories may not be subdirectories of the SBS directory.

Assign permissions to a machine directory so that only the users or administrators who will use the client have read and write permissions in the directory. If the machine directory is on an NTFS partition, assign permissions directly to the machine directories. If the machine directory is on a FAT partition, assign permissions to the shared directory containing the machine directories.

To install the first Windows 95 client

1. Boot the new client to MS-DOS 6.2x, using procedures in "Adding a New Client" earlier in this chapter.

You will need to run Windows 95 Setup while the client is booted from the Remoteboot service rather than when the client is booted from a floppy disk or hard drive.

2. Use the net logon command to log on using an account that has read access to the SBS server and write access to the shared directory that will contain this client's machine directory.

A good example is the account of someone who will use this client because they will need this access anyway.

3. Synchronize the time and date settings of the client, the SBS server, and the remoteboot server. Differing settings can interfere with Windows 95 Setup.

4. Use the net use command to map drive letters to the SBS server and machine directory location, and then determine the highest drive letter in use on the computer.

C: is a virtual hard drive mapped to parts of the remoteboot server. Each local hard drive partition (if any) takes another drive letter after C: (for example, D: and E: for two partitions). One more drive letter is reserved for use as a RAM drive during the Windows 95 boot process. Drive letters after that are available for use.

For example, if you have a local hard drive with one partition, C: will be mapped to the remoteboot server, D: will be the local hard drive, E: is reserved for use as a RAM drive, and F: and higher are available for use. You would type:

net use f: \\sbs_server\win95_share net use g: \\mach_server\mach_share

5. Change to the drive letter mapped to the SBS directory.

6. Run the Windows 95 Setup program by typing:

setup /t:temppath

where /t: is required and temppath is a path to a directory in which to store temporary files during installation. For example, if G: is mapped to the shared directory containing the client's machine directory, you could type:

setup /t:g:\client1.tmp

to store temporary files on that server.

Do not delete the t:\temppath directory until you have completed Step 12. Also, if you are installing two Window 95 clients simultaneously (for example, to support clients with different network adapters), choose separate temporary directories for each client.

Make the following decisions during setup:

  • In the Server-based Setup dialog box, click Set up Windows to run from a network server if asked.
  • In the Startup Method dialog box, click Start Windows from the network (remote boot server).
  • In the Machine Directory dialog box, when asked where to install Windows 95, type the path of the machine directory (using the drive letter specified in Step 4, for example, g:\client1).
  • In the Setup Options dialog box, click Custom setup.
  • In the Analyzing Your Computer dialog box, click No, I want to modify the hardware list.

Exclude as many hardware types and items from autodetection as possible. If autodetection crashes, run Setup again and exclude more items from autodetection. One problem could be that your network adapter is on IRQ2 or IRQ3; this conflicts with serial port detection with some network adapters.

  • In the Select Components dialog box, click to clear the Communications check box (unless the client has a modem and you intend to use dial-up networking).
  • In the Network Configuration dialog box, check that your network adapter and desired protocols are present and configured correctly.

If there are no network adapters shown, you must add and configure your network adapter.

If you add your network adapter, you must confirm the resource settings for the adapter. Select the adapter name in the Network Configuration dialog box, click Properties, and then click the Resources tab. Check that the settings displayed are correct (for example, the interrupt level). Then, click OK to force the Setup program to accept the settings; do not click Cancel.

For details about protocols on Windows 95 remoteboot clients, see "Supporting Multiple Network Adapters and Protocols" later in this chapter.

  • In the Identification dialog box, make sure that the workgroup for this client is the same as the workgroup or domain of the SBS server and machine directory server.

When the Windows 95 Setup program is done, reboot the client. The client will not yet boot to Windows 95; however, you must complete more steps first.

7. At the remoteboot server (or a client running Remoteboot Manager focused on the remoteboot server), start Remoteboot Manager.

8. Create a profile for the Windows 95 client. In Configuration, click the Windows 95 configuration corresponding to the client's network adapter type.

If you are not sure which configuration to choose, check the profile that is currently associated with this client for booting MS-DOS and use the equivalent Windows 95 profile.

9. Edit the client's workstation record to assign the client to the Windows 95 profile.

10. At the remoteboot server (or a client with write access to the remoteboot server's Rpl directory), run the Rpl\Bin\Win95clt.bat program by typing:

cd <systemroot>\rpl\bin win95clt mach_directory \\rpl_server profile_name

where:

  • mach_directory is the path to the client's machine directory.
  • \\rpl_server is the name of the remoteboot server.
  • profile_name is the name of the Windows 95 profile associated with the client.

For example, you could type:

cd \winnt\rpl\bin win95clt \\mach_server\mach_share\client1 \\rpl_server win95elnk2

The Win95clt program copies client-specific Windows 95 real-mode (also identified as MS-DOS 7.0) boot files from the client's machine directory to the Rpl\Rplfiles\Profiles\<profile_name> directory on the remoteboot server.

11. At the SBS server (or a client with write access to the SBS directory), edit the Machines.ini file in the SBS directory and add the following lines for the new client:

[adapter id] SYSDATPATH=g:\machine_dir g=\\mach_server\mach_share

where:

  • adapter id is the network adapter ID, specified in the remoteboot workstation record for this client.
  • g:\machine_dir is the location of the client's machine directory on a server; g is the drive letter assigned on the next line to the shared directory where the client's machine directory is located.
  • g=\\mach_server\mach_share identifies the drive letter assigned to the shared directory where the machine directory resides. You must use the same drive letter and share name established in Step 4.

For example, you might add the following lines to Machines.ini:

[02608C8EAA2D] SYSDATPATH=g:\client1 g=\\mach_server\mach_share

Reboot the Windows 95 client.

The client will now boot to Windows 95 and complete the Windows 95 Setup program.

Installing Subsequent Windows 95 Clients

Once you have installed a single client, subsequent clients of the same type will be much easier to install. These subsequent clients do not have to be exactly the same as the first, but they must use the same type of network adapter and the same adapter settings (IRQ, I/O address, etc.).

If you need to install a Windows 95 client that does have different configuration settings, you must treat the installation as a fresh installation; see "Installing the First Windows 95 Client" earlier in this section.

To install subsequent Windows 95 clients

1. Boot the new client to MS-DOS 6.2x, using procedures in "Adding a New Client" earlier in this chapter.

2. Log on to a regular Windows 95 client (for example, the one you used to run netsetup when you established the SBS server).

Use an account that has write access to the shared directory on the SBS server and to the shared directory containing machine directories.

3. Put the Windows 95 compact disc in the client's CD-ROM drive. In Windows Explorer, switch to the Admin\Nettools\Netsetup directory.

4. Double-click Netsetup.exe.

5. In the Server-Based Setup dialog box, click Set Path, and specify the path to the SBS server; then click OK.

You can type a drive letter for a mapped drive, a network name for a server (for example, \\server1\sharedir), or a network path to a specific directory (for example, \\server1\sharedir\rpl\win95).

The button name becomes Change Path if a server was defined previously.

6. Click Add.

7. In the Set Up Machine dialog box, click Set Up One Machine and then type the following information:

  • Computer name: type a computer name of the client (you must create a unique name).
  • Path to machine directory: type a network pathname for the machine directory you want to create for the client.
  • Existing machine directory: type the network pathname for an existing machine directory of a client similar to this one.

For example, you might type the following values:

  • Computer name: client2
  • Path to machine directory: \\mach_server\mach_share\client2
  • Existing machine directory: \\mach_server\mach_share\client1

8. Click OK.

You may see an error message about creating the machine directory. Check that the directory was created and that it contains several files; if so, then disregard the error message.

9. At the remoteboot server (or a client running Remoteboot Manager focused on the remoteboot server), start Remoteboot Manager.

10. Edit the client's workstation record to assign the client to the same Windows 95 profile as the first client.

11. Edit the Machines.ini file in the SBS directory. Add the following lines for the new client:

[adapter id] SYSDATPATH=g:\machine_dir g=\\mach_server\mach_share

where:

  • adapter id is the network adapter ID, specified in the remoteboot workstation record for this client.
  • g:\machine_dir is the location of the client's machine directory on a server; g is the drive letter assigned on the next line to the shared directory where the machine directory is located.
  • g=\\mach_server\mach_share assigns a drive letter to the shared directory where the machine directory resides. Use the same drive letter used by the original Windows 95 remoteboot client.

For example, you might add the following lines to Machines.ini:

[02608C8EAA2E] SYSDATPATH=g:\client2 g=\\mach_server\mach_share

12. Reboot the Windows 95 client.

The client will now boot to Windows 95 and complete the Windows 95 Setup program.

What You See on a Windows 95 Client

When you boot the client, a remoteboot logon prompt appears:

Type Remoteboot username, or press enter if it is <workstation>:

This asks for the account name and password associated with the client computer itself, not for your own user account name and password.

Windows 95 then prompts you twice for your username and password: once from a command prompt and again in a dialog box. At both of these prompts, enter your user account name and password.

Once Windows 95 has started, the C: drive is unassigned; it was assigned during the remoteboot process and is no longer needed. Each local hard drive partition takes another drive letter after C: (for example, D: and E: for two partitions). One more drive letter was used as a RAM drive during the Windows 95 boot process; you can now use it as a RAM drive for your own purposes. Two more drive letters, usually the next two drive letters in sequence, are mapped to the SBS server and to the shared directory containing the client's machine directory. When setting up the client, you choose exactly which two drive letters to map and they will always be the same for this client. Do not unmap or remap these drives elsewhere.

For example, if you have a local hard drive with one partition, C: is unmapped, D: is the local hard drive, E: is a RAM drive, F: is mapped to the SBS server, and G: is mapped to the shared directory containing the client's machine directory.


Installing Windows 3.1 for MS-DOS Clients

You can install Windows 3.1 in similar client environments simply by creating a profile for Windows 3.1 users and installing the Windows 3.1 environment in the profile. In this way, you can add as many new clients as you need without having to install the Windows 3.1 environment with each new addition. Keep in mind, however, that all the clients sharing the profile must be similar enough to share the same startup information.

If the clients are not similar, you create personal copies of profiles. If Windows 3.1 is already installed for a profile, and you create a new personal copy of that profile, the Windows 3.1 installation is part of the new copy, and you do not have to reinstall it. If you have established a personal copy of a profile and later want to add Windows 3.1, you must add it separately for that personal copy of the profile, or delete the personal copy of the profile and create a new one from a profile that does have Windows 3.1 installed.

To support Windows 3.1 for remoteboot clients:

  • Install Windows 3.1 files on the remoteboot server. This makes the files easily available for client installations.
  • Create a profile for Windows 3.1 users. Install Windows 3.1 once for all clients using the profile.
  • Install Windows 3.1 separately for clients using a personal copy of a profile (if the profile did not support Windows 3.1 at the time you made the personal copy). Or, delete the client account and recreate it, making a personal copy of a profile that does support Windows 3.1.

Installing Windows 3.1 Files on the Server

Installing Windows 3.1 files on the server makes the files easily available for client installations.

To install Windows 3.1 files on the server

1. Create an MS-DOS profile, if one does not exist. (For details, see "Setting Up and Starting the Remoteboot Service" earlier in this chapter.)

2. Boot a remoteboot client that will use Windows 3.1, and join it to the MS-DOS profile using Remoteboot Manager. (For details, see "Adding a New Client" earlier in this chapter.)

Note

If you will use the shared Windows 3.1 profile method for similar clients, assign the client to use a profile, not a personal copy of a profile. If you will use the personal profile user method for different clients, assign the client to use a personal copy of a profile.

3. Reboot the client.

At the remoteboot logon prompt (the prompt that first appears when you start the client), supply the name and password of an account that is a member of the Administrators group on the Windows NT Server computer.

4. If the client does not have a floppy disk drive, use the floppy disk drive of a server on the network:

  • First, at the server (it doesn't have to be the remoteboot server), use File Manager or the net share command to share the server's floppy disk drive.
  • Then, at the client, use File Manager or the net use command to connect to the shared floppy disk drive.

5. Put the Windows 3.1 Disk 1 in the floppy disk drive.

6. Run setup /a on the Windows 3.1 Disk 1 and install to C:\Win.

Windows 3.1 files are expanded and put into the <systemroot>\Rpl\Rplfiles\Binfiles\Win directory on the remoteboot server.

Continue the installation. Depending on how you want to set up profiles, proceed to "Installing Windows 3.1 for a Profile" or to "Installing Windows 3.1 for a Personal Copy of a Profile."

Installing Windows 3.1 for a Profile

When you install Windows 3.1 for a profile, all clients that share that profile use Windows 3.1. Also, if you later assign a personal copy of the profile to a client, that client uses Windows 3.1.

To install Windows 3.1 for a profile

1. Create a profile for Windows 3.1 users on the remoteboot server.

Give the profile a specific name that suggests the Windows version and the operating system associated with it. For example, D62WIN31 tells you that this profile is for MS-DOS 6.2x with Windows version 3.1.

2. In Remoteboot Manager, assign a remoteboot client to the new profile (not using a personal copy of the profile).

3. Reboot the client.

At the remoteboot logon prompt (the prompt that first appears when you start the client), supply the name and password of an account that is a member of the Administrators group on the Windows NT Server computer.

4. On the client, change to the Windows 3.1 directory by typing:

cd \win

5. On the client, run setup /n to install Windows 3.1 in C:\Windows (do not choose to upgrade any existing Windows installations). Choose the express installation.

If the client has memory trouble while running Setup, see "Configuring Memory for MS-DOS and Windows 3.1" later in this chapter.

6. Follow the instructions in the Setup program to modify the Autoexec.bat and Config.sys files.

Note

If Setup displays an error message saying that it cannot update your system files on drive C, choose Cancel. This creates Autoexec.win and Config.win files in the C:\Windows directory. Copy these files to C:\Autoexec.bat and C:\Config.sys, respectively.

7. Add the following lines to the end of the [386enh] section in the C:\Windows\System.ini file:

TimerCriticalSection=5000 UniqueDosPSP=True PSPIncrement=2

8. Return to the MS-DOS prompt and copy all the files and directories in C:\Windows to C:\Wksta.pro\Win by typing:

xcopy /e c:\windows c:\wksta.pro\win

This makes the Windows 3.1 files available to all remoteboot clients that are joined to the profile.

If the xcopy command does not work on the client, you can copy the files from a command prompt on the server by typing the following command, all on one line:

xcopy /e c:\systemroot\rpl\rplfiles\machines\client\profile\wksta\win
c:\systemroot\rpl\rplfiles\profiles\profile\wksta\win

where client is the name of the client and profile is the name of the profile.

9. Reboot the remoteboot client and log on.

Installing Windows 3.1 for a Personal Copy of a Profile

If you assign a personal copy of a profile (without Windows 3.1) to a client, and then later decide that you want to install Windows 3.1 for that client, you can install Windows 3.1 separately for this client. Or, delete the client account and recreate it, making a personal copy of a profile that does support Windows 3.1.

You may want to install a separate copy of Windows 3.1 for a client if the client requires customized Windows 3.1 configuration files.

To install Windows 3.1 for a personal copy of a profile

1. On the remoteboot server, assign the remoteboot client to an MS-DOS profile. Specify a personal copy of the profile.

2. Reboot the client.

At the remoteboot logon prompt (the prompt that first appears when you start the client), supply the name and password of an account that is a member of the Administrators group on the Windows NT Server computer.

3. On the client, change to the Windows 3.1 directory by typing the following:

cd \win

4. Run setup /n to install Windows 3.1 in C:\Windows (do not choose to upgrade any existing Windows installations). Choose the express installation.

If the client has memory trouble while running Setup, see "Configuring Memory for MS-DOS and Windows 3.1" later in this chapter.

5. Follow the instructions in the Setup program to modify the Autoexec.bat and Config.sys files.

Note

If Setup displays an error message saying that it cannot update your system files on drive C, choose Cancel. This creates Autoexec.win and Config.win files in the C:\Windows directory. Copy these files to C:\Autoexec.bat and C:\Config.sys, respectively.

6. Add the following lines to the end of the [386enh] section in the C:\Windows\System.ini file:

TimerCriticalSection=5000 UniqueDosPSP=True PSPIncrement=2

7. When the Setup program is finished, reboot the client and log on.


Optimizing the Remoteboot Service

Once the Remoteboot service has been configured and customized for your network needs, Windows NT Server offers some additional ways to optimize the service. Most of the topics in this section deal with increasing performance. Other topics tell you how to further customize your configuration.

This section contains information on how to:

  • Use the rplcmd utility to change the remoteboot database.
  • Create remoteboot configurations for new adapters.
  • Configure memory for MS-DOS and Windows 3.1.
  • Configure memory for Windows 95.
  • Set local swapping.
  • Use a RAM drive on the client.
  • Set hardware buffers.


Using the Remoteboot Command Utility (RPLCMD.EXE)

The rplcmd utility can be used to view and update records in the remoteboot database, including those that are inaccessible through Remoteboot Manager. This utility is for advanced administrators, not for casual use.

Before you use rplcmd, make sure that you have a backup copy of the remoteboot database. For details, see "Backing Up the Remoteboot Database" later in this chapter.

This is the syntax of rplcmd:

rplcmd [\\computername]

where \\computername specifies a remote computer where the Remoteboot service is running. If this parameter is omitted, rplcmd manages the Remoteboot service on the local computer.

The main rplcmd command prompt appears as:

Adapter Boot Config Profile Service Vendor Wksta [Quit]

Each command has the following effect:

  • Adapter modifies adapter records (records of remoteboot clients that have been started but do not yet have a workstation record assigned).
  • Boot modifies boot block records.
  • Config modifies configuration records.
  • Profile modifies profiles.
  • Service controls the Remoteboot service.
  • Vendor associates a vendor "name," or six-digit hexadecimal prefix, with a text comment describing the vendor.
  • Wksta modifies workstation records.

To select a command, type the first letter in the command name and press ENTER. To return to the main menu, press CTRL+Z at any prompt and press ENTER.

Each of the main commands has further command prompts, including these common commands:

  • Add — to add a new record.
  • Del — to delete a record (or all records).
  • Enum — to enumerate, or show information for, a record (or all records). You can enumerate information at different levels; level 0 gives you the least information per record.


Creating Remoteboot Configurations for New Adapters

The following section is for advanced administrators.

Note

Before you use rplcmd, make sure that you have a backup copy of the remoteboot database. For details, see "Backing Up the Remoteboot Database" later in this chapter.

When the Remoteboot service receives a boot request, it looks up the workstation record associated with the client's network adapter ID (if there isn't one, then it creates an adapter record and does not attempt to boot the client). It then determines the profile associated with the workstation record and the configuration record that was used to create the profile. The configuration record contains a boot block record name, and more than one boot block record may have the same name. The Remoteboot service looks for a boot block record with this boot block record name and the vendor ID contained in the client's network adapter ID. The configuration record and the boot block record provide the information needed to boot the client.

Windows NT Server provides boot block and configuration records for the most popular network adapters.

Use the following procedure if Remoteboot Manager cannot assign a workstation record to the correct profile because the network adapter type is incompatible. This can happen when there is no existing boot block record mapping the network adapter vendor ID to the correct network adapter type. You must create a new boot block record specifying the vendor ID and the network adapter type. If any client with this network adapter type will boot to Windows 95, you must create an MS-DOS boot block record and a Windows 95 boot block record.

To create a new boot block record for a supported network adapter type

· Use the rplcmd utility to add boot block records for the adapter and vendor ID. For details about the rplcmd utility, see the preceding section, "Using the Remoteboot Command Utility (RPLCMD.EXE)."

For BootName, use the name of an existing boot block record that boots clients with network adapters of this type (but with a different vendor ID).

For example, the following sequence of commands creates sample boot block records for MS-DOS and Windows 95:

C:\winnt\rpl> rplcmd Adapter Boot Config Profile Service Vendor Wksta [Quit]: b Add Del Enum: a BootName=DOSX VendorName=012345 BbcFile=BBLOCK\NETBEUI\dirname\DOSBB.CNF All other parameters are optional BootComment=Name of this adapter WindowSize=0 Adapter Boot Config Profile Service Vendor Wksta [Quit]: b Add Del Enum: a BootName=W95X VendorName=012345 BbcFile=BBLOCK\NETBEUI\dirname\W95BB.CNF All other parameters are optional BootComment=Name of this adapter WindowSize=0 Adapter Boot Config Profile Service Vendor Wksta [Quit]: v Add Del Enum: a VendorName=012345 BootComment=Name of this adapter

Note In this example, and in those that follow, the value 012345 represents the "vendor name" or network adapter prefix. Replace this with the first six digits of the network adapter type's adapter identification number.

If the adapter prefix for the new adapter type matches that of an existing adapter type, modify the BootName field of the boot block and workstation record field to be unique among all boot block or workstation records corresponding to that adapter prefix. For example, use DOS for IBM Token Ring and DOSI for IBM Ethernet.

If you want to use a new remoteboot-compatible network adapter that is not already supported by Windows NT Server, you must manually create a new boot block, boot block record(s), and a configuration record corresponding to the new adapter. This allows the Remoteboot service and Remoteboot Manager to recognize the new adapter type.

Microsoft does not guarantee support for adapters that are not on the list of supported adapters (see "Supported Network Adapters" earlier in this chapter). Note especially that the Remoteboot service does not support PCI, Token-Ring, or PNP adapters for Windows 95 remoteboot clients.

To support Windows 95 clients with a particular network adapter type, you must create both an MS-DOS 6.2x configuration and a Windows 95 configuration.

To create an MS-DOS configuration for a new adapter

1. Copy the MS-DOS device driver for the network adapter to the <systemroot>\Rpl\Bblock\Ndis directory.

2. Create the directory <systemroot>\Rpl\Bblock\Netbeui\adapter, where adapter is the name of the adapter. Within this directory, create these files:

  • Dosbb.cnf
  • Protocol.ini

Pattern these files after existing files in a corresponding directory, but substitute the new driver names in the Dosbb.cnf file, and the correct driver information in the Protocol.ini file.

3. Use the rplcmd utility to add a boot block record for the new adapter. For details about the rplcmd utility, see the preceding section, "Using the Remoteboot Command Utility (RPLCMD.EXE)."

For example, the following sequence of commands creates a sample boot block record:

C:\winnt\rpl> rplcmd Adapter Boot Config Profile Service Vendor Wksta [Quit]: b Add Del Enum: a BootName=DOSX VendorName=012345 BbcFile=BBLOCK\NETBEUI\dirname\DOSBB.CNF All other parameters are optional BootComment=Name of this adapter WindowSize=0

4. Use the rplcmd utility to add the new configuration.

For example, the following sequence of commands creates a sample configuration:

C:\winnt\rpl> rplcmd Adapter Boot Config Profile Service Vendor Wksta [Quit]: c Add Del Enum: a ConfigName=DOS622X BootName=DOSX DirName=DOS DirName2=DOS622 FitShared=fits\dos622.FIT FitPersonal=fits\dos622p.FIT All other parameters are optional ConfigComment=DOS 6.22 <adapter name> DirName3= DirName4=

For BootName, enter the name of the boot block record you created in step 3.

To create a Windows 95 configuration for a new adapter

1. Boot the client to MS-DOS 6.2x to confirm that the MS-DOS configuration is correct. For details, see "Adding a New Client" earlier in this chapter.

2. In the <systemroot>\Rpl\Bblock\Netbeui\adapter directory, where adapter is the name of the adapter, copy the Dosbb.cnf file to W95bb.cnf.

3. Edit the new W95bb.cnf file to change the following line:

EXE BBLOCK\I13.COM ~ ~ ~

to read:

EXE BBLOCK\W95I13.COM ~ ~ ~

4. Use the rplcmd utility to add a boot block record for the new adapter. For details about the rplcmd utility, see the preceding section, "Using the Remoteboot Command Utility (RPLCMD.EXE)."

For example, the following sequence of commands creates a sample boot block record:

C:\winnt\rpl> rplcmd Adapter Boot Config Profile Service Vendor Wksta [Quit]: b Add Del Enum: a BootName=W95X VendorName=012345 BbcFile=BBLOCK\NETBEUI\dirname\W95BB.CNF All other parameters are optional BootComment=Name of this adapter WindowSize=0

5. If there is not already a Windows 95 configuration for this BootName, then use the rplcmd utility to add the new configuration.

For example, the following sequence of commands creates a sample configuration:

C:\winnt\rpl> rplcmd Adapter Boot Config Profile Service Vendor Wksta [Quit]: c Add Del Enum: a ConfigName=W95X BootName=W95X DirName=DOS DirName2=W95X FitShared=fits\win95.FIT FitPersonal=fits\win95p.FIT All other parameters are optional ConfigComment=Windows 95 <adapter name> DirName3= DirName4=

For BootName, enter the name of the boot block record you created in step 4.


Configuring Memory for MS-DOS and Windows 3.1

Here are two tips for configuring the remoteboot client to use memory most efficiently while running MS-DOS version 5.0 or later, Windows 3.1 Setup, or Windows 3.1 itself.

Configuring EMM386.EXE

The Config.sys file contains a device line for Emm386.exe. This line is disabled (the line starts with REM) because you must calculate the parameters. This procedure is for a 386-based (or higher) client running MS-DOS 5.00 or later.

To configure Emm386 for more upper memory

1. Find out how much conventional memory the client has (in decimal terms) by typing mem at the MS-DOS prompt.

2. Convert this number to hexadecimal format and drop the rightmost digit. To convert, you can use the dectohex command in the <systemroot>\Rpl\Rplfiles\Binfiles\Binr directory.

3. Edit the device=Emm386.exe line in the Config.sys file.

  • Remove the REM designation at the beginning of the line. Check that the path specified for the file is the root (C:\) directory, not the C:\Dos directory.
  • Use the remaining four digits of the hexadecimal value for the first x= value. (The second x= value is 9FFF and should not be changed.)

For example, if conventional memory is 598016, the hexadecimal value is 92000. In this case, use x=9200-9FFF.

Disabling SMARTDRV.SYS

Windows 3.1 installs a device command in the Config.sys file to use Smartdrv.sys. If your Windows 3.1 client seems to be operating slowly, experiment with disabling this line. Disabling Smartdrv.sys may speed the process up by giving Windows 3.1 memory on the client rather than on a disk cache.

To disable SMARTDRV.SYS

· Disable the device=SMARTDRV.SYS line (precede it with REM) in the client's Config.sys file.


Configuring Memory for Windows 95

With Windows 95, you generally do not need to load Emm386 in the Config.sys file. When you need to exclude ranges of memory used by a network adapter card or other peripheral device, edit the System.ini file in the client's home directory. In the [386Enh] section, add a line like the following:

[386Enh]
EMMExclude=CC00-CFFF


Setting Up Local Swapping

You can increase performance on your Windows 95 and Windows 3.1 remoteboot clients by using the client's hard drive for swapping.

To set up local swapping on Windows 95 clients

· Add a pagingfile=path entry in the [386Enh] section of the System.ini file in the client's machine directory.

To set up local swapping on Windows 3.1 clients

· Edit the swapfile line in the client's System.ini file to point to drive D.


Using a RAM Drive on the Client

You can optimize post-boot performance on your remoteboot clients by using a RAM drive. Use of a virtual disk, such as the Ramdrive.sys provided with most MS-DOS versions, can reduce network traffic by storing commonly used files and utilities locally. (If, however, the client does not have RAM to spare, using a virtual disk could increase swapping.)

The RAM drive should be placed first in the PATH environmental variable. Giving memory to file caches may also help performance, especially on the remoteboot server. For more information about memory management, see the documentation for the MS-DOS operating system and for the network client software.


Setting Hardware Buffers

To achieve maximum possible usage of upper memory blocks (UMBs) for MS-DOS 5.0 or later, set hardware buffers to be contiguous and as low as possible within the C000-F000 range.

By making sure that the address ranges (ROM and RAM) are as contiguous as possible, you will be able to create the largest single, free address range. This will provide more UMBs for MS-DOS than fragmenting the address ranges.

On PC/AT computers, refer to the hardware and software manuals that came with your adapters to determine the address ranges that can be set. Usually, this is done with jumpers on the adapter, but occasionally it must be changed with a setup program. Once you have determined the address ranges, arrange them to be as close together as possible without overlapping.

On PS/2 computers, you will need to run the reference disk and supply the ADF files (if they are not already on the disk) for all the adapters. Using the reference disk program, you can determine address ranges for each adapter, and then set them.


Directory, File Index, and Configuration File Details

The following sections describe the structure of the RPL directory and the formats of remoteboot configuration files.


The RPL Directory

The following illustration shows the subdirectories created in the <systemroot>\Rpl directory when you install the Remoteboot service.

Directories that are automatically installed should not be deleted (for example, do not delete C:\Tmp from a remoteboot client). If a directory is deleted, you must recreate it and set the permissions with the Remoteboot Manager Fix Security command, or you can use Remoteboot Manager to delete the affected workstation record and recreate it (after first saving any client-specific files).

In the <systemroot>\Rpl directory, the System.mdb and Rplsvc.mdb files contain the remoteboot database. The Jet.log file contains information used in recovery from power failures or other catastrophic interruptions.


File Index Tables

File index tables (or FIT files) are ASCII files containing filename lookup tables that enable file translation. Remoteboot client software translates a directory name or filename typed by the client user into the true directory name or filename on the server. In general, the client translates references of the form C:\... to \\servername\Rplfiles\... (that is, to locations in the <systemroot>\Rpl\Rplfiles directory on the server).

Windows 95 clients use a .fit file only in the early stages of their boot process. Once the client is running Windows 95, it uses storage defined by the SBS server and machine directory server.

File translation pairs consist of a prototype filename or prefix, followed by a space, and an actual filename or prefix, relative to the directory named on the first line [usually (Rplfiles)]. If the prototype matches a proper prefix of the name to be matched, the matched portion is replaced by the actual prefix. If there is an exact match (not just a prefix), the actual filename is substituted. If several prefixes match, the longest one is selected for substitution. A network path of the form \\any_servername\sharename may be included in the actual filename or prefix, in which case it overrides the directory listed on line one.

Examples:

  • If the client requests access to C:\Win386.swp (for example, to open it for writing), the client software will use the .fit file to translate it into:

    \\servername\RPLFILES\TMPFILES\(CNAME)\SWAPFILE.DAT

where (CNAME) is the client name.

  • If C:\Config.sys is requested, the following will be used because it has the longest matching prefix (C:\):

    \\servername\RPLFILES\PROFILES\(PROFILE)\CONFIG.SYS

where (PROFILE) is the profile name. The line near the top of each .fit file that starts with C:\ sends all C:\ references that aren't at least partially matched by other lines to the directory \\servername\Rplfiles\Profiles\(Profile).

Note that the "machine writeable files" section of each .fit file lists the files and directories to which the user has write access.

By convention there are usually two .fit files for each profile: one to be used when sharing the profile and one to be used with personal copies of the profile. For example, Dos622.fit is for clients that share the Dos622 profile, and Dos622p.fit is for personal copies of the Dos622 profile. The file format is the same, but the personal profile .fit translates most references to directories specific to the client rather than to directories shared with other clients. The .fit file used for Windows 95 clients has no differences between the shared and personal versions.

Fields in .fit files are separated with white space. The maximum line length is 512 characters. A comment line has a semicolon (;) as the first non-space character.

The following keywords have special meaning in a .fit file:

  • (PROFILE) is the name of the profile assigned to this client.
  • (CNAME) is the name of the client.
  • (RPLFILES) is the <systemroot>\Rpl\Rplfiles directory, shared by the server with the sharename Rplfiiles.
  • (BINFILES) is a directory for executable files. It is assumed to be relative to Rplfiles (\systemroot\Rpl\Rplfiles\Binfiles).
  • (TMPFILES) is a directory for temporary and swap files. It is assumed to be relative to Rplfiles (<systemroot>\Rpl\Rplfiles\Tmpfiles).


Boot Block Configuration Files

The boot block configuration file specifies the contents of the boot block sent to the client by the Remoteboot service and is designated by the .cnf extension. The boot block normally includes the Rplboot.sys, Rplstart.com, and Rpldisk.sys files and the real-mode network drivers. The boot block also contains some client-specific data (a copy of the workstation record from the remoteboot database) and some profile-specific data (the .fit file associated with the profile used).

A line in a .cnf file typically has three fields:

  • Type
  • Filename (path is relative to the <systemroot>\Rpl directory)
  • Parameter(s)

All valid types are listed next, along with their expected filenames and parameters.

Fields in .cnf files are separated with white space. Spaces within a field are represented with a tilde (~). The maximum line length is 512 characters. A comment line has a semicolon (;) as the first non-space character.

Note

The DRV and EXE types of boot block configuration files must be specified in the reverse order in which they would normally occur in a Config.sys file. For example, if ABC.DRV must appear before DEF.EXE in Config.sys, DEF.EXE must appear before ABC.DRV in the .cnf file.

RPL Type

The filename specified with the RPL type is the initialization program that runs on a client. There must be exactly one RPL type in a .cnf file. The initialization program is normally Rplboot.sys.

BASE Type

The value specified with the BASE type is a hexadecimal segment number that identifies the base address of the boot block. There can be only one BASE type in a .cnf file. If none is specified, 00C0h is used as the default base address.

DAT Type

Files listed with the DAT type specify data files that should be stored on the boot block. The filename is relative to <systemroot>\Rpl.

LDR Type

The filename and parameters listed with the LDR type specify which loader to use on the client. The loader is the program that Rplboot.sys will pass control to; there can be only one LDR keyword. The loader is normally Rplstart.com.

DRV Type

The filename and parameters listed with the DRV type specify the device drivers used to form the boot block. The filename field specifies the name of the device driver. The DRV type has three parameter fields:

  • The first field specifies parameters used by the device driver.
  • The second field specifies any additional memory used by the device driver (in decimal kilobytes).
  • The third field is M if the device driver can be moved in memory to reuse space that it doesn't need; it is ~ if the device driver cannot be moved.

If the driver can be moved after initialization and its memory requirements are less than for the original driver image, Rplboot.sys moves the driver to reclaim some of the unused memory and adjusts all interrupt vectors that point into the driver's memory area. Some drivers cannot be moved because they record segment addresses that are correct during initialization but not after the driver has been moved.

EXE Type

Files listed with the EXE type specify executables (.exe and .com files) that are run during the boot process. The filename is the name of the executable, and the parameters field specifies arguments passed to the executable. EXE lines must be specified in reverse order—that is, the last one listed in the boot block configuration file will be the first one executed.


Supporting Multiple Network Adapters and Protocols

The method of supporting multiple network adapters or multiple protocols depends on whether the client runs Windows 95 or MS-DOS/Windows 3.1.


Using Multiple Network Adapters and Protocols with Windows 95

If the client has multiple network adapters, only one should have a RPL ROM. When you configure the client's workstation record in Remoteboot Manager, specify a profile corresponding to the network adapter with the RPL ROM.

You need NetBEUI and DLC connectivity to the remoteboot server in order to set up and boot a Windows 95 client. The network adapters and protocols defined in Windows 95 Setup become active once the Windows 95 real-mode client is booted. You no longer need NetBEUI or DLC at this phase, as long as you can access the SBS server and the shared directory containing your machine directory.


Using Multiple Network Adapters with MS-DOS and Windows 3.1

If a remoteboot MS-DOS or Windows 3.1 client computer has multiple network adapters, you will need to modify the boot block information for the adapter that has the RPL ROM chip.

To modify the boot block information

1. Using Remoteboot Manager, create a new profile.

2. Add the network adapter driver to the <systemroot>\Rpl\Bblock\Netbeui\adapter\Dosbb.cnf boot block configuration files, where adapter is the name of the adapter that has the RPL ROM chip on the client computer.

3. Update the <systemroot>\Rpl\Bblock\Netbeui\adapter\Protocol.ini file with sections for the new network adapter driver.


Using Multiple Protocols with MS-DOS and Windows 3.1

A remoteboot MS-DOS or Windows 3.1 client always runs the NetBEUI protocol. This section describes how to install support for TCP/IP, DLC, and IPX protocols for use by remoteboot clients.

Installing TCP/IP Support

Before you set up clients to use TCP/IP, you must either enable DHCP to assign addresses automatically, or you must assign IP addresses and subnet masks for each client that will use TCP/IP. (See the Windows NT Server TCP/IP manual for more information about TCP/IP addresses.)

When you have arranged for addresses, you can then enable TCP/IP support.

To enable TCP/IP support

1. Edit the <systemroot>\Rpl\Bblock\Netbeui\adapter\Dosbb.cnf file, where adapter is the name of the network adapter. Remove the semicolon (;) in column one of this line:

;DRV BBLOCK\TCPDRV.DOS /I:C:\LANMAN.DOS ~ ~

2. For each profile (or personal copy of a profile) that will support TCP/IP, edit the following files as described:

  • In <systemroot>\Rpl\Rplfiles\Profiles\profile\Autoexec.bat, where profile is the name of the profile, enable umb.com, nmstr, and load tcpip by removing the REM designations at the beginnings of those lines.
  • In <systemroot>\Rpl\Rplfiles\Profiles\profile\Config.sys, where profile is the name of the profile, enable nemm.dos by removing the REM designation at the beginning of that line.

3. Boot a client using one of the profiles altered in the last step.

Installing MS-DLC Support

To install MS-DLC support

· At the client, type load msdlc.

Or, add this command to the end of the client's Autoexec.bat file.

Installing IPX Support

When you install IPX support, you will need the Microsoft Network Client version 2.2 NetWare Connectivity disk and the Novell NetWare SHGEN-1 and SHGEN-2 disks (or the WSGEN disk).

Note

IPX support is installed per adapter and is MS-DOS version specific. Follow the installation procedure for each adapter that will support IPX; define profiles for each version of MS-DOS that will support IPX.

To install IPX support

1. On the server, edit the <systemroot>\Rpl\Bblock\Netbeui\adapter\Dosbb.cnf file, where adapter is the name of the network adapter. Remove the semicolon (;) in column one of this line:

;DRV BBLOCK\IPXNDIS.DOS ~ ~ ~

2. Create a new profile with a name that describes IPX support (for example, DOS62IPX).

Note

IPX is MS-DOS version specific. You must create a separate profile for each version of MS-DOS that will support IPX.

3. Assign a client to the new profile.

4. Boot the client.

At the remoteboot logon prompt (the prompt that first appears when you start the client), supply the name and password of an account that is a member of the Administrators group on the Windows NT Server computer.

5. If the client does not have a floppy disk drive, use the floppy disk drive of a server on the network:

  • First, at the server (it doesn't have to be the remoteboot server), use File Manager or the net share command to share the server's floppy disk drive.
  • Then, at the client, use File Manager or the net use command to connect to the shared floppy disk drive.

6. Put the Microsoft Network Client NetWare Connectivity disk in the floppy disk drive.

7. On the client, run the NetWare Connectivity Setup program by typing a:nwsetup (use a different drive letter if needed).

When prompted, insert the Novell NetWare SHGEN-1 and SHGEN-2 disks (or the WSGEN disk).

8. Reboot the client.

Supply the client password (if any).

9. Log on to the client with a normal user account.

10. To start using the IPX protocol, type nwload. Or, add this command to the end of the client's Autoexec/bat file.

IPX is now installed on the client's profile and is available for use by other clients using this profile.


Backing Up the Remoteboot Database

The remoteboot database holds the configuration, workstation, and profile records and other data for the Remoteboot service. You should back up the database before and after you make significant changes and save the copies. The Remoteboot service automatically backs up the database every 24 hours (counting from when you start the service).

Because the Remoteboot service makes automatic backups (overwriting the current backup copies), and for good administrative procedure, you should occasionally archive copies of the backup files.

To back up the remoteboot database

· On the Configure menu of Remoteboot Manager, click Backup Database.

The Jet.log, Rplsvc.mdb, and System.mdb files are backed up to the <systemroot>\Rpl\Backup directory.

To restore a backup copy of the remoteboot database

· Copy the files from <systemroot>\Rpl\Backup (or other saved versions of the files) to the Rpl directory.

In the event of an emergency (such as a corrupted database), the Remoteboot service restores automatically from the <systemroot>\Rpl\Backup directory.


Troubleshooting Remoteboot

This section lists some common problems you may encounter using the Remoteboot service. For more troubleshooting information, see the \CLIENTS\RPL\README.TXT file on the Windows NT Server compact disc.


Remoteboot Service Won't Start

Check the server's event log, which can provide useful diagnostic information. In the Administrative Tools group, select Event Viewer.


Remoteboot Manager Won't Start

Be sure that you are logged on using an account that is a member of the Administrators local group.


Remoteboot Service Stops

Be sure that the server's own network configuration is correct, including hardware settings for the network adapter.


Remoteboot Client Won't Start

If a client won't boot remotely, or if you're having problems with the way the client is booting:

  • Be sure that the server is running and that the Remoteboot service is running.
  • The client must be on the same subnet as the server.
  • Check Remoteboot Manager's list of adapters that have not yet been converted to workstation records. To update the list, choose Refresh from the View menu. If the client's adapter is on the list, convert the adapter record to a workstation record.
  • Check the <systemroot>\Rpl\Fits directory. The server must have a .fit file for each profile that is to boot remotely.
  • Each client must have an RPL ROM chip installed on or built into its network adapter. This ROM chip may need to be enabled via jumpers or a configuration program.
  • Check the defaults for hardware settings in the <systemroot>\Rpl\Bblock\Netbeui\adapter\Protocol.ini file.
  • If the client has a hard disk, the hard disk may need to be prepared for the Remoteboot service using the rplenabl utility.
  • If the remoteboot server is a backup domain controller, wait until the account you've added has been replicated (or force synchronization to the primary domain controller using Server Manager).


No Profiles Available

You have not yet created any profiles. See "Managing Profiles" earlier in this chapter.


No Configurations Available

On the Remoteboot Manager Configure menu, click Check Configurations. If there still are no configurations available, you have not yet copied MS-DOS files to the server. See "Installing MS-DOS Files on the Remoteboot Server" earlier in this chapter.


Chapter 16 - MS Network Client Version 3.0 for MS-DOS

This chapter tells how to install and use Microsoft Network Client version 3.0 for MS-DOS. Network Client is software that you install on a computer running the MS-DOS operating system so that the computer can use resources on a network. For example, a computer with Network Client can use printers, programs, and data stored on a computer running Windows NT Server.

With Network Client, your computer can use resources on Microsoft networks, as well as other networks such as Microsoft LAN Manager networks.

In addition, if the computer had Novell NetWare installed before you install Network Client, you can still connect to NetWare resources (in addition to Microsoft network resources). For more information, see the Readme.txt file located in the directory that contains the Network Client files.


Making Installation Disks

A network administrator makes installation disks using the Network Client Administrator on a computer running Windows NT Server. For details, see Chapter 11, "Managing Client Administration," in the Windows NT Server Concepts and Planning Guide.

There are two kinds of Network Client installation disks:

  • An installation disk set contains all of the Network Client software. For Network Client 3.0, this is just one disk. You install manually using only this disk.
  • A network installation startup disk contains basic MS-DOS and Network Client software, just enough to start a client computer and then copy the full Network Client software over the network from the computer running Windows NT Server. This is usually faster than installing manually.


Setting Up and Configuring Network Client

The Setup program for Network Client identifies the computer's hardware and software, configures Network Client to run on the computer, and copies necessary files to the computer's hard disk.

Before you set up Network Client, you need to determine the following:

  • The user name to be used

The user name identifies a member of the workgroup or domain. Choose a unique name in the workgroup or domain.

  • The name to be assigned to the computer

This unique name identifies the computer within the network. Often this name is a variation of the user name.

  • The name of the user's workgroup and/or domain

This name determines how your computer fits in with other computers that are already organized into groups on the network. These are not names that you make up; they already exist on the network. Ask the network administrator if you don't know what names to use.

  • Full redirector or basic redirector

Full redirector means that you have all Network Client functions available, including logging on to domains and using advanced network applications. You can choose the basic redirector instead, which uses less memory and disk space, if you need only standard workgroup functions like connecting to shared files and printers.

To use Microsoft Windows with Network Client, you must install the full redirector, and you must start it with the net start full command before starting Windows. Windows for Workgroups, Windows 95, and the Windows NT platform include their own network client capabilities, so you should not run Network Client with them.

If you will also use the Remote Access Service (RAS) to connect to a network over a phone line, you must install the full redirector.

  • The manufacturer and model of the network adapter

The Setup program attempts to determine the model of network adapter in the computer. Some network adapters have additional configuration options; see the network administrator or the network adapter documentation if you need to change configuration options.

  • The network protocol used on this network

Your computer must use the same protocol as the computers to which it connects. If you don't know what protocol the computers on your network use, ask the network administrator.

There are other options that you can change with the Setup program, but these are the most important options.

To set up Network Client

1. Depending on the type of installation disk you have:

  • For an installation disk set (all Network Client software is on the disk), put the disk in a floppy disk drive. If you put the disk in drive A, type a:\setup at the MS-DOS command prompt, and then press ENTER. If the floppy disk drive is a different letter, use that letter instead of a.

If the computer displays an error message about lack of memory, you may need to stop other programs that take up memory, by stopping the programs or by altering the Autoexec.bat file and restarting the computer.

  • For a network installation startup disk, put the disk in drive A and restart the computer. When the computer restarts, it will automatically run the Network Client installation program.

A prompt appears asking you for a username and password. Supply a username and password for an account with permission to connect to the directory on the computer running Windows NT Server where Network Client files are stored. When the computer displays a message about creating a password-list file, type n and then press ENTER.

The client must make a connection to the shared directory on the computer running Windows NT Server. If the computer displays an error message saying that "the specified shared directory cannot be found," check that the computer running Windows NT Server is indeed sharing the directory.

If the computer displays an error message about lack of memory, modify the Config.sys file on the network installation startup disk to use extended memory. For example, Emm386.exe and Himem.sys provide extended memory for MS-DOS 5.0 and later. If you do not have extended memory, use the NetBEUI or IPX protocols because they use less memory.

The network installation startup disk was configured using default settings for the network adapter. Please verify that the default settings are correct for your network adapter and modify them if necessary. (The settings are in the A:\Net\protocol.ini file.)

2. Follow the instructions of the Setup program.

If your network adapter does not appear in the list of supported network adapters, you may be able to use one of the following instead:

  • ArcNet-compatible for an ArcNet network adapter
  • NE1000-compatible for an 8-bit Ethernet network adapter that is not on the list
  • NE2000-compatible for a 16-bit Ethernet network adapter that is not on the list

If this still doesn't work, contact the network adapter manufacturer to obtain a device driver disk compatible with Microsoft Network Client. When you receive the driver disk, run Setup and choose Network Adapter Not Shown On List Below, and then follow the instructions.

If you need more information about any Setup dialog box, press F1 for Help.

The Network Client Setup program identifies the hardware on the computer, copies the Network Client files to the hard disk, and creates and modifies network configuration files. The Setup program creates System.ini and Protocol.ini files in the directory that contains the Network Client files. These files contain information about the computer's Network Client configuration.

Setup adds a device command to the Config.sys file to install the Ifshlp.sys device driver.

In the Autoexec.bat file, Setup adds to the path command the directory that contains the Network Client files. Also, if you specify that you want Network Client to start each time the computer is started, Setup adds the net start command. When net start runs, it examines the System.ini file, which contains information about the startup options you specified during Setup. Setup may add additional lines to the Autoexec.bat file to start programs needed for specific network protocols.

The changes Setup makes to the configuration files take effect when you restart the computer after the Setup program is finished.

If your startup information changes, you can update your configuration information by running Setup again. For example, you might change your workgroup name or network card.

To update a setting after you install Network Client

1. Change to the directory that contains your installed Network Client files, and then type setup at the command prompt.

Do not run the Setup.exe program that is on the installation disk.

If the computer displays an error message about lack of memory, use the net stop rdr command to stop the Network Client software before running Setup. You may need to stop other programs that take up memory by stopping the programs or by altering the Autoexec.bat file and restarting the computer. After running Setup, either restart the computer or, if you didn't change any settings, restart Network Client by typing net start rdr.

2. Examine the list that the Network Client Setup program displays to find the entries that you want to change. If a setting needs to be updated, press the up arrow key until you select that setting, and then press Enter.

3. Follow the instructions on your screen. If you need help at any time, press F1.


Using Network Client with the TCP/IP Protocol

The MS-DOS TCP/IP implementation for Microsoft Network Client version 3.0 for MS-DOS supports:

  • An MS-DOS-based interface.
  • Domain name resolver (DNR) to resolve hostname-to-IP address mappings if your network has a Domain Name System (DNS) server.
  • The Dynamic Host Configuration Protocol (DHCP).
  • Windows Internet Name Service (WINS) resolution.
  • Windows Sockets.

MS-DOS-based clients do not support following features which are provided by TCP/IP-32 for Windows for Workgroups version 3.11, TCP/IP for Windows 95, and Windows NT Workstation and Windows NT Server versions 3.5, 3.51, and 4.0:

  • Support for DNS resolution using WINS
  • Support for WINS resolution using DNS
  • Name registration with the WINS database. (MS-DOS-based computers are clients, not servers, and do not generally need registration.)
  • Ability to act as a WINS proxy node
  • Support for multiple network adapters
  • Support for Internet Group Management Protocol (IGMP).
  • DHCP command-line switches for Ipconfig.exe (use the DHCP Administration utility instead). Specifically, Ipconfig.exe does not support the following switches, which are available in the Ipconfig.exe utilities for Windows for Workgroups and the Windows NT platform:
    • IPCONFIG /release
    • IPCONFIG /renew
    • IPCONFIG /?
    • IPCONFIG /all


Getting Help

MS-DOS users can carry out Network Client commands in two ways: by using the pop-up interface or by typing commands at the MS-DOS command prompt. For information on using the pop-up interface, see the section "Using Network Client" later in this chapter. For both methods, Help is available for quick information about specific Network Client commands or features.

To get help for commands typed at the MS-DOS command prompt

Type the command name followed by /?, or type net help followed by the second word in the net command.

For example, for information about the net view command, at the MS-DOS command prompt type net view /? or type net help view.

To get a summary of all Network Client commands

At the MS-DOS command prompt, type net /? | more and press Enter.

To get help while using the pop-up interface

Press F1 or ALT+H.


Starting Network Client and Logging On

During Setup, you specify whether you want Network Client to start automatically every time the computer is started. You also specify whether a prompt appears to log on to the workgroup and/or to a domain at startup time. The default settings are to automatically start Network Client and prompt for logon each time the computer is started.

If you specify in Setup that Network Client should not start automatically, the user must start it.

To start Network Client and log on to the workgroup

1. At the MS-DOS command prompt, type net logon and press Enter.

2. If Network Client hasn't started, a prompt asks whether to start the workstation service. Type y and then press Enter.

3. If the prompt displaying the user name is correct, press Enter.

If you are logging on at someone else's computer, type your user name, and then press Enter.

4. At the prompt for a password, type your password, and then press Enter.

If you are logging on for the first time, you can specify any password up to 14 characters long. A prompt asks you to type your password again to confirm that it is correct. This is your workgroup password.

5. If you are logging on for the first time, and the computer is in a Windows NT Server domain, a prompt for the domain password appears. Type your domain password and press Enter.

After you type your password(s), Network Client reestablishes your persistent connections, if you have any. These are connections that you made before and specified that you want to have reestablished every time you log on to your workgroup. For more information, see the Help for net use.

Your workgroup password authorizes access to your password list file, which is a list of the passwords for connections made that are password-protected. If you do maintain a password list file, and you do log on to a domain, the password list file will also hold your domain password. For more information about the password list file and how to change your password, see the Help for net password.

If you have trouble starting or using Network Client, see the "Troubleshooting" section later in this chapter.


Using Network Client

MS-DOS users can issue Network Client commands by using the pop-up interface or by typing commands at the MS-DOS command prompt.

If you use the pop-up interface, you don't have to remember the syntax for the equivalent Network Client command at the MS-DOS command prompt. The pop-up interface also allows you to view your current connections, browse for shared resources, and make new connections in an easy-to-use environment. It is a character-based utility; you must use the keyboard rather than a mouse.

Experienced MS-DOS users who are familiar with Network Client commands may prefer to type commands at the MS-DOS command prompt rather than using the pop-up interface.


Loading and Displaying the Pop-up Interface

You can load and display the pop-up interface simultaneously or as two separate operations. Loading and displaying the pop-up interface simultaneously is easier than performing the operations separately, and it makes more efficient use of memory. You load and display the interface by typing a single command. When you finish using the interface, Network Client unloads it from memory, freeing about 29K of memory for programs. The disadvantage is that you cannot use the interface while using another program.

To load and display the pop-up interface simultaneously

1. At the MS-DOS command prompt, type net and press Enter.

The pop-up interface appears.

2. When you finish using the interface, press Esc. Network Client unloads the interface from memory.

The advantage of loading and displaying the pop-up interface separately is that you can display it at any time, either from the MS-DOS command prompt or while you are using another program. One disadvantage is that you need to use separate commands to load, display, and unload the interface. Also, the pop-up interface occupies about 29K of memory, whether you are using it or not, until you explicitly unload it from memory.

To load and display the pop-up interface separately

1. At the MS-DOS command prompt, type net start popup and press Enter.

Note

If the pop-up interface is loaded into memory automatically when you start the computer, skip this step.

2. When you want to display the pop-up interface, press ctrl+ALT+N.

If, during Setup, you chose a key other than N to display the pop-up interface, press CTRL+ALT plus the key you specified.

When you finish using the pop-up interface, you can unload it from memory.

To unload the pop-up interface from memory

At the MS-DOS command prompt, type net stop popup and press Enter.


Using Shared Directories

With Network Client, members of your workgroup can exchange information using shared directories. Shared directories are directories to which all users on a network have access. You use shared directories the same way you use the directories on your local hard disk, except that you have to connect to shared directories before you can use the files on them.

To use a file in a shared directory, you need to know the name of the computer that contains the shared directory and the name of the shared directory that contains the file you want. After you establish a connection, you treat the shared directory as if it were a disk drive on your computer.

You connect to a shared directory by assigning a drive letter to it.

To connect your computer to a shared directory

1. Display the pop-up interface as described in the preceding section.

2. In the Path field of the Disk Connection pop-up, type two backslashes, the name of the computer, and the shared directory that you want to connect to.

For example, to connect to a directory named Public on a computer named Rene, type \\rene\public in the Path field.

If you're not sure of the name of the computer or directory you want to connect to, you can browse through a list by choosing the Browse button (press ALT+B, and then press F1 for help). Browsing will show you only the computers in your workgroup.

3. To assign a drive letter to the shared directory, choose the Drive field by pressing ALT+V, type the drive letter you want to use, and then press ENTER.

If you do not specify a drive letter for the shared directory, Network Client assigns the first available drive letter.

4. If you want to connect your computer to the shared directory every time you log on, make sure an X appears in the Reconnect At Startup check box.

To select or clear the Reconnect At Startup check box, press ALT+R.

5. To connect to the shared directory specified in the Path field, choose the Connect button by pressing ALT+C.

You can also connect to a shared directory by typing net use at the MS-DOS command prompt. For information on the net use command and its syntax, see the Help for net use.

For information about browsing for shared directories and disconnecting from a shared directory, press F1 in the pop-up interface, or see the Help for the net view and net use commands.

Note

Your workgroup may include computers that share directories but do not appear in the Browse dialog box. You can try connecting to these computers, even though you cannot browse for their names.


Using Shared Printers

You can print files with Network Client by sending them from your computer to printers that are shared by members of your workgroup. Connecting to a shared printer allows you to use it as if it were physically connected to your computer. You connect your computer to a shared printer by assigning a parallel port (LPT) to it. You can use port LPT1, LPT2, or LPT3.

To connect your computer to a shared printer

1. Display the pop-up interface, as described earlier in this chapter.

2. Choose the Show Printers button by pressing ALT+S.

3. In the Port field of the Printer Connection dialog box, type two backslashes and the number of the parallel port (LPT) that you want to assign to the shared printer, and then press TAB.

4. In the Path field, type the name of the computer and shared printer that you want to connect to. For example, to connect to a printer named Laser that is physically connected to a computer named Clive, type \\clive\laser in the Path field.

5. If you want to connect your computer to this printer every time you log on to your workgroup, make sure an X appears in the Reconnect At Startup check box.

To select or clear the Reconnect At Startup check box, press ALT+R.

6. To connect to the shared printer specified in the Path field, choose the Connect button by pressing ALT+C.

You can also issue the net use command at the MS-DOS command prompt to connect to a shared printer. For information on the net use command and its syntax, see the Help for net use.

For information about browsing for shared printers and disconnecting from a shared printer, press F1 in the pop-up interface, or see the Help for the net view and net use commands.

Note

Your workgroup may include computers that share printers but do not appear in the Browse dialog box. You can try connecting to these computers, even though you cannot browse for their names.

After you connect your computer to a shared printer, you can print formatted files from the application you used to create them. You can also print unformatted text files from MS-DOS with the print command. For more information, see the Help for the print command.

You can also display the pop-up interface to pause, resume, or delete a print job, and to view the print queue, which is the list of files that are waiting to print on a particular printer. For information, see the Help for the pop-up interface or for the net print command.


Using Network Client with Microsoft Windows

This section contains information about configuring Microsoft Windows so that it runs with Network Client.

Note

Windows for Workgroups, Windows 95, and Windows NT include their own network client capabilities, so you should not run Network Client with them.

To use Microsoft Windows with Network Client, you must install the full redirector, and you must start it with the net start full command before starting Windows.

To configure Windows to run with Network Client

1. Start Windows.

2. In the Main group, choose the Windows Setup icon.

The Windows Setup window appears. It lists your current display, keyboard, mouse, and network settings.

3. From the Options menu, choose Change System Settings.

The Change System Settings dialog box appears.

4. Open the list for the Network setting by clicking the arrow to the right of it. Or press TAB until you select the Network setting, and then press ALT+DOWN ARROW to open the list.

5. Click Microsoft Network (or 100% compatible), or select it by pressing the up arrow or DOWN ARROW key.

6. Click OK.

Setup may prompt you to insert a Windows Setup disk in drive A. If it does, insert the disk. However, if the file for the Microsoft Network device driver is in a directory on your hard disk, you can type its path in the box instead.

7. Choose the OK button.


Troubleshooting

This section provides help if you encounter problems when using Network Client.


Network Client Will Not Start After a Successful Setup

If Network Client won't start after you complete Setup, try the following steps to solve the problem:

  • Make sure that all cables and connectors are securely fastened and that the network adapter is securely in its slot.
  • If the network adapter came with a diagnostics program, try running the program. For more information, see the documentation that came with the network adapter.
  • Run the net diag command. You can use net diag to test a specific connection with another computer or you can use net diag /status to see the status of your own network adapter. For information, type net help diag at the MS-DOS command prompt.
  • If you are using an external transceiver, specify the correct setting. For more information, see the following section, "Specifying an External Transceiver."
  • Make sure the correct base memory address and interrupt request (IRQ) settings are specified for the network adapter. For more information, see "Checking and Changing Network-Adapter Settings," later in this chapter.
  • Make sure the device command for EMM386 in your Config.sys file excludes the memory address used by your network adapter. For more information, see "Making Sure EMM386 Doesn't Conflict with the Network Adapter," later in this chapter.
  • Make sure the network adapter is on the list provided in Setup. If your network adapter is not on this list, you might be able to get it to work by using a generic setting. For more information, see the Setup instructions earlier in this chapter.
  • Make sure the network adapter is using a different interrupt (IRQ) than the mouse. For more information about determining what interrupt to assign to the network adapter, see the documentation that came with the network adapter.
  • If you are using the NWLink (IPX/SPX-compatible) protocol, make sure the network adapter is set for the proper network topology type. NWLink supports Ethernet network adapters only on 802.2 topology and token ring and FDDI network adapters only on 802.3 topology.
  • You might need to change the network adapter's configuration settings. If you have an ISA adapter that is configured by using jumpers and switches, you might need to change their positions or settings. If you have a software-configured adapter, use the configuration program that came with the network adapter to change your settings. For more information, see the documentation that came with the network adapter.


Specifying an External Transceiver

This section applies to you only if your network adapter is attached to an external transceiver. An external transceiver is a small box that connects the network cable to the cable that attaches to a network adapter. Only some Ethernet network adapters use external transceivers.

To specify that you are using an external transceiver

1. Start the Network Client Setup program, as described in the section "Setting Up and Configuring Network Client" earlier in this chapter.

2. Select Change Network Configuration by pressing the UP ARROW key, and then press ENTER.

A list of options for modifying network-adapter and protocol settings appears.

3. Select Change Settings by pressing the UP ARROW key, and then press ENTER.

A list of network-adapter and protocol settings appears.

4. Press the UP ARROW key until you have selected the Transceiver setting, and then press ENTER.

A list of values appears.

5. From the list of values, select External, Thick, or DIX (depending on what kind of transceiver you have) by pressing the UP ARROW or DOWN ARROW key. Then press ENTER.

The new value appears on the Transceiver line in the list of network-adapter settings.

6. Press ENTER, and then follow the instructions on the screen to complete Setup.

7. When Setup is complete, restart the computer by pressing ENTER.

If Network Client still does not start, proceed to the following section.


Checking and Changing Network-Adapter Settings

The Network Client Setup program examines your computer's configuration and attempts to determine the network adapter's base memory address and interrupt request (IRQ) setting. If Setup incorrectly identifies these, Network Client will not start.

For information about determining the correct settings yourself, see the documentation that came with the network adapter.

After you determine the correct base memory address and interrupt setting, you can specify them by running Setup again.

To change the base memory address or interrupt setting

1. Start the Network Client Setup program, as described earlier in this chapter.

2. Select Change Network Configuration by pressing the UP ARROW key, and then press ENTER.

A list of options for modifying network-adapter and protocol settings appears.

3. Select Change Settings by pressing the UP ARROW key, and then press ENTER.

A list of network-adapter and protocol settings appears.

4. If you want to change the setting for the network adapter's interrupt, proceed to step 5. If you want to change the setting for the network adapter's base memory address, do the following:

  • Select the setting for the base memory address by pressing the UP ARROW key, and then press ENTER. This setting is named Memory Window, RAM Address, or something similar. You might have to press the PAGE UP or PAGE DOWN key to find this setting.

A list of values appears.

  • Select the base memory address you want by pressing the UP ARROW or DOWN ARROW key, and then press ENTER.

The new value appears on the base memory address line in the list of network-adapter settings.

5. If you do not want to change the network adapter's interrupt setting, proceed to step 6. If you want to change the setting, do the following:

  • Select the interrupt setting by pressing the UP ARROW key, and then press ENTER. This setting is named IRQ_Level, Interrupt, or something similar. You might have to press the PAGE UP or PAGE DOWN key to find this setting.

A list of values appears.

  • Select the interrupt you want by pressing the UP ARROW or DOWN ARROW key, and then press ENTER.

The new value appears on the interrupt line in the list of network-adapter settings.

6. Choose The Listed Options Are Correct by pressing ENTER. Then follow the instructions on the screen to complete Setup.

7. When Setup is complete, restart the computer by pressing ENTER.

If Network Client still does not start, proceed to the following section.


Making Sure EMM386 Doesn't Conflict with the Network Adapter

If you use the EMM386 memory manager, make sure that it does not use the same memory that the network adapter uses. If you are using a different memory manager, such as QEMM or 386MAX, see the documentation that came with that memory manager.

To ensure that EMM386 doesn't conflict with the network adapter

1. Use any text editor to open the Config.sys file.

2. Look for the device command line for the EMM386 memory manager. It should look similar to the following:

device=c:\dos\emm386.exe

If the Config.sys file does not contain a device command for EMM386, you are not using EMM386.

3. If the Config.sys file contains a device command for EMM386, add the following to that command line:

x=mmmm-nnnn

For mmmm, specify the base memory address of your network adapter. For nnnn, specify a value that is 32K greater than mmmm by using the following method:

If the second character in mmmm is 8, the last three characters you specify for nnnn should be FFF. For example, if the base memory address is D800, the device command line should look similar to the following:

device=c:\dos\emm386.exe x=D800-DFFF

If the second character in mmmm is 0, the last three characters you specify for nnnn should be 7FF. For example, if the base memory address is C000, the device command line should look similar to the following:

device=c:\dos\emm386.exe x=C000-C7FF

Note

This method for determining the value for nnnn is based on a network-adapter device driver that uses 32K of memory. The values for mmmm and nnnn are hexadecimal numbers. Check your network-adapter documentation to see if the network adapter uses more or less than 32K of memory. If it does, adjust the value for nnnn accordingly. For example, if the adapter uses only 16K of memory, the characters to specify for nnnn in the preceding two examples would be DBFF and C3FF, respectively.

4. Save the Config.sys file, and then quit the text editor.

5. Restart the computer.


Shared Resources Are Not Listed

If the names of shared resources do not appear when you use the Browse dialog box in the pop-up interface or when you type net view at the MS-DOS command prompt, try the following:

  • Make sure the network-adapter settings are correct. For more information, see "Specifying an External Transceiver" and "Checking and Changing Network-Adapter Settings," earlier in this section.
  • Sometimes, when a computer in your workgroup is turned off or restarted, you won't be able to see other computers on the network for a few minutes. Wait a few minutes, and then check again.
  • If you know the name of the shared directory or printer you want to connect to, try connecting to it by typing the path of the shared directory or printer in the Path field of the Disk Connections or Printer Connections dialog boxes. Or specify the path by using the net use command at the MS-DOS command prompt.


The Computer You Want to Connect to Is Not Listed

If a computer on the network does not appear when you use the Browse dialog box in the pop-up interface or when you type net view at the MS-DOS command prompt, one of the following might be the cause:

  • The computer might have been recently restarted. Wait a few minutes, and then try again.
  • If a computer is part of another workgroup (not your own), you cannot use the Browse dialog box in the pop-up interface to display it. To see a list of computers in another workgroup, you must use the net view command with the /workgroup option at the MS-DOS command prompt. For more information, type net help view at the MS-DOS command prompt.


The Mouse Doesn't Work Correctly

If the mouse worked correctly before you set up Network Client, but doesn't work afterward, the mouse might be using the same interrupt setting as the network adapter. Try assigning a different interrupt to the network adapter.

For information about determining the correct interrupt setting for the network adapter, see the documentation that came with the network adapter. For information about how to change the interrupt setting, see "Checking and Changing Network-Adapter Settings," earlier in this section.


Error 234: Additional Data is Available

When you browse the network using the net view command from a computer running Network Client, the following error appears:

NET3513: More data is available than can be returned by LAN Manager.

This problem occurs when you browse a computer that has a share name longer than 12 characters.


The NET3778 Error Message Appears

When you log on to a domain across a router using the TCP/IP protocol from a LAN Manager 2.2c client computer or a Network Client 3.0 client computer configured as a WINS client, the NET3778 error message appears.

To work around this problem, add the following entry for a domain controller in the LMHOSTS file:

#DOM:<domain name>


Wrong Persistent Connection Is Removed

After you create several persistent network connections in Network Client 3.0 and attempt to remove a specific network connection, it is not removed. The most recent persistent network connection is removed. For example, if you have network connections assigned to drives E, G, and F (in this order), and you attempt to remove drive E, drive F is removed. This problem does not occur if you use the following command:

net use e: /d


Network Clients Are Unable to Change Their Passwords

If the account policy User must log on in order to change password is checked in Windows NT 3.5, 3.51, or 4.0, Network Client for MS-DOS 3.0 clients are unable to change their passwords. The policy is meant to keep users with expired accounts from being able to change their passwords. However, these clients receive Access Denied errors when they attempt to change their passwords, regardless of their account status.

This problem occurs because Network Client sets an inappropriate flag when it requests a password change on a Windows NT Server.

To work around this problem, turn off the User must log on in order to change password policy in User Manager on the computer running Windows NT Server.


Troubleshooting Network Client and DHCP

If you have problems using Network Client with the Dynamic Host Configuration Protocol (DHCP), use the following troubleshooting steps, utilities, and Resources to resolve the problem.

Troubleshooting Steps

  1. Simplify your computer's boot configuration by removing terminate-and-stay-resident (TSR) programs, and third-party utilities from your Config.sys and Autoexec.bat files. Remove or minimize the use of memory managers. If you correct the problem, add back functionality until you discover the utility or combination of utilities that is creating the problem.
  2. Verify that the Protocol.ini and System.ini files reflect your configuration. For more information:
    • See Section 16, "Network Settings in System.ini," of the Readme.txt file in the Microsoft Network Client directory.
    • Check the Help available in Setup.exe. Use the F1 key to get clarification on a specific option.
    • Query in the Microsoft Knowledge Base for the name of your specific network interface card (NIC).

      Note The Windows NT Knowledge Base (KB) is available in Help files on the Windows NT Server Resource Kit CD.

  3. Force Microsoft Network Client to recreate the hidden DHCP configuration file (Dhcp.prm). To do this:

A. Use the Attrib command to remove the hidden and read-only file attributes.

B. Delete the file.

C. Quit and restart Microsoft Network Client to allow the file to be recreated.

D. Network Client automatically creates the Dhcp.prm (a hidden binary file) in the installation directory.

  1. Verify that the IP is functioning correctly by using the ping, net view, net config, and net diag commands on Network Client.

For more information see:

  • The Help available for each command by typing /?. For example, net view /?. For ping help, type the command without any parameters.
  • The Readme.txt file in the Microsoft Network Client directory. Check the table of contents for sections that pertain to your specific installation.

Troubleshooting Utilities

You can run Ipconfig on the client computer to check the client's IP configuration. For more information, see:

  • Section 21, "Ipconfig.exe and Controlling DHCP Leases," in the Readme.txt file in the Microsoft Network Client directory.
  • The following Knowledge Base articles:
    • Q94069: Microsoft TCP/IP Protocol Comparison and FAQ
    • Q123285: IPCONFIG Displays Invalid Results
    • Q130538: DHCP-Enabled MS-DOS Clients Do Not Resolve Host Names

You can run DHCP Manager on Windows NT Server to check the DHCP Server configuration. Use the Scope Active Leases option to verify that leasing is occurring. For more information, see:

  • The Microsoft Windows NT Server Networking Supplement.
  • Knowledge Base article Q120829 titled "DHCP (Dynamic Host Configuration Protocol) Basics."

Note

The Windows NT Knowledge Base (KB) is available in Help files on the Windows NT Server Resource Kit compact disc.

Troubleshooting Resources

If the troubleshooting topics in this chapter don't help you resolve your Network Client problem, see the Readme.txt file in the Microsoft Network Client installation directory, or query the Microsoft Knowledge Base.

Note

The Windows NT Knowledge Base is available in Help files on the Windows NT Server Resource Kit compact disc.


Appendix A - TCP/IP Utilities Reference

This appendix is a reference for using Microsoft TCP/IP utilities, which are diagnostic and connectivity utilities for network and connectivity administration. These client utilities are provided for file transfer, terminal emulation, and network diagnostics.

Diagnostic commands help you detect TCP/IP networking problems. Connectivity commands enable users to interact with and use resources on Microsoft hosts and non-Microsoft hosts such as UNIX workstations. The following commands are included:

  • Diagnostic commands: arp, hostname, ipconfig, lpq, nbtstat, netstat, ping, route, and tracert
  • Connectivity commands: finger, ftp, lpr, rcp, rexec, rsh, telnet, and tftp

Important

All passwords used by Windows networking services are encrypted. However, the ftp, ftpsvc, rexec, and telnet connectivity utilities all rely on clear-text password authentication by the remote computer. Clear-text passwords are not encrypted before being sent over the network. This enables another user equipped with a network analyzer on the same network to steal a user's remote account password. For this reason, it is strongly recommended that users of these utilities choose different passwords than their Windows NT-based workgroup, workstation, or domain for the passwords used on non-Microsoft remote computers to which they connect by using the ftp, ftpsvc, rexec, and telnet utilities.

Note

Switches used in the syntax for TCP/IP commands are case-sensitive. For example, for nbtstat, the switch -R has a different effect from the -r switch.

See also the topic "TCP/IP Procedures Help" in Control Panel Help.


arp

This diagnostic command displays and modifies the IP-to-Ethernet or Token Ring physical address translation tables used by the Address Resolution Protocol (ARP).

Syntax

arp -a [inet_addr] [-N [if_addr]]
arp -d inet_addr [if_addr]
arp -s inet_addr ether_addr [if_addr]

Parameters

-a

Displays current ARP entries by querying TCP/IP. If inet_addr is specified, only the IP and physical addresses for the specified host are displayed.

-d

Deletes the entry specified by inet_addr.

-g

Same as -a

-s

Adds an entry in the ARP cache to associate the IP address inet_addr with the physical address ether_addr. The physical address is given as 6 hexadecimal bytes separated by hyphens. The IP address is specified using dotted decimal notation. The entry is static. It will not be automatically removed from the cache after the timeout expires and will not exist after a reboot of your computer.

-N [if_addr]

Displays the ARP entries for the network interface specified by if_addr.

ether_addr

Specifies a physical address.

if_addr

Specifies, if present, the IP address of the interface whose address translation table should be modified. If not present, the first applicable interface will be used.

inet_addr

Specifies an IP address in dotted decimal notation.


finger

This connectivity command displays information about a user on a specified host running the Finger service. Output varies based on the configuration of the remote host.

Syntax

finger [-l] [user]@ hostname [...]

Parameters

-l

Displays information in long list format; not supported on all remote computers.

user

Specifies the user you want information about. Omit the user parameter to display information about all users on the specified host.

@hostname

Specifies the host name or IP address of the remote computer whose users you want information about.


ftp

This connectivity command transfers files to and from a host running an FTP server service, for example the Microsoft Internet Information Server. (A service is called a daemon in UNIX). Ftp is a complete session-oriented file transfer protocol. Ftp can be used interactively or by processing ASCII text files.

Syntax

ftp [-v] [-n] [-i] [-d] [-g] [-s: filename] [hostname]

Parameters

-v

Suppresses display of remote server responses.

-n

Suppresses autologon upon initial connection.

-i

Turns off interactive prompting during multiple file transfers.

-d

Enables debugging, displaying all ftp commands passed between the client and server.

-g

Disables filename globbing, which permits the use of wildcard characters in local file and path names. (See the glob command in the TCP/IP Procedure Help. )

-s: filename

Specifies a text file containing ftp commands; the commands automatically run after ftp starts. Use this switch instead of redirection (>).

hostname

Specifies the host name or IP address of the remote host to connect to. The host, if specified, must be the last parameter on the line.

The following table lists the ftp commands. For details about syntax of individual ftp commands, choose the ftp commands topic in the TCP/IP Procedure Help.

Table A.1 FTP Commands in Windows NT

Command | Purpose
! | Runs the specified command on the local computer.
? | Displays descriptions for ftp commands. ? is identical to help.
append | Appends a local file to a file on the remote computer using the current file type setting.
ascii | Sets the file transfer type to ASCII, which is the default.
bell | Toggles a bell to ring after each file transfer command is completed. By default, the bell is off.
binary | Sets the file transfer type to binary.
bye | Ends the FTP session with the remote host and exits ftp.
cd | Changes the working directory on the remote host.
close | Ends the FTP session with the remote server and returns to the command interpreter.
debug | Toggles debugging. When debugging is on, each command sent to the remote host is printed, preceded by the string --->. By default, debugging is off.
delete | Deletes files on remote hosts.
dir | Displays a list of a remote directory's files and subdirectories.
disconnect | Disconnects from the remote host, retaining the ftp prompt.
get | Copies a remote file to the local host using the current file transfer type.
glob | Toggles filename globbing. Globbing permits use of wildcard characters in local file or path names. By default, globbing is on.
hash | Toggles hash-sign (#) printing for each data block transferred. The size of a data block is 2048 bytes. By default, hash-sign printing is off.
help | Displays descriptions for ftp commands.
lcd | Changes the working directory on the local host. By default, the current directory on the local host is used.
literal | Sends arguments, verbatim, to the remote FTP server. A single FTP reply code is expected in return.
ls | Displays an abbreviated list of a remote directory's files and subdirectories.
mdelete | Deletes files on remote hosts.
mdir | Displays a list of a remote directory's files and subdirectories. Mdir enables you to specify multiple files.
mget | Copies remote files to the local host using the current file transfer type.
mkdir | Creates a remote directory.
mls | Displays an abbreviated list of a remote directory's files and subdirectories.
mput | Copies local files to the remote host using the current file transfer type.
open | Connects to the specified FTP server.
prompt | Toggles prompting. Ftp prompts during multiple file transfers to enable you to selectively retrieve or store files; mget and mput transfer all files if prompting is turned off. By default, prompting is on.
put | Copies a local file to the remote host using the current file transfer type.
pwd | Displays the current directory on the remote host.
quit | Ends the FTP session with the remote host and exits ftp.
quote | Sends arguments, verbatim, to the remote FTP server. A single FTP reply code is expected in return. Quote is identical to literal.
recv | Copies a remote file to the local host using the current file transfer type. Recv is identical to get.
remotehelp | Displays help for remote commands.
rename | Renames remote files.
rmdir | Deletes a remote directory.
send | Copies a local file to the remote host using the current file transfer type. Send is identical to put.
status | Displays the current status of FTP connections and toggles.
trace | Toggles packet tracing; trace displays the route of each packet when running an ftp command.
type | Sets or displays the file transfer type.
user | Specifies a user to the remote host.
verbose | Toggles verbose mode. If on, all ftp responses are displayed; when a file transfer completes, statistics regarding the efficiency of the transfer are also displayed. By default, verbose is on.


hostname

This diagnostic command prints the name of the host on which the command is issued.

Syntax

hostname

This command has no parameters.


ipconfig

This diagnostic command displays all current TCP/IP network configuration values. This command is useful on computers running DHCP because it enables users to determine which TCP/IP configuration values have been configured by DHCP. If you enter only ipconfig without parameters, the response is a display of all of the current TCP/IP configuration values, including IP address, subnet mask, and default gateway.

Syntax

ipconfig [/all | /renew [adapter] | /release [adapter]]

Parameters

all

Produces a full display. Without this switch, ipconfig displays only the IP address, subnet mask, and default gateway values for each network card.

renew [adapter]

Renews DHCP configuration parameters. This option is available only on computers running the DHCP Client service. To specify an adapter name, type the adapter name that appears when you use ipconfig without parameters.

release [adapter]

Releases the current DHCP configuration. This option disables TCP/IP on the local computer and is available only on DHCP clients. To specify an adapter name, type the adapter name that appears when you use ipconfig without parameters.


lpq

This diagnostic utility is used to obtain the status of a print queue on a host running the LPD server. To use the lpq command from the Windows NT command prompt, you must first install the Microsoft TCP/IP Printing service from the Network option in Control Panel.

Syntax

lpq -S Server -P Printer [-l]

Parameters

-S Server

Specifies the name of the host that has the printer attached to it.

-P Printer

Specifies the name of the printer for the desired queue.

-l

Specifies that a detailed status should be given.


lpr

This connectivity utility is used to print a file to a host running an LPD server. You use the lpr command from the Windows NT command prompt, you must first install the Microsoft TCP/IP Printing service from the Network option in Control Panel.

Syntax

lpr -S Server -P Printer [-o Options] [-C Class] [-J Jobname] [-o option] [-x] [-d] filename

Parameters

-S Server

Specifies the name of the host that has the printer attached to it.

-P Printer

Specifies the name of the printer for the desired queue.

-C Class

Specifies the content of the banner page for the class.

-J Jobname

Specifies the name of this job.

-o option

Indicates the type of the file (by default assumes a text file). Use "-o l" for binary PostScript files.

-x

Indicates compatibility with SunOS version 4.1.x and earlier.

-d

Send data file first.

filename

The name of the file to be printed.

Notes

To print a nontext file, such as a PostScript file, from a Windows NT-based computer to a printer controlled by a UNIX computer, use the lpr utility with the -ol switch. The l option specifies that the print file should be passed as is to the printer, with no processing by the Lpdsvc service.

To print a nontext file from a UNIX computer to a printer controlled by a Windows NT-based computer, use the lpr utility on the UNIX computer with the
-l switch. For details on the UNIX lpr utility, see your UNIX documentation.


nbtstat

This diagnostic command displays protocol statistics and current TCP/IP connections using NetBIOS over TCP/IP (NetBT).

Syntax

nbtstat [-a remotename] [-A IPaddress] [-c] [-n] [-R] [-r] [-S] [-s] [interval]

Parameters

-a remotename

Lists the remote computer's name table using the computer's name.

-A IPaddress

Lists the remote computer's name table using the computer's IP address.

-c

Lists the contents of the NetBIOS name cache, giving the IP address of each name.

-n

Lists local NetBIOS names.

-R

Reloads the LMHOSTS file after purging all names from the NetBIOS name cache. Can be used if LMHOSTS LOOKUP is enabled on the computer. (To enable LMHOSTS LOOKUP, check Enable LMHOSTS LOOKUP on the WINS Address tab on the TCP/IP Properties page.

-r

Lists name resolution statistics for Windows networking. On a Windows NT-based computer configured to use WINS, this option returns the number of names resolved and registered via broadcast or via WINS.

-S

Displays both workstation and server sessions, listing the remote computers by IP address only.

-s

Displays both workstation and server sessions. It attempts to resolve the remote computer IP address to a name by using the name resolution services (including, but not limited to, HOSTS FILE LOOKUP) which are configured on the computer.

interval

Redisplays selected statistics, pausing interval seconds between each display. Press Ctrl+C to stop redisplaying statistics. If this parameter is omitted, nbtstat prints the current configuration information once.

Notes

The column headings generated by the nbtstat utility have the following meanings.

In

Number of bytes received.

Out

Number of bytes sent.

In/Out

Whether the connection is from the computer (outbound) or from another computer to the local computer (inbound).

Life

The remaining time that a name table cache entry will live before it is purged.

Local Name

The local NetBIOS name associated with the connection.

Remote Host

The name or IP address associated with the remote computer.

Type

This refers to the type of name. A name can either be a unique name or a group name.

<03>

Each NetBIOS name is 16 characters long. The last byte has special significance, and is used to indicate specific NetBIOS applications that each identify themselves by using the NetBIOS computer name. (The <> notation is the last byte converted to a hexadecimal value.)

State

The state of NetBIOS connections. The possible states are shown in the following list:

State | Meaning
Connected | The session has been established.
Associated | A connection endpoint has been created and associated with an IP address.
Listening | This endpoint is available for an inbound connection.
Idle | This endpoint has been opened but cannot receive connections.
Connecting | The session is in the connecting phase where the name-to-IP address mapping of the destination is being resolved.
Accepting | An inbound session is currently being accepted and will be connected shortly.
Reconnecting | A session is trying to reconnect if it failed to connect on the first attempt.
Outbound | A session is in the connecting phase where the TCP connection is currently being created.
Inbound | An inbound session is in the connecting phase.
Disconnecting | A session is in the process of disconnecting.
Disconnected | The local computer has issued a disconnect, and it is waiting for confirmation from the remote computer.


netstat

This diagnostic command displays protocol statistics and current TCP/IP network connections.

Syntax

netstat [-a] [-e][-n][-s] [-p protocol] [-r] [interval]

Parameters

-a

Displays all connections and listening ports; server connections are usually not shown.

-e

Displays Ethernet statistics. This can be combined with the -s option.

-n

Displays addresses and port numbers in numerical form (rather than attempting name lookups).

-s

Displays per-protocol statistics. By default, statistics are shown for TCP, UDP, ICMP, and IP; the -p option can be used to specify a subset of the default.

-p protocol

Shows connections for the protocol specified by proto; proto (See notes) can be tcp or udp. If used with the -s option to display per-protocol statistics, protocol can be tcp, udp, icmp, or ip.

-r

Displays the contents of the routing table.

interval

Redisplays selected statistics, pausing interval seconds between each display. Press Ctrl+C to stop redisplaying statistics. If this parameter is omitted, netstat prints the current configuration information once.

Notes

The netstat utility provides statistics on the following network components.

Statistic | Purpose
Foreign Address | The IP address and port number of the remote computer to which the socket is connected. The name corresponding to the IP address is shown, instead of the number, if the HOSTS file contains an entry for the IP address. In cases where the port is not yet established, the port number is shown as an asterisk (*).
Local Address | The IP address of the local computer, as well as the port number the connection is using. The name corresponding to the IP address is shown, instead of the number, if the HOSTS file contains an entry for the IP address. In cases where the port is not yet established, the port number is shown as an asterisk (*).
Proto | The name of the protocol used by the connection.
(state) | Indicates the state of TCP connections only. The possible states are: CLOSED FIN_WAIT_1 SYN_RECEIVED CLOSE_WAIT FIN_WAIT_2 SYN_SEND ESTABLISHED LISTEN TIMED_WAIT LAST_ACK


nslookup

This diagnostic tool displays information from Domain Name System (DNS) name servers. Before using this tool, you should be familiar with how DNS works. Nslookup is available only if the TCP/IP protocol has been installed.

Syntax

nslookup [-option …] [hostname | - [server]]

Modes

Nslookup has two modes: interactive and non-interactive.

If you only need to look up a single piece of data, use non-interactive mode. For the first argument, type the name or IP address of the host to be looked up. For the second argument, type the name or IP address of a DNS name server. If you omit the second argument, the default DNS name server will be used.

If you need to look up more than one piece of data, you can use interactive mode. Type a hyphen (-) for the first argument and the name or IP address of a DNS name server for the second argument. Or, omit both arguments (the default DNS name server will be used).

Parameters

-option …

Specifies one or more nslookup commands as a command-line option. For a list of these optional commands, see the following Table A.2, Nslookup Commands in Windows NT. Each option consists of a hyphen (-) followed immediately by the command name and, in some cases, an equal sign (=) and then a value. For example, to change the default query type to host information and the initial timeout to 10 seconds, you would type:

nslookup -querytype=hinfo -timeout=10

The command line length must be less than 256 characters.

hostname

Look up information for hostname using the current default server or using server if specified. If computer-to-find is an IP address and the query type is A or PTR, the name of the computer is returned. If hostname is a name and does not have a trailing period, the default DNS domain name is appended to the name. (You can change this behavior by using the nslookup set command. Refer to the following Table A.2, Nslookup Commands in Windows NT. To look up a computer not in the current DNS domain, append a period to the name.

If you type a hyphen (-) instead of hostname, the command prompt changes to nslookup interactive mode.

server

Host name of the DNS server to use. If you omit server, the default DNS name server is used.

Notes

Interactive Commands

  • To interrupt interactive commands at any time, press CTRL+C.
  • To exit, type exit.
  • The command line length must be less than 256 characters.
  • To treat a built-in command as a host name, precede it with the escape character (\).
  • An unrecognized command is interpreted as a host name.

Diagnostics

If the nslookup command fails, an error message prints. Possible errors are:

  • Timed out

The server did not respond to a request after a certain amount of time (changed with set timeout=value) and a certain number of retries (changed with set retry=value).

  • No response from server

No DNS name server is running on the server.

  • No records

The DNS name server does not have resource records of the current query type for the host, although the host name is valid. The query type is specified with the set querytype command.

  • Non-existent domain

The host name or DNS domain name does not exist.

  • Connection refused

– Or –

  • Network is unreachable

The connection to the DNS name server or Finger server could not be made. This error commonly occurs with ls and finger requests.

  • Server failure

The DNS name server found an internal inconsistency in its database and could not return a valid answer.

  • Refused

The DNS name server refused to service the request.

  • Format error

The DNS name server found that the request packet was not in the proper format. It may indicate an error in nslookup.

The following table shows the nslookup commands. For details about syntax for individual nslookup commands, choose the nslookup commands topic in the TCP/IP Procedure Help.

Table A.2 Nslookup Commands in Windows NT

Command | Purpose
exit | Exits interactive nslookup.
finger | Connects with the Finger server on the current host. The current host is defined when a previous lookup for a host was successful and returned the address information.
help | Displays a brief summary of nslookup commands.
ls | Lists information for a DNS domain. The default output contains host names and their IP addresses. (When output is directed to a file, hash marks (###) are printed for every 50 records received from the server.)
lserver | Changes the default server to the specified DNS domain. Lserver uses the initial server to look up the information about the specified DNS domain. (This is in contrast to the server command, which uses the current default server.)
root | Changes the default server to the server for the root of the DNS domain name space. Currently, the host G.ROOT-SERVERS.NET. is used. (This command is a synonym for lserver g.root-server.net.) The name of the root server can be changed with the set root command.
server | Changes the default server to the specified DNS domain. Server uses the current default server to look up the information about the specified DNS domain. (This is in contrast to the lserver command, which uses the initial server.)
set | Changes configuration settings that affect the behavior of the nslookup commands.
set all | Prints the current values of the configuration settings. Also prints information about the default server and host..
set cl[ass] | Changes the query class. (The class specifies the protocol group of the information.)
set [no]d2 | Turns exhaustive debugging mode on or off. Essentially all fields of every packet are printed.
set [no] deb[ug] | Turns debugging mode on or off. With debugging on, more information is printed about the packet sent to the server and the resulting answer.
set [no] def[name] | If set, appends the default DNS domain name to a single-component lookup request. (A single component is a component that contains no periods.)
set do[main] | Changes the default DNS domain to the name specified. The default DNS domain name is appended to a lookup request depending on the state of the defname and search options. The DNS domain search list contains the parents of the default DNS domain if it has at least two components in its name. For example, if the default DNS domain is mydomain.mycompany.com, the search list is mydomain.mycompany.com and mycompany.com. Use the set srchlist command to specify a different list. Use the set all command to display the list.
Set [no] ig[nore] | If set, ignores packet truncation errors.
Set po[rt] | Changes the default TCP/UDP DNS name server port to the value specified.
Set q[uerytype] | Changes the type of information query. More information about types can be found in RFC 1035. (The set type command is a synonym for set querytype.)
set [no] rec[urse] | If set, tells the DNS name server to query other servers if it does not have the information.
Set ret[ry] | Sets the number of retries. When a reply to a request is not received within a certain amount of time (changed with set timeout), the timeout period is doubled and the request is resent. The retry value controls how many times a request is re-sent before giving up.
Set ro[ot] | Changes the name of the root server. This affects the root command.
Set [no] sea[rch] | If set and the lookup request contains at least one period but does not end with a trailing period, appends the DNS domain names in the DNS domain search list to the request until an answer is received.
Set srchl[ist] | Changes the default DNS domain name and search list. A maximum of six names separated by slashes (/) can be specified. This command overrides the default DNS domain name and search list of the set domain command. Use the set all command to display the list.
Set ti[meout] | Changes the initial number of seconds to wait for a reply to a request. When a reply to a request is not received within this time period, the timeout is doubled and the request is re-sent. (The number of retries is controlled with the set retry option.)
set ty[pe] | Changes the type of information query. More information about types can be found in RFC 1035. (The set type command is a synonym for set querytype.)
set [no] v[c] | If set, always uses a virtual circuit when sending requests to the server.
view | Sorts and lists the output of previous ls command(s).

References

For in-depth coverage of nslookup, see DNS and BIND by Paul Albitz and Cricket Liu, published by O'Reilly and Associates.


ping

This diagnostic command verifies connections to one or more remote computers.

Syntax

ping [-t] [-a] [-n count] [-l length] [-f] [-i ttl] [-v tos] [-r count] [-s count]
[[-j host-list] | [-k host-list]] [-w timeout] destination-list

Parameters

-t

Pings the specified host until interrupted.

-a

Resolves addresses to host names.

-n count

Sends the number of ECHO packets specified by count. The default is 4.

-l length

Sends ECHO packets containing the amount of data specified by length. The default is 64 bytes; the maximum is 8192.

-f

Sends a Do Not Fragment flag in the packet. The packet will not be fragmented by gateways on the route.

-i ttl

Sets the time to live field to the value specified by ttl.

-v tos

Sets the type of service field to the value specified by tos.

-r count

Records the route of the outgoing packet and the returning packet in the record route field. A minimum of 1 to a maximum of 9 hosts must be specified by count.

-s count

Specifies the timestamp for the number of hops specified by count.

-j host-list

Routes packets via the list of hosts specified by host-list. Consecutive hosts can be separated by intermediate gateways (loose source routed). The maximum number allowed by IP is 9.

-k host-list

Routes packets via the list of hosts specified by host-list. Consecutive hosts cannot be separated by intermediate gateways (strict source routed). The maximum number allowed by IP is 9.

-w timeout

Specifies a timeout interval in milliseconds.

destination-list

Specifies the remote hosts to ping.

Notes

The ping command verifies connections to remote hosts by sending ICMP echo packets to the host and listening for echo reply packets. Ping waits for up to 1 second for each packet sent and prints the number of packets transmitted and received. Each received packet is validated against the transmitted message. By default, four echo packets containing 64 bytes of data (a periodic sequence of uppercase alphabetic characters) are transmitted.

You can use the ping utility to test both the host name and the IP address of the host. If the IP address is verified but the host name is not, you might have a name resolution problem. In this case, be sure that the host name you are querying is in either the local HOSTS file or in the DNS database.

The following shows sample output for ping:

C:\>ping ds.internic.net Pinging ds.internic.net [192.20.239.132] with 32 bytes of data: Reply from 192.20.239.132: bytes=32 time=101ms TTL=243 Reply from 192.20.239.132: bytes=32 time=100ms TTL=243 Reply from 192.20.239.132: bytes=32 time=120ms TTL=243 Reply from 192.20.239.132: bytes=32 time=120ms TTL=243


rcp

This connectivity command copies files between a Window NT computer and a computer running rshd, the remote shell server service or daemon. (A service is called a daemon in UNIX.) The rcp command can also be used for third-party transfer to copy files between two computers running rshd when the command is issued from a Windows NT-based computer. The rshd server service (daemon) is available on UNIX computers, but not on a Windows NT-based computer. The Windows NT-based computer can only participate as the computer from which the commands are issued. The remote computers must also support the rcp utility in addition to running rshd.

Syntax

rcp [-a | -b] [-h] [-r] source1 source2 ... sourceN destination

Parameters

-a

Specifies ASCII transfer mode. This mode converts the carriage return/linefeed characters to carriage returns on outgoing files, and linefeed characters to carriage return/linefeeds for incoming files. This is the default transfer mode.

-b

Specifies binary image transfer mode. No carriage return/linefeed conversion is performed.

-h

Transfers source files marked with the hidden attribute on the Windows NT-based computer. Without this option, specifying a hidden file on the rcp command line has the same effect as if the file did not exist.

-r

Recursively copies the contents of all subdirectories of the source to the destination. Both the source and destination must be directories.

source and destination

Must be of the form [host[.user]:]filename. If the [host[.user]:] portion is omitted, the host is assumed to be the local computer. If the user portion is omitted, the currently logged-on Windows NT user name is used. If a fully qualified host name is used, which contains the period (.) separators, then the [.user] must be included. Otherwise, the last part of the host name is interpreted as the user name. If multiple source files are specified, the destination must be a directory.

If the filename does not begin with a forward slash ( / ) for UNIX computers or a backward slash ( \ ) for Windows NT-based computers, it is assumed to be relative to the current working directory. Under Windows NT, this is the directory from which the command is issued. On the remote computer, it is the logon directory for the remote user. A period (.) means the current directory. Use the escape characters ( \ , ", or ') in remote paths to use wildcard characters on the remote host.

Notes

Remote Privileges

The rcp command does not prompt for passwords; the current or specified user-name must exist on the remote host and enable remote command execution via rcp.

The .rhosts File

The .rhosts file specifies which remote computer or users can assess a local account using rsh or rcp. This file (or a HOSTS equivalent) is required on the remote computer for access to a remote computer using these commands. Rsh and rcp both transmit the local user name to the remote computer. The remote computer uses this name plus the IP address (usually resolved to a host name) or the requesting computer to determine whether access is granted. There is no provision for specifying a password to access an account using these commands.

If the user is logged on to a Windows NT Server domain, the domain controller must be available to resolve the currently logged-on name, because the logged-on name is not cached on the local computer. Because the user name is required as part of the rsh protocol, the command fails if the user name cannot be obtained.

The .rhosts file is a text file where each line is an entry. An entry consists of the local host name, the local user name, and any comments about the entry. Each entry is separated by a tab or space, and comments begin with a hash mark (#),for example:

computer5 marie #This computer is in room 31A

The .rhosts file must be in the user's home directory on the remote computer. (Normally a DNS name server is used instead of the .rhosts file.)

Additionally, have your host name added to the remote computer's /Etc/Hosts file. This enables the remote computer to authenticate remote requests for your computer using the Microsoft TCP/IP utilities.

For more information about a remote computer's specific implementation of the .rhosts file, see the remote computer's documentation

Specifying Hosts

Use the host.user variables to use a user name other than the current user name. If host.user is specified with source, the .rhosts file on the remote host must contain an entry for user.

If a host name is supplied as a full domain name containing periods, a user name must be appended to the host name. This prevents the last element of the domain name from being interpreted as a user name. For example,

rcp domain-name1.user:johnm domain-name2.user:richr

Remote Processing

Remote processing is performed by a command run from the user's logon shell on most UNIX computers. The user's .profile or .cshrc is executed before parsing filenames, and exported shell variables can be used (using the escape characters or quotation marks) in remote filenames.

Copying Files

If you attempt to copy a number of files to a file rather than a directory, only the last file is copied. Also, the rcp command cannot copy a file onto itself.

Examples

These examples show syntax for some common uses of rcp.

To copy a local file to the logon directory of a remote computer:

rcp filename remotecomputer:

To copy a local file to an existing directory and a new filename on a remote computer:

rcp filename remotecomputer:/directory/newfilename

To copy multiple local files to a subdirectory of a remote logon directory:

rcp file1 file2 file3 remotecomputer:subdirectory/filesdirectory

To copy from a remote source to the current directory of the local computer:

rcp remotecomputer:filename

To copy from multiple files from multiple remote sources to a remote destination with different user names:

rcp remote1.user1:file1 remote2.user2:file2 remotedest.destuser:directory

To copy from a remote computer using an IP address to a local computer (where the user name is mandatory because a period is used in the remote host name):

rcp 11.101.12.1.user:filename filename


rexec

This connectivity command runs commands on remote hosts running the rexecd service. Rexec authenticates the user name on the remote host by using a password, before executing the specified command.

Syntax

rexec host [-l username] [-n] command

Parameters

host

Specifies the remote host on which to run command.

-l username

Specifies the user name on the remote host.

-n

Redirects the input of rexec to NUL.

command

Specifies the command to run.

Notes

Rexec prompts the user for a password and authenticates the password on the remote host. If the authentication succeeds, the command is executed.

Rexec copies standard input to the remote command, standard output of the remote command to its standard output, and standard error of the remote command to its standard error. Interrupt, quit, and terminate signals are propagated to the remote command. Rexec normally terminates when the remote command does.

Using Redirection Symbols

Use quotation marks around redirection symbols to redirect onto the remote host. If quotation marks are not used, redirection occurs on the local computer. For example, the following command appends the remote file remotefile to the local file localfile:

rexec otherhost cat remotefile >> localfile

The following command appends the remote file remotefile to the remote file otherremotefile:

rexec otherhost cat remotefile ">>" otherremotefile

Using Interactive Commands

You cannot run most interactive commands. For example, vi or emacs cannot be run using rexec. Use telnet to run interactive commands.


route

This diagnostic command manipulates network routing tables.

Syntax

route [-f] [command [destination] [MASK netmask] [gateway] [METRIC metric]]

Parameters

-f

Clears the routing tables of all gateway entries. If this parameter is used in conjunction with one of the commands, the tables are cleared prior to running the command.

-p

When used with the route add command, makes a route persistent across restarts of the computer. By default, routes are not preserved when the computer is restarted. When used with the route print command, displays the list of registered persistent routes. Ignored for all other commands.

command

Specifies one of four commands.

Command | Purpose
print | Prints a route
add | Adds a route
delete | Deletes a route
change | Modifies an existing route

destination

Specifies the host to send command.

MASK

Specifies, if present, that the next parameter be interpreted as the netmask parameter.

netmask

Specifies, if present, the subnet mask value to be associated with this route entry. If not present, this parameter defaults to 255.255.255.255.

gateway

Specifies the gateway.

METRIC

Specifies the route metric (cost) for the destination.

Notes

The route utility does not accept a subnet mask value of 255.255.255.255 on the command line. To specify a subnet mask with this value, you must accept the default.

On a multihomed computer on which a network is available from more than one adapter card, all network traffic is passed over the first gateway defined. If you add a second gateway to the same network, the entry is added to the route table, but it is never used.

The route utility uses the Networks file to convert destination names to addresses. For the route utility to work correctly, the network numbers in the Networks file must specify all four octets in dotted decimal notation. For example, a network number of 284.122.107 must be specified in the Networks file as 284.122.107.0, with trailing zeroes appended.

All symbolic names used for destination or gateway are looked up in the network and host name database files NETWORKS and HOSTS, respectively. If the command is route print or route delete, wildcards may be used for the destination and gateway, or the gateway argument may be omitted.


rsh

This connectivity command runs commands on remote hosts running the rsh service. For information about the .rhosts file, see the Rcp command.

Syntax

rsh host[-l username] [-n] command

Parameters

host

-l username

Specifies the user name to use on the remote host. If omitted, the logged-on user name is used.

-n

Redirects the input of rsh to NUL.

command

Specifies the command to run.

Notes

Rsh copies standard input to the remote command, standard output of the remote command to its standard output, and the standard error of the remote command to its standard error. Rsh normally terminates when the remote command does.

Using Redirection Symbols

Use quotation marks around redirection symbols to redirect onto the remote host. If quotation marks are not used, redirection occurs on the local computer. For example, the following command appends the remote file remotefile to the local file localfile:

rsh otherhost cat remotefile >> localfile

The following command appends the remote file remotefile to the remote file otherremotefile:

rsh otherhost cat remotefile ">>" otherremotefile

Using Rsh on a Windows NT Server Domain

If the user is logged on to a Windows NT Server domain, the domain controller must be available to resolve the currently logged-on name, because the logged-on name is not cached on the local computer. Because the username is required as part of the rsh protocol, the command fails if the username cannot be obtained.

The .rhosts File

The .rhosts file generally permits network access rights on UNIX computers. The .rhosts file lists computer names and associated logon names that have access to remote computers. When issuing rcp, rexec, or rsh commands to a remote computer with a properly configured .rhosts file, you do not need to provide logon and password information for the remote computer.

The .rhosts file is a text file where each line is an entry. An entry consists of the local computer name, the local user name, and any comments about the entry. Each entry is separated by a tab or space, and comments begin with a hash mark (#), for example:

computer5 marie #This computer is in room 31A

The .rhosts file must be in the user's home directory on the remote computer. For further information about a remote computer's specific implementation of the .rhosts file, see the remote computer's documentation. (Normally a DNS name server is used instead of the .rhosts file.)


telnet

This connectivity command starts terminal emulation with a remote host running a Telnet server service. Telnet provides DEC™ VT 100, DEC VT 52, or TTY emulation, using the connection-based services of TCP.

To provide terminal emulation from a Windows NT computer, the remote host must be running TCP/IP and a Telnet server service. The Windows NT-based Telnet client must also have a user account on the remote Telnet server.

The Telnet client can be started by selecting Telnet from the Accessories program group or by using the command prompt. The syntax and usage for starting the Telnet client from the command prompt is described next. For information about starting the Telnet client by selecting Telnet from the Accessories program group, see online Help.

Note

Windows NT Server and Windows NT Workstation provide the telnet client utility but do not provide a Telnet server service (telnetd), also referred to as the Telnet daemon.

Syntax

telnet [host [port]]

Parameters

hostname

Specifies the host name or IP address of the remote host with which you want to connect.

port

Specifies the remote port you want to connect to. The default value is specified by the telnet entry in the Services file. If no entry exists in the Services file, the default connection port value is decimal 23.


tftp

This connectivity command transfers files to and from a remote computer running the Trivial File Transfer Protocol (TFTP) service. This utility is similar to ftp, but it does not provide user authentication, although the files require read and write UNIX permissions. Tftp can only be used for unidirectional transfer of files.

Syntax

tftp [-i] host [get | put] source [destination]

Parameters

-i

Specifies binary image transfer mode (also called octet). In binary image mode, the file is moved literally byte by byte. Use this mode when transferring binary files.

If -i is omitted, the file is transferred in ASCII mode. This is the default transfer mode. This mode converts the end-of-line (EOL) characters to a carriage return for UNIX and to a carriage return/linefeed for personal computers. Use this mode when transferring text files. If a file transfer is successful, the data transfer rate is displayed.

host

Specifies the local or remote host.

get

Transfers destination on the remote computer to source on the local computer.

Because the TFTP protocol does not support user authentication, the user must be logged on, and the files must be writable on the remote computer.

put

Transfers source on the local computer to destination on the remote computer.

source

Specifies the file to transfer.

destination

Specifies where to transfer the file.


tracert

This diagnostic utility determines the route taken to a destination by sending Internet Control Message Protocol (ICMP) echo packets with varying time-to-live (TTL) values to the destination. Each router along the path is required to decrement the TTL on a packet by at least 1 before forwarding it, so the TTL is effectively a hop count. When the TTL on a packet reaches 0, the router is supposed to send back an ICMP Time Exceeded message to the source computer. Tracert determines the route by sending the first echo packet with a TTL of 1 and incrementing the TTL by 1 on each subsequent transmission until the target responds or the maximum TTL is reached. The route is determined by examining the ICMP Time Exceeded messages sent back by intermediate routers. Notice that some routers silently drop packets with expired TTLs and will be invisible to tracert.

Syntax

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

Parameters

-d

Specifies not to resolve addresses to host names.

-h maximum_hops

Specifies maximum number of hops to search for target.

-j host-list

Specifies loose source route along host-list.

-w timeout

Waits the number of milliseconds specified by timeout for each reply.

target_name

Name of the target host.

C:\>tracert ds.internic.net Tracing route to ds.internic.net [198.49.45.10] over a maximum of 30 hops: 1 <10 ms <10 ms * [131.107.1.100] 2 10 ms <10 ms 10 ms seattle1-gw.nwnet.net [192.80.12.82] 3 * 10 ms 10 ms enss143-enet.nwnet.net [192.35.180.2] 4 20 ms * 10 ms t3-3.seattle-cnss8.t3.ans.net [140.222.88.4] 5 30 ms 30 ms 20 ms t3-0.los-angeles-cnss8.t3.ans.net [140.222.8.1 6 70 ms 70 ms 80 ms t3-0.new-york-cnss24.t3.ans.net [140.222.24.1] 7 80 ms 81 ms 80 ms t3-0.denver-cnss40.t3.ans.net [140.222.40.1] 8 100 ms 91 ms 90 ms t3-1.new-york-cnss32.t3.ans.net [140.222.32.2] 9 90 ms 90 ms 91 ms mf-0.new-york-cnss36.t3.ans.net [140.222.32.196] 10 100 ms 90 ms 91 ms t1-0.enss222.t3.ans.net [140.222.222.1] 11 140 ms 191 ms 100 ms ds.internic.net [198.49.45.10] Trace complete.


Appendix B - Port Reference for MS TCP/IP

In TCP/IP, a port is the mechanism that allows a computer to simultaneously support multiple communication sessions with computers and programs on the network. A port is basically a refinement of an IP address; a computer that receives a packet from the network can further refine the destination of the packet by using a unique port number that is determined when the connection is established. A number of "well known" ports have reserved numbers that correspond to predetermined functions.

This appendix describes the Windows NT Server and Windows NT Workstation default port assignments for TCP/IP and UDP. The Services file controls port assignments used by Windows NT Server and Windows NT Workstation. The Services file is located in the \systemroot\Winnt\System32\Drivers\Etc\Services directory.


Port Assignments for Well Known Ports

Well known services are defined by RFC 1060. The relationship between the well known services and the well known ports is described in this excerpt from RFC 1340 (J. Reynolds and J. Postal, July 1992):

The well known ports are controlled and assigned by the Internet Assigned Numbers Authority (IANA), and on most systems can only be used by system (or root) processes or by programs executed by privileged users.

Ports are used in TCP to name the ends of logical connections that carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port. The contact port is sometimes called the "well known port."

UDP ports are not the same as TCP ports, though to the extent possible, TCP and UDP may use the same port assignments. The UDP specification is defined in RFC 768.

The assigned ports use a small portion of the possible port numbers. For many years, the assigned ports were in the range 0 – 255. Recently, the range for assigned ports managed by the IANA has been expanded to the range
0 – 1023.

The following table describes both TCP and UDP port assignments for well known ports.

Table B.1 Port Assignments for Well Known Ports

Decimal | Keyword | Description
0/tcp, udp |  | Reserved
1/tcp, udp | tcpmux | TCP Port Service Multiplexer
2/tcp, udp | compressnet | Management Utility
3/tcp, udp | compressnet | Compression Process
4/tcp, udp |  | Unassigned
5/tcp, udp | rje | Remote Job Entry
6/tcp, udp |  | Unassigned
7/tcp, udp | echo | Echo
8/tcp, udp |  | Unassigned
9/tcp, udp | discard | Discard; alias=sink null
10/tcp, udp |  | Unassigned
11/udp | systat | Active Users; alias=users
12/tcp, udp |  | Unassigned
13/tcp, udp | daytime | Daytime
14/tcp, udp |  | Unassigned
15/tcp, udp |  | Unassigned [was netstat]
16/tcp, udp |  | Unassigned
17/tcp, udp | qotd | Quote of the Day; alias=quote
18/tcp, udp | msp | Message Send Protocol
19/tcp, udp | chargen | Character Generator; alias=ttytst source
20/tcp, udp | ftp-data | File Transfer [Default Data]
21/tcp, udp | ftp | File Transfer [Control], connection dialog
22/tcp, udp |  | Unassigned
23/tcp, udp | telnet | Telnet
24/tcp, udp |  | Any private mail system
25/tcp, udp | smtp | Simple Mail Transfer; alias=mail
26/tcp, udp |  | Unassigned
27/tcp, udp | nsw-fe | NSW User System FE
28/tcp, udp |  | Unassigned
29/tcp, udp | msg-icp | MSG ICP
30/tcp, udp |  | Unassigned
31/tcp, udp | msg-auth | MSG Authentication
32/tcp, udp |  | Unassigned
33/tcp, udp | dsp | Display Support Protocol
34/tcp, udp |  | Unassigned
35/tcp, udp |  | Any private printer server
36/tcp, udp |  | Unassigned
37/tcp, udp | time | Time; alias=timeserver
38/tcp, udp |  | Unassigned
39/tcp, udp | rlp | Resource Location Protocol; alias=resource
40/tcp, udp |  | Unassigned
41/tcp, udp | graphics | Graphics
42/tcp, udp | nameserver | Host Name Server; alias=nameserver
43/tcp, udp | nicname | Who Is; alias=nicname
44/tcp, udp | mpm-flags | MPM FLAGS Protocol
45/tcp, udp | mpm | Message Processing Module
46/tcp, udp | mpm-snd | MPM [default send]
47/tcp, udp | ni-ftp | NI FTP
48/tcp, udp |  | Unassigned
49/tcp, udp | login | Login Host Protocol
50/tcp, udp | re-mail-ck | Remote Mail Checking Protocol
51/tcp, udp | la-maint | IMP Logical Address Maintenance
52/tcp, udp | xns-time | XNS Time Protocol
53/tcp, udp | domain | Domain Name Server
54/tcp, udp | xns-ch | XNS Clearinghouse
55/tcp, udp | isi-gl | ISI Graphics Language
56/tcp, udp | xns-auth | XNS Authentication
57/tcp, udp |  | Any private terminal access
58/tcp, udp | xns-mail | XNS Mail
59/tcp, udp |  | Any private file service
60/tcp, udp |  | Unassigned
61/tcp, udp | ni-mail | NI MAIL
62/tcp, udp | acas | ACA Services
63/tcp, udp | via-ftp | VIA Systems - FTP
64/tcp, udp | covia | Communications Integrator (CI)
65/tcp, udp | tacacs-ds | TACACS-Database Service
66/tcp, udp | sql*net | Oracle SQL*NET
67/tcp, udp | bootpc | DHCP/BOOTP Protocol Server
68/tcp, udp | bootpc | DHCP/BOOTP Protocol Server
69/ udp | tftp | Trivial File Transfer
70/tcp, udp | gopher | Gopher
71/tcp, udp | netrjs-1 | Remote Job Service
72/tcp, udp | netrjs-2 | Remote Job Service
73/tcp, udp | netrjs-3 | Remote Job Service
74/tcp, udp | netrjs-4 | Remote Job Service
75/udp |  | Any private dial out service
76/tcp, udp |  | Unassigned
77/tcp, udp |  | Any private RJE service
78/tcp, udp | vettcp | Vettcp
79/tcp, udp | finger | Finger
80/tcp, udp | www | World Wide Web HTTP
81/tcp, udp | hosts2-ns | HOSTS2 Name Server
82/tcp, udp | xfer | XFER Utility
83/tcp, udp | mit-ml-dev | MIT ML Device
84/tcp, udp | ctf | Common Trace Facility
85/tcp, udp | mit-ml-dev | MIT ML Device
86/tcp, udp | mfcobol | Micro Focus Cobol
87/tcp, udp |  | Any private terminal link; alias=ttylink
88/tcp, udp | kerberos | Kerberos
89/tcp | su-mit-tg | SU/MIT Telnet Gateway
89/udp | su-mit-tg | SU/MIT Telnet Gateway
90/tcp, udp |  | DNSIX Security Attribute Token Map
91/tcp, udp | mit-dov | MIT Dover Spooler
92/tcp, udp | npp | Network Printing Protocol
93/tcp, udp | dcp | Device Control Protocol
94/tcp, udp | objcall | Tivoli Object Dispatcher
95/tcp, udp | supdup | SUPDUP
96/tcp, udp | dixie | DIXIE Protocol Specification
97/tcp, udp | swift-rvf | Swift Remote Virtual File Protocol
98/tcp, udp | tacnews | TAC News
99/tcp, udp | metagram | Metagram Relay
100/tcp | newacct | [unauthorized use]
101/tcp, udp | hostname | NIC Host Name Server; alias=hostname
102/tcp, udp | iso-tsap | ISO-TSAP
103/tcp, udp | gppitnp | Genesis Point-to-Point Trans Net; alias=webster
104/tcp, udp | acr-nema | ACR-NEMA Digital Imag. & Comm. 300
105/tcp, udp | csnet-ns | Mailbox Name Nameserver
106/tcp, udp | 3com-tsmux | 3COM-TSMUX
107/tcp, udp | rtelnet | Remote Telnet Service
108/tcp, udp | snagas | SNA Gateway Access Server
109/tcp, udp | pop2 | Post Office Protocol - Version 2; alias=postoffice
110/tcp, udp | pop3 | Post Office Protocol - Version 3; alias=postoffice
111/tcp, udp | sunrpc | SUN Remote Procedure Call
112/tcp, udp | mcidas | McIDAS Data Transmission Protocol
113/tcp, udp | auth | Authentication Service; alias=authentication
114/tcp, udp | audionews | Audio News Multicast
115/tcp, udp | sftp | Simple File Transfer Protocol
116/tcp, udp | ansanotify | ANSA REX Notify
117/tcp, udp | uucp-path | UUCP Path Service
118/tcp, udp | sqlserv | SQL Services
119/tcp, udp | nntp | Network News Transfer Protocol; alias=usenet
120/tcp, udp | cfdptkt | CFDPTKT
121/tcp, udp | erpc | Encore Expedited Remote Pro.Call
122/tcp, udp | smakynet | SMAKYNET
123/tcp, udp | ntp | Network Time Protocol; alias=ntpd ntp
124/tcp, udp | ansatrader | ANSA REX Trader
125/tcp, udp | locus-map | Locus PC-Interface Net Map Server
126/tcp, udp | unitary | Unisys Unitary Login
127/tcp, udp | locus-con | Locus PC-Interface Conn Server
128/tcp, udp | gss-xlicen | GSS X License Verification
129/tcp, udp | pwdgen | Password Generator Protocol
130/tcp, udp | cisco-fna | Cisco FNATIVE
131/tcp, udp | cisco-tna | Cisco TNATIVE
132/tcp, udp | cisco-sys | Cisco SYSMAINT
133/tcp, udp | statsrv | Statistics Service
134/tcp, udp | ingres-net | INGRES-NET Service
135/tcp, udp | loc-srv | Location Service
136/tcp, udp | profile | PROFILE Naming System
137/tcp, udp | netbios-ns | NetBIOS Name Service
138/tcp, udp | netbios-dgm | NetBIOS Datagram Service
139/tcp, udp | netbios-ssn | NetBIOS Session Service
140/tcp, udp | emfis-data | EMFIS Data Service
141/tcp, udp | emfis-cntl | EMFIS Control Service
142/tcp, udp | bl-idm | Britton-Lee IDM
143/tcp, udp | imap2 | Interim Mail Access Protocol v2
144/tcp, udp | news | NewS; alias=news
145/tcp, udp | uaac | UAAC Protocol
146/tcp, udp | iso-ip0 | ISO-IP0
147/tcp, udp | iso-ip | ISO-IP
148/tcp, udp | cronus | CRONUS-SUPPORT
149/tcp, udp | aed-512 | AED 512 Emulation Service
150/tcp, udp | sql-net | SQL-NET
151/tcp, udp | hems | HEMS
152/tcp, udp | bftp | Background File Transfer Program
153/tcp, udp | sgmp | SGMP; alias=sgmp
154/tcp, udp | netsc-prod | Netscape
155/tcp, udp | netsc-dev | Netscape
156/tcp, udp | sqlsrv | SQL Service
157/tcp, udp | knet-cmp | KNET/VM Command/Message Protocol
158/tcp, udp | pcmail-srv | PCMail Server; alias=repository
159/tcp, udp | nss-routing | NSS-Routing
160/tcp, udp | sgmp-traps | SGMP-TRAPS
161/tcp, udp | snmp | SNMP; alias=snmp
162/tcp, udp | snmptrap | SNMPTRAP
163/tcp, udp | cmip-man | CMIP/TCP Manager
164/tcp, udp | cmip-agent | CMIP/TCP Agent
165/tcp, udp | xns-courier | Xerox
166/tcp, udp | s-net | Sirius Systems
167/tcp, udp | namp | NAMP
168/tcp, udp | rsvd | RSVD
169/tcp, udp | send | SEND
170/tcp, udp | print-srv | Network PostScript
171/tcp, udp | multiplex | Network Innovations Multiplex
172/tcp, udp | cl/1 | Network Innovations CL/1
173/tcp, udp | xyplex-mux | Xyplex
174/tcp, udp | mailq | MAILQ
175/tcp, udp | vmnet | VMNET
176/tcp, udp | genrad-mux | GENRAD-MUX
177/tcp, udp | xdmcp | X Display Manager Control Protocol
178/tcp, udp | nextstep | NextStep Window Server
179/tcp, udp | bgp | Border Gateway Protocol
180/tcp, udp | ris | Intergraph
181/tcp, udp | unify | Unify
182/tcp, udp | audit | Unisys Audit SITP
183/tcp, udp | ocbinder | OCBinder
184/tcp, udp | ocserver | OCServer
185/tcp, udp | remote-kis | Remote-KIS
186/tcp, udp | kis | KIS Protocol
187/tcp, udp | aci | Application Communication Interface
188/tcp, udp | mumps | Plus Five's MUMPS
189/tcp, udp | qft | Queued File Transport
190/tcp, udp | gacp | Gateway Access Control Protocol
191/tcp, udp | prospero | Prospero
192/tcp, udp | osu-nms | OSU Network Monitoring System
193/tcp, udp | srmp | Spider Remote Monitoring Protocol
194/tcp, udp | irc | Internet Relay Chat Protocol
195/tcp, udp | dn6-nlm-aud | DNSIX Network Level Module Audit
196/tcp, udp | dn6-smm-red | DNSIX Session Mgt Module Audit Redir
197/tcp, udp | dls | Directory Location Service
198/tcp, udp | dls-mon | Directory Location Service Monitor
199/tcp, udp | smux | SMUX
200/tcp, udp | src | IBM System Resource Controller
201/tcp, udp | at-rtmp | AppleTalk Routing Maintenance
202/tcp, udp | at-nbp | AppleTalk Name Binding
203/tcp, udp | at-3 | AppleTalk Unused
204/tcp, udp | at-echo | AppleTalk Echo
205/tcp, udp | at-5 | AppleTalk Unused
206/tcp, udp | at-zis | AppleTalk Zone Information
207/tcp, udp | at-7 | AppleTalk Unused
208/tcp, udp | at-8 | AppleTalk Unused
209/tcp, udp | tam | Trivial Authenticated Mail Protocol
210/tcp, udp | z39.50 | ANSI Z39.50
211/tcp, udp | 914c/g | Texas Instruments 914C/G Terminal
212/tcp, udp | anet | ATEXSSTR
213/tcp, udp | ipx | IPX
214/tcp, udp | vmpwscs | VM PWSCS
215/tcp, udp | softpc | Insignia Solutions
216/tcp, udp | atls | Access Technology License Server
217/tcp, udp | dbase | dBASE UNIX
218/tcp, udp | mpp | Netix Message Posting Protocol
219/tcp, udp | uarps | Unisys ARPs
220/tcp, udp | imap3 | Interactive Mail Access Protocol v3
221/tcp, udp | fln-spx | Berkeley rlogind with SPX auth
222/tcp, udp | fsh-spx | Berkeley rshd with SPX auth
223/tcp, udp | cdc | Certificate Distribution Center
224-241 |  | Reserved
243/tcp, udp | sur-meas | Survey Measurement
245/tcp, udp | link | LINK
246/tcp, udp | dsp3270 | Display Systems Protocol
247-255 |  | Reserved
345/tcp, udp | pawserv | Perf Analysis Workbench
346/tcp, udp | zserv | Zebra server
347/tcp, udp | fatserv | Fatmen Server
371/tcp, udp | clearcase | Clearcase
372/tcp, udp | ulistserv | UNIX Listserv
373/tcp, udp | legent-1 | Legent Corporation
374/tcp, udp | legent-2 | Legent Corporation
512/tcp | print | Windows NT Server and Windows NT Workstation version 4.0 can send LPD client print jobs from any available reserved port between 512 and 1023. See also description for ports 721 to 731.
512/udp | biff | Used by mail system to notify users of new mail received; currently receives messages only from processes on the same computer; alias=comsat
513/tcp | login | Remote logon like telnet; automatic authentication performed, based on privileged port numbers and distributed databases that identify "authentication domains"
513/udp | who | Maintains databases showing who's logged on to the computers on a local net and the load average of the computer; alias=whod
514/tcp | cmd | Like exec, but automatic authentication is performed as for logon server
514/udp | syslog |
515/tcp, udp | printer | Spooler; alias=spooler. The print server LPD service will listen on tcp port 515 for incoming connections.
517/tcp, udp | talk | Like tenex link, but across computers; unfortunately, doesn't use link protocol (this is actually just a rendezvous port from which a TCP connection is established)
518/tcp, udp | ntalk |
519/tcp, udp | utime | Unixtime
520/tcp | efs | Extended file name server
520/udp | router | Local routing process (on site); uses variant of Xerox NS routing information protocol;alias=router routed
525/tcp, udp | timed | Timeserver
526/tcp, udp | tempo | Newdate
530/tcp, udp | courier | RPC
531/tcp | conference | Chat
531/udp | rvd-control | MIT disk
532/tcp, udp | netnews | Readnews
533/tcp, udp | netwall | For emergency broadcasts
540/tcp, udp | uucp | Uucpd
543/tcp, udp | klogin |
544/tcp, udp | kshell | Krcmd; alias=cmd
550/tcp, udp | new-rwho | New-who
555/tcp, udp | dsf |
556/tcp, udp | remotefs | Rfs server; alias=rfs_server rfs
560/tcp, udp | rmonitor | Rmonitord
561/tcp, udp | monitor |
562/tcp, udp | chshell | Chcmd
564/tcp, udp | 9pfs | Plan 9 file service
565/tcp, udp | whoami | Whoami
570/tcp, udp | meter | Demon
571/tcp, udp | meter | Udemon
600/tcp, udp | ipcserver | Sun IPC server
607/tcp, udp | nqs | Nqs
666/tcp, udp | mdqs |
704/tcp, udp | elcsd | Errlog copy/server daemon
721-731/tcp | printer | Under Windows NT 3.5x, all TCP/IP print jobs sent from a Windows NT computer were sourced from TCP ports 721 through 731. This is changed for Windows NT Server and Windows NT Workstation version 4.0, which sources LPD client print jobs from any available reserved port between 512 and 1023.
740/tcp, udp | netcp | NETscout Control Protocol
741/tcp, udp | netgw | NetGW
742/tcp, udp | netrcs | Network based Rev. Cont. Sys.
744/tcp, udp | flexlm | Flexible License Manager
747/tcp, udp | fujitsu-dev | Fujitsu Device Control
748/tcp, udp | ris-cm | Russell Info Sci Calendar Manager
749/tcp, udp | kerberos-adm | Kerberos administration
750/tcp | rfile | Kerberos authentication; alias=kdc
750/udp | loadav |
751/tcp, udp | pump | Kerberos authentication
752/tcp, udp | qrh | Kerberos password server
753/tcp, udp | rrh | Kerberos userreg server
754/tcp, udp | tell | Send; Kerberos slave propagation
758/tcp, udp | nlogin |
759/tcp, udp | con |
760/tcp, udp | ns |
761/tcp, udp | rxe |
762/tcp, udp | quotad |
763/tcp, udp | cycleserv |
764/tcp, udp | omserv |
765/tcp, udp | webster |
767/tcp, udp | phonebook | Phone
769/tcp, udp | vid |
770/tcp, udp | cadlock |
771/tcp, udp | rtip |
772/tcp, udp | cycleserv2 |
773/tcp | submit |
773/udp | notify |
774/tcp | rpasswd |
774/udp | acmaint_dbd |
775/tcp | entomb |
775/udp | acmaint_transd |
776/tcp, udp | wpages |
780/tcp, udp | wpgs |
781/tcp, udp | hp-collector | HP performance data collector
782/tcp, udp | hp-managed-node | HP performance data managed node
783/tcp, udp | hp-alarm-mgr | HP performance data alarm manager
800/tcp, udp | mdbs_daemon |
801/tcp, udp | device |
888/tcp | erlogin | Logon and environment passing
996/tcp, udp | xtreelic | XTREE License Server
997/tcp, udp | maitrd |
998/tcp | busboy |
998/udp | puparp |
999/tcp | garcon |
999/udp | applix | Applix ac
999/tcp, udp | puprouter |
1000/tcp | cadlock |
1000/udp | ock |


Port Assignments for Registered Ports

The registered ports are not controlled by the IANA and on most systems can be used by user processes or programs. Registered ports between 1024 and 5000 are also referred to as the ephemeral ports. Although the IANA cannot control uses of these ports, it does register or list uses of these ports as a convenience to the TCP/IP community. To the extent possible, these same port assignments are used with UDP. The registered ports are in the range 1024 – 65535.

This list specifies the port used by the Windows NT Server and Windows NT Workstation server process as its contact port for services and third-party software.

Note

Programs that use Remote Procedure Call (RPC) to communicate can randomly select a registered port above 1024.

Table B.2 Port Assignments for Registered Ports

Decimal |  | Keyword | Description
1024 |  |  | Reserved
1025/tcp, udp | blackjack |  | Network blackjack
1109/tcp | kpop |  | Pop with Kerberos
1167/udp | phone |  |
1248/tcp, udp | hermes |  |
1347/tcp, udp | bbn-mmc |  | Multimedia conferencing
1348/tcp, udp | bbn-mmx |  | Multimedia conferencing
1349/tcp, udp | sbook |  | Registration Network Protocol
1350/tcp, udp | editbench |  | Registration Network Protocol
1351/tcp, udp | equationbuilder |  | Digital Tool Works (MIT)
1352/tcp, udp | lotusnote |  | Lotus Note
1512/tcp, udp | WINS |  | Reserved for future use for Microsoft Windows Internet Name Service
1524/tcp, udp | ingreslock |  | Ingres
1525/tcp, udp | orasrv |  | Oracle
1525/tcp, udp | prospero-np |  | Prospero nonprivileged
1527/tcp, udp | tlisrv |  | Oracle
1529/tcp, udp | coauthor |  | Oracle
1600/tcp, udp | issd |  |
1650/tcp, udp | nkd |  |
1666/udp | maze |  |
2000/tcp, udp | callbook |  |
2001/tcp | dc |  |
2001/udp | wizard |  | Curry
2002/tcp, udp | globe |  |
2004/tcp | mailbox |  |
2004/udp | emce |  | CCWS mm conf
2005/tcp | berknet |  |
2005/udp | oracle |  |
2006/tcp | invokator |  |
2006/udp | raid-cc |  | RAID
2007/tcp | dectalk |  |
2007/udp | raid-am |  |
2008/tcp | conf |  |
2008/udp | terminaldb |  |
2009/tcp | news |  |
2009/udp | whosockami |  |
2010/tcp | search |  |
2010/udp | pipe_server |  |
2011/tcp | raid-cc |  | RAID
2011/udp | servserv |  |
2012/tcp | ttyinfo |  |
2012/udp | raid-ac |  |
2013/tcp | raid-am |  |
2013/udp | raid-cd |  |
2014/tcp | troff |  |
2014/udp | raid-sf |  |
2015/tcp | cypress |  |
2015/udp | raid-cs |  |
2016/tcp, udp | bootserver |  |
2017/tcp | cypress-stat |  |
2017/udp | bootclient |  |
2018/tcp | terminaldb |  |
2018/udp | rellpack |  |
2019/tcp | whosockami |  |
2019/udp | about |  |
2020/tcp, udp | xinupageserver |  |
2021/tcp | servexec |  |
2021/udp | xinuexpansion1 |  |
2022/tcp | down |  |
2022/udp | xinuexpansion2 |  |
2023/tcp, udp | xinuexpansion3 |  |
2024/tcp, udp | xinuexpansion4 |  |
2025/tcp | ellpack |  |
2025/udp | xribs |  |
2026/tcp, udp | scrabble |  |
2027/tcp, udp | shadowserver |  |
2028/tcp, udp | submitserver |  |
2030/tcp, udp | device2 |  |
2032/tcp, udp | blackboard |  |
2033/tcp, udp | glogger |  |
2034/tcp, udp | scoremgr |  |
2035/tcp, udp | imsldoc |  |
2038/tcp, udp | objectmanager |  |
2040/tcp, udp | lam |  |
2041/tcp, udp | interbase |  |
2042/tcp, udp | isis |  |
2043/tcp, udp | isis-bcast |  |
2044/tcp, udp | rimsl |  |
2045/tcp, udp | cdfunc |  |
2046/tcp, udp | sdfunc |  |
2047/tcp, udp | dls |  |
2048/tcp, udp | dls-monitor |  |
2049/tcp, udp | shilp |  | Sun NFS
2053/tcp | knetd |  | Kerberos de-multiplexer
2105/tcp | eklogin |  | Kerberos encrypted rlogon
2784/tcp, udp | www-dev |  | World Wide Web - development
3049/tcp, udp | NSWS |  |
4672/tcp, udp | rfa |  | Remote file access server
5000/tcp, udp | commplex-main |  |
5001/tcp, udp | commplex-link |  |
5002/tcp, udp | rfe |  | Radio Free Ethernet
5145/tcp, udp | rmonitor_secure |  |
5236/tcp, udp | padl2sim |  |
5555/tcp | rmt |  | Rmtd
5556/tcp | mtb |  | Mtbd (mtb backup)
6111/tcp, udp | sub-process |  | HP SoftBench Sub-Process Control
6558/tcp, udp | xdsxdm |  |
7000/tcp, udp | afs3-fileserver |  | File server itself
7001/tcp, udp | afs3-callback |  | Callbacks to cache managers
7002/tcp, udp | afs3-prserver |  | Users and groups database
7003/tcp, udp | afs3-vlserver |  | Volume location database
7004/tcp, udp | afs3-kaserver |  | AFS/Kerberos authentication service
7005/tcp, udp | afs3-volser |  | Volume management server
7006/tcp, udp | afs3-errors |  | Error interpretation service
7007/tcp, udp | afs3-bos |  | Basic overseer process
7008/tcp, udp | afs3-update |  | Server-to-server updater
7009/tcp, udp | afs3-rmtsys |  | Remote cache manager service
9535/tcp, udp | man |  | Remote man server
9536/tcp | w |  |
9537/tcp | mantst |  | Remote man server, testing
10000/tcp | bnews |  |
10000/udp | rscs0 |  |
10001/tcp | queue |  |
10001/udp | rscs1 |  |
10002/tcp | poker |  |
10002/udp | rscs2 |  |
10003/tcp | gateway |  |
10003/udp | rscs3 |  |
10004/tcp | remp |  |
10004/udp | rscs4 |  |
10005/udp | rscs5 |  |
10006/udp | rscs6 |  |
10007/udp | rscs7 |  |
10008/udp | rscs8 |  |
10009/udp | rscs9 |  |
10010/udp | rscsa |  |
10011/udp | rscsb |  |
10012/tcp | qmaster |  |
10012/udp | qmaster |  |
17007/tcp, udp | isode-dua |  |


Appendix C - MIB Object Types for Windows NT

This appendix provides the managed-objects definitions contained in the following Windows NT-based MIBs:

  • LAN Manager MIB-II for Windows NT
  • Microsoft DHCP Server MIB
  • Microsoft WINS Server MIB
  • Microsoft Internet Information Server MIB
    • Microsoft FTP Server MIB
    • Microsoft Gopher Server MIB
    • Microsoft HTTP Server MIB

Note

The Internet standards for Structure of Management Information (SMI) and MIB-II object types are defined in RFC 1155 and RFC 1213. Refer to those documents for definitions of the objects contained within SMI and MIB-II.

This appendix assumes that you are familiar with network management, TCP/IP, and SNMP. It also assumes that you are familiar with the concept of a management information base (MIB). If you are not familiar with TCP/IP or the Internet MIB-II, see Internetworking with TCP/IP by Douglas E. Comer (Prentice Hall, 1991) and The Simple Book by Marshall T. Rose (Prentice Hall, 1991).


LAN Manager MIB II for Windows NT

This MIB is documented in "LAN Manager 2.0 Management Information Base, LAN Manager MIB Working Group, Internet Draft: LanMgr-Mib-II" by Microsoft. The object definitions for this MIB are contained in the file named Lmmib2.mib.

The Windows NT implementation currently does not support the following objects:

  • svSesNumConns
  • svAuditLogSize
  • wkstaErrorLogSize
  • domLogonDomain

    LanMgr-Mib-II-MIB DEFINITIONS ::= BEGIN IMPORTS
    enterprises, OBJECT-TYPE, Counter
    FROM RFC1155-SMI
    DisplayString
    FROM RFC1213-MIB; lanmanager OBJECT IDENTIFIER ::= { enterprises 77 }
    lanmgr-2 OBJECT IDENTIFIER ::= { lanmanager 1 }
    lanmgr-2 Tree common OBJECT IDENTIFIER ::= { lanmgr-2 1 }
    server OBJECT IDENTIFIER ::= { lanmgr-2 2 }
    workstation OBJECT IDENTIFIER ::= { lanmgr-2 3 }
    domain OBJECT IDENTIFIER ::= { lanmgr-2 4 } Common Group comVersionMaj OBJECT-TYPE
    SYNTAX OCTET STRING
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The major release version number of the software."
    ::= { common 1 } comVersionMin OBJECT-TYPE
    SYNTAX OCTET STRING
    ACCESS read-only STATUS mandatory
    DESCRIPTION
    "The minor release version number of the software."
    ::= { common 2 } comType OBJECT-TYPE
    SYNTAX OCTET STRING
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The type of LAN Manager software this system is running.
    If no server is running, the node is a workstation. This
    object type is an octet string of length 4 treated as a bitmap
    (with the least significant bit being bit 0): OCTET 1 Software Type Bit
    - -
    workstation 0
    server 1
    sqlserver 2
    Primary DC 3
    Backup DC 4
    Time Source 5
    AFP Server 6 Netware Server 7 OCTET 2 undefined OCTET 3 undefined OCTET 4 undefined"
    ::= { common 3 } comStatStart OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The time, represented as seconds since January 1, 1970, at
    which the statistics on this node were last cleared."
    ::= { common 4 } comStatNumNetIOs OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of network I/O operations submitted on this node."
    ::= { common 5 } comStatFiNetIOs OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of network I/O operations on this node that failed
    issue."
    ::= { common 6 } comStatFcNetIOs OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of network I/O operations on this node that failed
    completion."
    ::= { common 7 } The Server Group svDescription OBJECT-TYPE
    SYNTAX DisplayString (SIZE (0..255))
    ACCESS read-write
    STATUS mandatory
    DESCRIPTION
    "A comment describing this server."
    ::= { server 1 } svSvcNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of network services installed on this server."
    ::= { server 2 } svSvcTable OBJECT-TYPE
    SYNTAX SEQUENCE OF SvSvcEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "A list of service entries describing network services installed
    on this server."
    ::= { server 3 } svSvcEntry OBJECT-TYPE
    SYNTAX SvSvcEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "The names of the network services installed on this server."
    INDEX { svSvcName }
    ::= { svSvcTable 1 }
    SvSvcEntry ::= SEQUENCE {
    svSvcName
    DisplayString,
    svSvcInstalledState
    INTEGER,
    svSvcOperatingState
    INTEGER,
    svSvcCanBeUninstalled
    INTEGER,
    svSvcCanBePaused
    INTEGER
    } svSvcName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..15))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the network service described by this entry."
    ::= { svSvcEntry 1 } svSvcInstalledState OBJECT-TYPE
    SYNTAX
    INTEGER {
    uninstalled(1),
    install-pending(2),
    uninstall-pending(3),
    installed(4)
    }
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The installation status of the network service specified by
    this entry."
    ::= { svSvcEntry 2 } svSvcOperatingState OBJECT-TYPE
    SYNTAX
    INTEGER {
    active(1),
    continue-pending(2),
    pause-pending(3),
    paused(4)
    }
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The operating status of the network service specified by
    this entry."
    ::= { svSvcEntry 3 } svSvcCanBeUninstalled OBJECT-TYPE
    SYNTAX
    INTEGER {
    cannot-be-uninstalled(1),
    can-be-uninstalled(2)
    } ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "Whether or not the network service specified by this entry
    can be uninstalled."
    ::= { svSvcEntry 4 } svSvcCanBePaused OBJECT-TYPE
    SYNTAX
    INTEGER {
    cannot-be-paused(1),
    can-be-paused(2)
    }
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "Whether or not the network service specified by this entry
    can be paused."
    ::= { svSvcEntry 5 } svStatOpens OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The total number of files that have been opened on the server."
    ::= { server 4 } svStatDevOpens OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The total number of communication devices opened on the server."
    ::= { server 5 } svStatQueuedJobs OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The total number of print jobs that have been spooled on the
    server."
    ::= { server 6 } svStatSOpens OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of sessions that have been started on the server."
    ::= { server 7 } svStatErrorOuts OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of sessions disconnected due to an error on the
    server."
    ::= { server 8 } svStatPwErrors OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of password violations encountered on the server."
    ::= { server 9 } svStatPermErrors OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of access permission violations encountered on this
    server."
    ::= { server 10 } svStatSysErrors OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of system errors encountered on the server."
    ::= { server 11 } svStatSentBytes OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of bytes sent by the server."
    ::= { server 12 } svStatRcvdBytes OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of bytes received by this server."
    ::= { server 13 } svStatAvResponse OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The mean number of milliseconds it has taken this server
    to process a workstation I/O request."
    ::= { server 14 } svSecurityMode OBJECT-TYPE
    SYNTAX
    INTEGER {
    share-level(1),
    user-level(2)
    }
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The type of security being run at this server."
    ::= { server 15 } svUsers OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of concurrent users this server is able to support."
    ::= { server 16 } svStatReqBufsNeeded OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of times the server has needed a request buffer in
    the process of handling a client request and could not allocate
    one."
    ::= { server 17 } svStatBigBufsNeeded OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of times the server has needed a big buffer in the
    process of handling a client request and could not allocate one."
    ::= { server 18 } svSessionNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of sessions clients have established to this server."
    ::= { server 19 } svSessionTable OBJECT-TYPE
    SYNTAX SEQUENCE OF SvSessionEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "A list of session entries corresponding to the current sessions
    clients have with this server."
    ::= { server 20 } svSessionEntry OBJECT-TYPE
    SYNTAX SvSessionEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "A session that is currently established to this server."
    INDEX { svSesClientName, svSesUserName }
    ::= { svSessionTable 1 } SvSessionEntry ::= SEQUENCE {
    svSesClientName
    DisplayString,
    svSesUserName
    DisplayString,
    svSesNumConns
    INTEGER,
    svSesNumOpens
    INTEGER,
    svSesTime
    Counter,
    svSesIdleTime
    Counter,
    svSesClientType
    INTEGER,
    svSesState
    INTEGER
    } svSesClientName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..15))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the remote machine that has established the session."
    ::= { svSessionEntry 1 } svSesUserName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..20))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the user at the remote machine that established the
    session."
    ::= { svSessionEntry 2 } svSesNumConns OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of connections to server resources currently active
    across this session."
    ::= { svSessionEntry 3 } svSesNumOpens OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of files, devices, and pipes that are open on this
    session."
    ::= { svSessionEntry 4 } svSesTime OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The length of time in seconds this session has been established."
    ::= { svSessionEntry 5 } svSesIdleTime OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The length of time in seconds this session has been idle."
    ::= { svSessionEntry 6 }
    svSesClientType OBJECT-TYPE
    SYNTAX INTEGER {
    down-level(1),
    dos-lm(2),
    dos-lm-2(3),
    os2-lm-1(4),
    os2-lm-2(5),
    dos-lm-2-1(6),
    os2-lm-2-1(7),
    afp-1-1(8),
    afp-2-0(9),
    nt-3-1(10)
    }
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The type of client that established the session."
    ::= { svSessionEntry 7 } svSesState OBJECT-TYPE
    SYNTAX INTEGER {
    active(1),
    deleted(2)
    }
    ACCESS read-write
    STATUS mandatory
    DESCRIPTION
    "Used to indicate the state of this session.
    The deleted state will never be returned on a
    session but can be used in set requests to delete
    a session."
    ::= { svSessionEntry 8 } svAutoDisconnects OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of sessions that the server has
    auto-disconnected due to timeout."
    ::= { server 21 } svDisConTime OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-write
    STATUS mandatory
    DESCRIPTION
    "The number of seconds the server waits before
    disconnecting an idle session. A value of 0xffff
    indicates that idle sessions will never be disconnected."
    ::= { server 22 } svAuditLogSize OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-write
    STATUS mandatory
    DESCRIPTION
    "The maximum size in kilobytes that the server's audit
    log can attain."
    ::= { server 23 } svUserNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of users that have accounts on this server."
    ::= { server 24 } svUserTable OBJECT-TYPE
    SYNTAX SEQUENCE OF SvUserEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "The table of active user accounts on this server."
    ::= { server 25 } svUserEntry OBJECT-TYPE
    SYNTAX SvUserEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "One of the user accounts on this server."
    INDEX { svUserName }
    ::= { svUserTable 1 } SvUserEntry ::= SEQUENCE {
    svUserName
    DisplayString
    } svUserName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..20))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the user account."
    ::= { svUserEntry 1 } svShareNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of shared resources on this server."
    ::= { server 26 } svShareTable OBJECT-TYPE
    SYNTAX SEQUENCE OF SvShareEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "The table of shares on this server."
    ::= { server 27 } svShareEntry OBJECT-TYPE
    SYNTAX SvShareEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "A table entry corresponding to a single share on this server."
    INDEX { svShareName }
    ::= { svShareTable 1 } SvShareEntry ::= SEQUENCE {
    svShareName
    DisplayString ,
    svSharePath
    DisplayString ,
    svShareComment
    DisplayString
    }
    svShareName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..12))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the share."
    ::= { svShareEntry 1 } svSharePath OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..255))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The local name of this shared resource."
    ::= { svShareEntry 2 } svShareComment OBJECT-TYPE
    SYNTAX DisplayString (SIZE (0..255))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "A comment associated with this share."
    ::= { svShareEntry 3 } svPrintQNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of print queues on this server."
    ::= { server 28 } svPrintQTable OBJECT-TYPE
    SYNTAX SEQUENCE OF SvPrintQEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "The table of print queues on this server."
    ::= { server 29 } svPrintQEntry OBJECT-TYPE
    SYNTAX SvPrintQEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "A table entry corresponding to a single print queue on this
    server."
    INDEX { svPrintQName }
    ::= { svPrintQTable 1 } SvPrintQEntry ::= SEQUENCE {
    svPrintQName
    DisplayString ,
    svPrintQNumJobs
    INTEGER
    }
    svPrintQName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..12))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the print queue."
    ::= { svPrintQEntry 1 } svPrintQNumJobs OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of jobs currently in this print queue."
    ::= { svPrintQEntry 2 } The Workstation Group
    wkstaStatSessStarts OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of sessions that this workstation has initiated."
    ::= { workstation 1 } wkstaStatSessFails OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of failed sessions that this workstation has
    experienced."
    ::= { workstation 2 } wkstaStatUses OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of connections this workstation has initiated."
    ::= { workstation 3 } wkstaStatUseFails OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of failed connections this workstation has
    experienced."
    ::= { workstation 4 } wkstaStatAutoRecs OBJECT-TYPE
    SYNTAX Counter
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of sessions broken and then automatically
    reestablished."
    ::= { workstation 5 } wkstaErrorLogSize OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-write
    STATUS mandatory
    DESCRIPTION
    "The size in kilobytes to which the workstation error log
    can grow."
    ::= { workstation 6 } wkstaUseNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of active uses the workstation is currently
    maintaining."
    ::= { workstation 7 } wkstaUseTable OBJECT-TYPE
    SYNTAX SEQUENCE OF WkstaUseEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "The table of active uses made by this workstation."
    ::= { workstation 8 } wkstaUseEntry OBJECT-TYPE
    SYNTAX WkstaUseEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "A use of a remote network resource."
    INDEX { useLocalName, useRemote }
    ::= { wkstaUseTable 1 } WkstaUseEntry ::= SEQUENCE {
    useLocalName
    DisplayString ,
    useRemote
    DisplayString ,
    useStatus
    INTEGER
    } useLocalName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (0..8))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the local devicename (such as e: or lpt1:) that
    is redirected."
    ::= { wkstaUseEntry 1 } useRemote OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..255))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the remote shared resource to which the redirection
    has been made. (such as \\server\share)."
    ::= { wkstaUseEntry 2 } useStatus OBJECT-TYPE
    SYNTAX
    INTEGER {
    use-ok(1),
    use-paused(2),
    use-session-lost(3),
    use-network-error(4),
    use-connecting(5),
    use-reconnecting(6)
    }
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The status of this connection."
    ::= { wkstaUseEntry 3 } The Domain Group
    domPrimaryDomain OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..15))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the primary domain to which this machine belongs."
    ::= { domain 1 } domLogonDomain OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..15))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the domain to which this machine is logged on."
    ::= { domain 2 } domOtherDomainNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of entries in domOtherDomainTable."
    ::= { domain 3 } domOtherDomainTable OBJECT-TYPE
    SYNTAX SEQUENCE OF DomOtherDomainEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "The list of other domains which this machine is monitoring."
    ::= { domain 4 } domOtherDomainEntry OBJECT-TYPE
    SYNTAX DomOtherDomainEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "An entry in the table of other domains."
    INDEX { domOtherName }
    ::= { domOtherDomainTable 1 } DomOtherDomainEntry ::= SEQUENCE {
    domOtherName
    DisplayString
    }
    domOtherName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..15))
    ACCESS read-write
    STATUS mandatory
    DESCRIPTION
    "The name of an additional domain which this machine is
    monitoring."
    ::= { domOtherDomainEntry 1 } domServerNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of entries in domServerTable."
    ::= { domain 5 } domServerTable OBJECT-TYPE
    SYNTAX SEQUENCE OF DomServerEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "The list of non-hidden servers that are on all of the
    domains this machine is monitoring."
    ::= { domain 6 } domServerEntry OBJECT-TYPE
    SYNTAX DomServerEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "An entry in the domain server table."
    INDEX { domServerName }
    ::= { domServerTable 1 } DomServerEntry ::= SEQUENCE {
    domServerName
    DisplayString
    }
    domServerName OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..15))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of a server on one of the domains which this
    machine is monitoring."
    ::= { domServerEntry 1 } domLogonNumber OBJECT-TYPE
    SYNTAX INTEGER
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The number of entries in domLogonTable."
    ::= { domain 7 } domLogonTable OBJECT-TYPE
    SYNTAX SEQUENCE OF DomLogonEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "The list of domain logons which this machine has processed.
    Available only on servers acting as primary or backup domain
    controllers. To compile the complete table of all logons on
    a given domain, it is necessary to query all primary and backup
    domain controllers on the domain."
    ::= { domain 8 } domLogonEntry OBJECT-TYPE
    SYNTAX DomLogonEntry
    ACCESS not-accessible
    STATUS mandatory
    DESCRIPTION
    "An entry in the logon table."
    INDEX { domLogonUser, domLogonMachine }
    ::= { domLogonTable 1 } DomLogonEntry ::= SEQUENCE {
    domLogonUser
    DisplayString ,
    domLogonMachine
    DisplayString
    }
    domLogonUser OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..20))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the user who is logged on to this domain."
    ::= { domLogonEntry 1 } domLogonMachine OBJECT-TYPE
    SYNTAX DisplayString (SIZE (1..15))
    ACCESS read-only
    STATUS mandatory
    DESCRIPTION
    "The name of the machine from which the user logged on."
    ::= { domLogonEntry 2 }
    END


Microsoft DHCP Server MIB

The DHCP Server MIB contains object-types that are used to monitor the network traffic between remote hosts and the DHCP server.

DHCP-MIB DEFINITIONS ::= BEGIN
IMPORTS
enterprises,
OBJECT-TYPE
FROM RFC1155-SMI
DisplayString
FROM RFC1213-MIB
microsoft,
software
FROM WINS-MIB; -- microsoft OBJECT IDENTIFIER ::= { enterprises 311 }
-- software OBJECT IDENTIFIER ::= { microsoft 1 } dhcp OBJECT IDENTIFIER ::= { software 3 }
dhcpPar OBJECT IDENTIFIER ::= { dhcp 1 }
dhcpScope OBJECT IDENTIFIER ::= { dhcp 2 } -- Dhcp MIB
-- Parameters (Prefix Par) parDhcpStartTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Dhcp Server start time"
::= { dhcpPar 1 } parDhcpTotalNoOfDiscovers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
discovery messages received"
::= { dhcpPar 2 }
parDhcpTotalNoOfRequests OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
requests received"
::= { dhcpPar 3 } parDhcpTotalNoOfReleases OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
releases received"
::= { dhcpPar 4 } parDhcpTotalNoOfOffers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
offers sent"
::= { dhcpPar 5 } parDhcpTotalNoOfAcks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
acks received"
::= { dhcpPar 6 } parDhcpTotalNoOfNacks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
nacks received"
::= { dhcpPar 7 } parDhcpTotalNoOfDeclines OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
declines"
::= { dhcpPar 8 } -- scope group (Prefix Scope)
scopeTable OBJECT-TYPE
SYNTAX SEQUENCE OF ScopeTableEntry
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A list of subnets maintained by the server"
::= { dhcpScope 1 } scopeTableEntry OBJECT-TYPE
SYNTAX ScopeTableEntry
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the row corresponding to a subnet"
INDEX { subnetAdd }
::= { scopeTable 1 } ScopeTableEntry ::= SEQUENCE {
subnetAdd
IpAddress,
noAddInUse
Counter,
noAddFree
Counter,
noPendingOffers
Counter
}
subnetAdd OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the subnet address "
::= { scopeTableEntry 1 } noAddInUse OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of addresses in use"
::= { scopeTableEntry 2 } noAddFree OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of addresses that are free "
::= { scopeTableEntry 3 } noPendingOffers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of addresses that are currently in the
offer state"
::= { scopeTableEntry 4 } END


Microsoft WINS Server MIB

The WINS server MIB contains object-types that are used to monitor the network
traffic between remote hosts and the WINS server.
WINS-MIB DEFINITIONS ::= BEGIN IMPORTS
enterprises,
OBJECT-TYPE
FROM RFC1155-SMI
DisplayString
FROM RFC1213-MIB;
microsoft OBJECT IDENTIFIER ::= { enterprises 311 }
software OBJECT IDENTIFIER ::= { microsoft 1 }
wins OBJECT IDENTIFIER ::= { software 2 }
par OBJECT IDENTIFIER ::= { wins 1 }
pull OBJECT IDENTIFIER ::= { wins 2 }
push OBJECT IDENTIFIER ::= { wins 3 }
datafiles OBJECT IDENTIFIER ::= { wins 4 }
cmd OBJECT IDENTIFIER ::= { wins 5 } -- WINS MIB
-- Parameters (Prefix Par) parWinsStartTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"WINS start time"
::= { par 1 }
parLastPScvTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which planned scavenging
took place. Planned scavenging happens at intervals
specified in the registry. Scavenging involves
changing owned non-refreshed entries to the released
state. Further, replicas may be changed to tombstones,
tombstones may be deleted, and revalidation of old
replicas may take place"
::= { par 2 }
parLastATScvTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which scavenging as a
result of administrative action took place"
::= { par 3 } parLastTombScvTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which replica tombstone
scavenging took place"
::= { par 4 } parLastVerifyScvTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which revalidation of
old active replicas took place"
::= { par 5 } parLastPRplTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which planned replication
took place. Planned replication happens at intervals
specified in the registry"
::= { par 6 } parLastATRplTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which administrator-
triggered replication took place."
::= { par 7 } parLastNTRplTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which network-triggered
replication took place. Network-triggered replication
happens as a result of an update notification message
from a remote WINS"
::= { par 8 } parLastACTRplTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which address change-
triggered replication took place. Address change-
triggered replication happens when the address of
an owned name changes due to a new registration"
::= { par 9 } parLastInitDbTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which the local database
was populated statically from one or more data files"
::= { par 10 } parLastCounterResetTime OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..30))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Most recent date and time at which the local counters
were initialized to zero"
::= { par 11 } parWinsTotalNoOfReg OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
registrations received"
::= { par 12 } parWinsTotalNoOfQueries OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
queries received"
::= { par 13 } parWinsTotalNoOfRel OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
releases received"
::= { par 14 } parWinsTotalNoOfSuccRel OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
releases that succeeded"
::= { par 15 } parWinsTotalNoOfFailRel OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
releases that failed"
::= { par 16 } parWinsTotalNoOfSuccQueries OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
queries that succeeded"
::= { par 17 } parWinsTotalNoOfFailQueries OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This variable indicates the number of
queries that failed"
::= { par 18 } parRefreshInterval OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the refresh interval.
Unit is in milliseconds"
::= { par 19 } parTombstoneInterval OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the tombstone interval.
Unit is in milliseconds"
::= { par 20 } parTombstoneTimeout OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the tombstone timeout.
Unit is in milliseconds"
::= { par 21 } parVerifyInterval OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the verify interval.
Unit is in milliseconds."
::= { par 22 } parVersCounterStartValLowWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the low word of the
version counter that WINS should start with"
::= { par 23 } parVersCounterStartValHighWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the high word of the
version counter that WINS should start with"
::= { par 24 } parRplOnlyWCnfPnrs OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates whether or not
replication should be done with non-configured partners. If not
set to zero, replication will be done only with partners listed in the
registry (except when an update notification comes in)"
::= { par 25 } parStaticDataInit OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates whether static data should
be read in at initialization and reconfiguration time.
Update of any MIB variable in the parameters group constitutes
reconfiguration"
::= { par 26 } parLogFlag OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates whether logging should be
done. Default behavior is to do logging"
::= { par 27 } parLogFileName OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable gives the path to the log file"
::= { par 28 } parBackupDirPath OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable gives the path to the backup directory"
::= { par 29 } parDoBackupOnTerm OBJECT-TYPE
SYNTAX INTEGER {
no(0),
yes(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable specifies whether WINS should do
backup on termination. Setting it to 1 holds no
meaning unless parBackupDirPath is set also"
::= { par 30 } parMigrateOn OBJECT-TYPE
SYNTAX INTEGER {
no(0),
yes(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable specifies whether static records
in the WINS database should be treated as
dynamic records during conflicts with new
dynamic registrations"
::= { par 31 } -- datafiles group (Prefix df) dfDatafilesTable OBJECT-TYPE
SYNTAX SEQUENCE OF DFDatafileEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A list of datafiles specified under the Datafiles
key in the registry. These files are used for
static initialization of the WINS database"
::= { datafiles 1 } dfDatafileEntry OBJECT-TYPE
SYNTAX DFDatafileEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"data file name"
INDEX { dfDatafileIndex }
::= { dfDatafilesTable 1 } DFDatafileEntry ::= SEQUENCE {
dfDatafileIndex
INTEGER,
dfDatafileName
DisplayString
} dfDatafileIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Used for indexing entries in the datafiles table.
It has no other use"
::= { dfDatafileEntry 1 } dfDatafileName OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Name of the datafile to use for static initialization"
::= { dfDatafileEntry 2 } -- pull group (Prefix pull) pullInitTime OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates whether pull should be
done at WINS invocation and at reconfiguration.
If any pull group's MIB variable is set, that
constitutes reconfiguration"
::= { pull 1 } pullCommRetryCount OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable gives the retry count in
case of communication failure when doing pull replication.
This is the maximum number of retries that will be
done at the interval specified for the partner
before WINS will stop for a certain number (canned) of
replication time intervals before starting again."
::= { pull 2 } pullPnrTable OBJECT-TYPE
SYNTAX SEQUENCE OF PullPnrEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A list of partners with which pull replication needs
to be done"
::= { pull 3 } pPullPnrEntry OBJECT-TYPE
SYNTAX PullPnrEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This is the row corresponding to a partner"
INDEX { pullPnrAdd }
::= { pullPnrTable 1 } PullPnrEntry ::= SEQUENCE {
pullPnrAdd
IpAddress, pullPnrSpTime
DisplayString, pullPnrTimeInterval
INTEGER, pullPnrMemberPrec
Counter,
pullPnrNoOfSuccRpls
Counter, pullPnrNoOfCommFails
Counter }
pullPnrAdd OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This is the address of the remote WINS partner"
::= { pPullPnrEntry 1 } pullPnrSpTime OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable gives the specific time at which
pull replication should occur"
::= { pPullPnrEntry 2 } pullPnrTimeInterval OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable gives the time interval for
pull replication"
::= { pPullPnrEntry 3 }
pullPnrMemberPrec OBJECT-TYPE
SYNTAX INTEGER {
low(0),
high(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This is the precedence to be given to members of
the special group pulled from the WINS. Note:
the precedence of locally registered members of a
special group is more than any replicas pulled in"
::= { pPullPnrEntry 4 } pullPnrNoOfSuccRpls OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times replication was successful with
the WINS after invocation or reset of counters"
::= { pPullPnrEntry 5 } pullPnrNoOfCommFails OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times replication was unsuccessful with
the WINS due to communication. failure (after invocation or reset of counters)"
::= { pPullPnrEntry 6 } pullPnrVersNoLowWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The low word of the highest version number found in records owned by this WINS."
::= { pPullPnrEntry 7 } pullPnrVersNoHighWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The high word of the highest version number found in records owned by this WINS."
::= { pPullPnrEntry 8 } -- push group (Prefix - push)
pushInitTime OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates whether a push (that is, a
notification message) should be done at invocation."
::= { push 1 } pushRplOnAddChg OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates whether a notification
message should be sent when an address changes"
::= { push 2 } pushPnrTable OBJECT-TYPE
SYNTAX SEQUENCE OF PushPnrEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A list of WINS partners with which push
replication is to be initiated"
::= { push 3 } pushPnrEntry OBJECT-TYPE
SYNTAX PushPnrEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This is the row corresponding to the WINS partner"
INDEX { pushPnrAdd }
::= { pushPnrTable 1 }
PushPnrEntry ::= SEQUENCE {
pushPnrAdd
INTEGER, pushPnrUpdateCount
INTEGER
} pushPnrAdd OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Address of the WINS partner"
::= { pushPnrEntry 1 }
pushPnrUpdateCount OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable indicates the number of updates that
should result in a push message"
::= { pushPnrEntry 2 } -- cmd group (Prefix - cmd) cmdPullTrigger OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable, when set, will cause the WINS to
pull from the remote WINS identified by the IpAddress"
::= { cmd 1 } cmdPushTrigger OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable, when set, will cause the WINS to
push a notification message to the remote WINS
identified by the IpAddress"
::= { cmd 2 }
cmdDeleteWins OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable, when set, will cause all information
pertaining to a WINS (data records, context
information) to be deleted from the local WINS.
Use this only when owner-address mapping table is
getting to near capacity. Note: Deletion of all
information pertaining to the managed WINS is not
permitted"
::= { cmd 3 } cmdDoScavenging OBJECT-TYPE
SYNTAX INTEGER {
no(0),
yes(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable, when set, will cause WINS to do
scavenging."
::= { cmd 4 } cmdDoStaticInit OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
DESCRIPTION
"When this variable is set, WINS will do static
initialization using the file specified as the value.
If 0 is specified, WINS will do static initialization using the
files specified in the registry (can be read-written using Datafile table"
::= { cmd 5 } cmdNoOfWrkThds OBJECT-TYPE
SYNTAX INTEGER (1..4)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Sets the number of worker threads in WINS"
::= { cmd 6 } cmdPriorityClass OBJECT-TYPE
SYNTAX INTEGER {
normal(0),
high(1)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Sets the priority class of WINS to normal or high"
::= { cmd 7 } cmdResetCounters OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Resets the counters. Value is ignored"
::= { cmd 8 } cmdDeleteDbRecs OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable, when set, will cause all data records
pertaining to a WINS to be deleted from the local WINS.
Note: Only data records are deleted."
::= { cmd 9 } cmdDRPopulateTable OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This variable can be set to retrieve records of
a WINS whose Ip address is provided. When set,
the table is populated immediately"
::= { cmd 10 }
cmdDRDataRecordsTable OBJECT-TYPE
SYNTAX SEQUENCE OF CmdDRRecordEntry
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the table that stores the data records.
The records are sorted by name.
Note: the table is cached (to save on overhead on WINS).
To repopulate the table, set cmdDRDataRecordsTable mib var"
::= { cmd 11 } cmdDRRecordEntry OBJECT-TYPE
SYNTAX CmdDRRecordEntry
ACCESS read-write
STATUS mandatory
DESCRIPTION "Data record owned by WINS whose address
was specified when CmdDRRecordsTable was
set"
INDEX { cmdDRRecordName }
::= { cmdDRDataRecordsTable 1 } CmdDRRecordEntry ::= SEQUENCE {
cmdDRRecordName
DisplayString,
cmdDRRecordAddress
OCTET STRING,
cmdDRRecordType
INTEGER,
cmdDRRecordPersistenceType
INTEGER,
cmdDRRecordState
INTEGER
} cmdDRRecordName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Name in the record"
::= { cmdDRRecordEntry 1 }
cmdDRRecordAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Address(es) of the record. If the record is
a multihomed record or a special group, the
addresses are returned sequentially in pairs.
Each pair is comprised of the address of the
owner WINS followed by the address of the
machine (multihomed)/member (special group).
Note: Following SNMP's convention, the records
are always returned in network byte order"
::= { cmdDRRecordEntry 2 }
cmdDRRecordType OBJECT-TYPE
SYNTAX INTEGER {
unique(0),
normalgroup(1),
specialgroup(2),
multihomed(3)
}
Note: The preceding order should not be disturbed. It is the same as-- in winsintf.h (WINSINTF_RECTYPE_E)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Type of the record"
::= {cmdDRRecordEntry 3 } cmdDRRecordPersistenceType OBJECT-TYPE
SYNTAX INTEGER {
static(0),
dynamic(1)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Persistence type of the record"
::= { cmdDRRecordEntry 4 }
cmdDRRecordState OBJECT-TYPE
SYNTAX INTEGER {
active(0),
released(1),
tombstone(2),
deleted(3)
}
-- Note: The preceding order should not be disturbed. It is the same as
-- in winsintf.h (WINSINTF_STATE_E)
-- for a SET operation only released and deleted values are
-- allowed
ACCESS read-only
STATUS mandatory
DESCRIPTION
"State of the record."
::= { cmdDRRecordEntry 5 } cmdWinsVersNoLowWord OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The low word of the version number counter of the WINS"
::= { cmd 12 } cmdWinsVersNoHighWord OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The high word of the version number counter of the WINS"
::= { cmd 13 }
END


Microsoft Internet Information Server (IIS) MIB

The Microsoft Internet Information Server MIB contains objects that provide information about network communications and performance on the IIS Server. The base object for the InternetServer MIB is 1.3.6.1.4.1.311.1.7 and is currently composed of several MIBs that branch from this base object:

  • FTP Server MIB
  • Gopher Server MIB
  • HTTP Server MIB

The InternetServer section of the OID name tree is organized as follows:

iso (1)
org(3)
dod(6)
internet(1)
private(4)
enterprises(1)
microsoft(311)
software(1)
InternetServer(7)
FtpServer(2)
FTPStatistics(1)
W3Server(3)
W3Statistics(1)
GopherServer(4)
GopherStatistics(1)


Microsoft FTP Server MIB

FtpServer-MIB DEFINITIONS ::= BEGIN
IMPORTS
enterprises,
OBJECT-TYPE,
Counter
FROM RFC1155-SMI
internetServer
FROM InternetServer-MIB;
-- microsoft OBJECT IDENTIFIER ::= { enterprises 311 }
-- software OBJECT IDENTIFIER ::= { microsoft 1 }
-- internetServer OBJECT IDENTIFIER ::= { software 7 }
ftpServer OBJECT IDENTIFIER ::= { internetServer 2 }
ftpStatistics OBJECT IDENTIFIER ::= { ftpServer 1 } -- FTP Server Statistics
totalBytesSentHighWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the high 32-bits of the total number of
of BYTEs sent by the FTP Server"
::= { ftpStatistics 1 } totalBytesSentLowWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the low 32-bits of the total number of
of BYTEs sent by the FTP Server"
::= { ftpStatistics 2 } totalBytesReceivedHighWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the high 32-bits of the total number of
of BYTEs received by the FTP Server"
::= { ftpStatistics 3 } totalBytesReceivedLowWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the low 32-bits of the total number of
of BYTEs received by the FTP Server"
::= { ftpStatistics 4 }
totalFilesSent OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of files sent by this
FTP Server"
::= { ftpStatistics 5 } totalFilesReceived OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of files received by this
FTP Server"
::= { ftpStatistics 6 } currentAnonymousUsers OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of anonymous users currently
connected to the FTP Server"
::= { ftpStatistics 7 } currentNonAnonymousUsers OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of nonanonymous users currently
connected to the FTP Server"
::= { ftpStatistics 8 } totalAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of anonymous users that
have ever connected to the FTP Server"
::= { ftpStatistics 9 }
totalNonAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of nonanonymous users that
have ever connected to the FTP Server"
::= { ftpStatistics 10 } maxAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of anonymous users
simultaneously connected to the FTP Server"
::= { ftpStatistics 11 } maxNonAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of nonanonymous users
simultaneously connected to the FTP Server"
::= { ftpStatistics 12 } currentConnections OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the current number of connections to the
FTP Server"
::= { ftpStatistics 13 } maxConnections OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of simultaneous
connections to the FTP Server"
::= { ftpStatistics 14 } connectionAttempts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of connection attempts that
have been made to the FTP Server"
::= { ftpStatistics 15 } logonAttempts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of logon attempts that have
been made to the FTP Server"
::= { ftpStatistics 16 }
END


Microsoft Gopher Server MIB

GopherServer-MIB DEFINITIONS ::= BEGIN

IMPORTS
enterprises,
OBJECT-TYPE,
Counter
FROM RFC1155-SMI
internetServer
FROM InternetServer-MIB; -- microsoft OBJECT IDENTIFIER ::= { enterprises 311 }
-- software OBJECT IDENTIFIER ::= { microsoft 1 }
-- internetServer OBJECT IDENTIFIER ::= { software 7 }
gopherServer OBJECT IDENTIFIER ::= { internetServer 4 }
gopherStatistics OBJECT IDENTIFIER ::= { gopherServer 1 }
-- Gopher Server Statistics totalBytesSentHighWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the high 32-bits of the total number of
of BYTEs sent by the Gopher Server"
::= { gopherStatistics 1 } totalBytesSentLowWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the low 32-bits of the total number of
of BYTEs sent by the Gopher Server"
::= { gopherStatistics 2 } totalBytesReceivedHighWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the high 32-bits of the total number of
of BYTEs received by the Gopher Server"
::= { gopherStatistics 3 } totalBytesReceivedLowWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the low 32-bits of the total number of
of BYTEs received by the Gopher Server"
::= { gopherStatistics 4 } totalFilesSent OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of files sent by this
Gopher Server"
::= { gopherStatistics 5 }
totalDirectorySent OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of directory listings sent
by this Gopher Server" ::= { gopherStatistics 6 } totalSearchesDone OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of searches done by this
Gopher Server"
::= { gopherStatistics 7 } currentAnonymousUsers OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of anonymous users currently
connected to the Gopher Server"
::= { gopherStatistics 8 } currentNonAnonymousUsers OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of nonanonymous users currently
connected to the Gopher Server"
::= { gopherStatistics 9 } totalAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of anonymous users that
have ever connected to the Gopher Server"
::= { gopherStatistics 10 } totalNonAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of nonanonymous users that
have ever connected to the Gopher Server"
::= { gopherStatistics 11 } maxAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of anonymous users
simultaneously connected to the Gopher Server"
::= { gopherStatistics 12 } maxNonAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of nonanonymous users
simultaneously connected to the Gopher Server"
::= { gopherStatistics 13 } currentConnections OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the current number of connections to the
Gopher Server"
::= { gopherStatistics 14 } maxConnections OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of simultaneous
connections to the Gopher Server"
::= { gopherStatistics 15 } connectionAttempts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of connection attempts that
have been made to the Gopher Server"
::= { gopherStatistics 16 } logonAttempts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of logon attempts that have
been made to this Gopher Server"
::= { gopherStatistics 17 } abortedConnections OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of aborted connections that have
been made to this Gopher Server"
::= { gopherStatistics 18 }
END


Microsoft HTTP Server MIB

HttpServer-MIB DEFINITIONS ::= BEGIN

IMPORTS
enterprises,
OBJECT-TYPE,
Counter
FROM RFC1155-SMI
internetServer
FROM InternetServer-MIB; -- microsoft OBJECT IDENTIFIER ::= { enterprises 311 }
-- software OBJECT IDENTIFIER ::= { microsoft 1 }
-- internetServer OBJECT IDENTIFIER ::= { software 7 }
httpServer OBJECT IDENTIFIER ::= { internetServer 3 }
httpStatistics OBJECT IDENTIFIER ::= { httpServer 1 } -- Http Server Statistics totalBytesSentHighWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the high 32-bits of the total number of
of BYTEs sent by the Http Server"
::= { httpStatistics 1 } totalBytesSentLowWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the low 32-bits of the total number of
of BYTEs sent by the Http Server"
::= { httpStatistics 2 } totalBytesReceivedHighWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the high 32-bits of the total number of
of BYTEs received by the Http Server"
::= { httpStatistics 3 } totalBytesReceivedLowWord OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the low 32-bits of the total number of
of BYTEs received by the Http Server"
::= { httpStatistics 4 } totalFilesSent OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of files sent by this
Http Server"
::= { httpStatistics 5 }
currentAnonymousUsers OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of anonymous users currently
connected to the Http Server"
::= { httpStatistics 6 } currentNonAnonymousUsers OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of nonanonymous users currently
connected to the Http Server"
::= { httpStatistics 7 } totalAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of anonymous users that
have ever connected to the Http Server"
::= { httpStatistics 8 } totalNonAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the total number of nonanonymous users that
have ever connected to the Http Server"
::= { httpStatistics 9 }
maxAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of anonymous users
simultaneously connected to the Http Server"
::= { httpStatistics 10 }
maxNonAnonymousUsers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of nonanonymous users
simultaneously connected to the Http Server"
::= { httpStatistics 11 } currentConnections OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the current number of connections to the
Http Server"
::= { httpStatistics 12 } maxConnections OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the maximum number of simultaneous
connections to the Http Server"
::= { httpStatistics 13 } connectionAttempts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of connection attempts that
have been made to the Http Server"
::= { httpStatistics 14 } logonAttempts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of logon attempts that have
been made to this Http Server"
::= { httpStatistics 15 }
totalGets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of requests using the GET method
that have been made to this Http Server"
::= { httpStatistics 16 } totalPosts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of requests using the POST method
that have been made to this Http Server"
::= { httpStatistics 17 } totalHeads OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of requests using the HEAD method
that have been made to this Http Server"
::= { httpStatistics 18 } totalOthers OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of requests not using the GET,
POST, or HEAD method that have been made to this Http
Server"
::= { httpStatistics 19 } totalCGIRequests OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of Common Gateway Interface (CGI)
requests that have been made to this Http Server"
::= { httpStatistics 20 } totalBGIRequests OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of Binary Gateway Interface (BGI)
requests that have been made to this Http Server"
::= { httpStatistics 21 }
totalNotFoundErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This is the number of requests the Http server could
not satisfy because the requested resource could not
be found"
::= { httpStatistics 22 }


Appendix D - Windows Sockets

The Windows Sockets application programming interface (API) provides a standard Windows interface to many transports (protocols) with different addressing schemes such as TCP/IP and IPX. The Windows Sockets API is designed to provide a programming standard for all platforms.

Windows Sockets is a programming interface based on the familiar "socket" interface from the University of California at Berkeley. Windows Sockets is an industry standard used by software developers and is part of the public Windows Open Systems Architecture (WOSA).

This appendix provides the following information about Windows Sockets:

  • An overview of Windows Sockets as implemented in Windows NT Server and Windows NT Workstation
  • A description of Windows Sockets programs from third-party vendors that support cross-platform computing.
  • A list of TCP/IP utilities compliant with Windows Sockets.
  • Instructions for developers on how to obtain the latest information, specifications, and sample programs needed to develop Windows Sockets compliant programs for the Microsoft family of 32-bit and 16-bit Windows operating systems.

The information in this appendix supersedes information about TCP/IP and the Windows Sockets API in the following sources:

  • Chapter 10, "Overview of Microsoft TCP/IP for Windows NT," and Appendix A, "TCP/IP Utilities Reference," of the Windows NT Networking Guide, Volume 1
  • Chapter 1, "Overview of Microsoft TCP/IP," and Chapter 11 "Utilities Reference," of the TCP/IP book for Microsoft Windows NT Server


Overview of Windows Sockets

When referring to the seven layers of the OSI model for network communications, Windows Sockets functions at the session layer interface to the transport layer. In other words, Windows Sockets is an interface between applications and the transport protocol and works as a bi-directional pipe for incoming and outgoing application data. Windows Sockets is implemented as a dynamic-link library (DLL) that allows applications and the transport service to be dynamically bound together at run time.

Windows Sockets was originally designed for use with the TCP/IP transport protocol. However, extensions to Windows Sockets now allow use of non-TCP/IP transport protocols with Windows Sockets. Windows Sockets as implemented in Windows NT Server and Windows NT Workstation provides a true transport-independent interprocess communication service. Windows Sockets in Windows NT Server and Windows NT Workstation supports the following transport protocols:

  • TCP/IP
  • Novell IPX/SPX
  • Digital DECnet
  • Xerox Network Systems (XNS)

Note

Windows NT Server and Windows NT Workstation version 4.0 implement 32-bit Windows Sockets version 2.0. Earlier versions of Windows NT implement 32-bit Windows Sockets version 1.1. The specifications for Windows Sockets are open, public specifications. See the section "Developing Programs Using Windows Sockets" at the end of this appendix for a list of Microsoft and other Internet sites from which you can receive information about Windows Sockets.

TCP/IP Utilities Compatible with Windows Sockets

As mentioned earlier, Windows Sockets was originally designed for use with TCP/IP. Many commonly used TCP/IP utilities are compatible with the Windows Sockets provided with Windows NT Server and Windows NT Workstation. These TCP/IP utilities are as follows:

  • arp
  • finger
  • ftp
  • hostname
  • ipconfig
  • lpq
  • lpr
  • nbtstat
  • netstat
  • nslookup
  • ping
  • rcp
  • rexec
  • route
  • rsh
  • telnet
  • tftp
  • tracert

For a complete description of each of these utilities, see online Help or refer to Appendix A, "TCP/IP Utilities Reference."


Third-party Software for TCP/IP and Windows Sockets

Most TCP/IP users either use programs that comply with the Windows Sockets standard, such as the TCP/IP utilities ftp or telnet, or third-party programs. TCP/IP-aware programs from vendors that comply with the Windows Sockets standard can run on virtually any TCP/IP implementation.

Other typical third-party programs include graphic connectivity utilities (for example, those that connect to the Internet), terminal emulation software, Simple Mail Transport Protocol (SMTP) and electronic mail clients, network printing utilities, SQL client programs, and corporate client-server programs.

Note

For information about Microsoft partners and solution providers who provide Windows Sockets-compliant software, contact Microsoft Sales and Services at 1-800-426-9400 and request the catalog "Microsoft InfoSource," part number #098-62986. This catalog provides information about Microsoft partners and solution providers who provide a wide range of third-party hardware, software, and services.

Third-party software can also be used to implement a seamless network environment between Windows NT Server and Windows NT Workstation computers and UNIX networks. To do this, additional third-party software is required for:

  • Support for Network File System (NFS), the de facto standard for UNIX file sharing
  • The ability to run the most common UNIX graphical user interface, X Window, on Windows NT Server and Windows NT Workstation computers.

Third-party programs provide Windows NT-based support for NFS. These third-party programs allow Windows NT-based computers and programs to connect to UNIX-based file directories and to access data, while the UNIX systems in the network can access the Windows NT Server and Windows NT Workstation file directories and file data.

The Windows Sockets standard ensures compatibility with third-party programs for X Window. Currently available third-party programs include X Window manager programs and client libraries. These programs and libraries allow development of X Window client programs for Windows NT Server and Windows NT Workstation computers.

Note

Windows NT Server and Windows NT Workstation documentation uses the standard terminology for the client and server relationship, where the client is the workstation and the server is the computer that provides shared resources to network users. There is a portion of the UNIX world in which this relationship is reversed. The client is the server, and the server is the client. In UNIX X window terminology, the client software resides on the computer that performs the processing, and the server software resides on the computer that displays the output.


Developing Programs Using Windows Sockets

The Windows Sockets API is an open, public specification based on the Berkeley (BSD) Sockets APIs that are a de facto standard for UNIX network programming. Because the Windows Sockets API is similar to the Berkeley Sockets API, UNIX applications can be easily ported to the Windows NT Server, Windows NT Workstation, and Windows 95 platforms.

Note

Developers can also use the protocol-independent Windows Sockets API to develop programs for the AppleTalk stack, the underlying mechanism that allows Windows NT Servers using Services for Macintosh to share files and printers with Macintosh networks.

The Windows Sockets standard allows a developer to create a program with a single common interface and a single executable that can run over many types of TCP/IP implementations. The Windows Sockets API provides the following:

  • A familiar networking API for programmers using Windows NT Server, Windows NT Workstation, Windows 95, Windows 3.11 or higher, and UNIX.
  • Binary compatibility between vendors for heterogeneous Windows-based TCP/IP stacks and utilities.
  • Support for both connection-oriented and connectionless protocols.

Windows Sockets version 2.0 provides a clean architecture for plugging in service providers. Specifications for the next generation of Windows Sockets version 2.0 and earlier versions are available from the Internet, and in the Microsoft Win32 Software Developers Kit.

To get current Windows Sockets information from the Microsoft Developers Network

· Connect to: //www.microsoft.com/intdev/inttech/winsock.htm

To get a copy of the specification for the next generation of Windows Sockets, Windows Sockets version 2.0

· Connect to: //www.stardust.com/wsresource/winsock2

Or, connect to: //www.intel.com/IAL/winsock2

To get a copy of the Windows Sockets specifications by using anonymous FTP

1. Make sure you have write permission in your current working directory.

2. At the command prompt, start ftp, and then connect to ftp.microsoft.com
(or 198.105.232.1).

3. Log on as anonymous.

4. Type your electronic mail address for the password.

5. Type cd \bussys\winsock\spec11, and then press ENTER.

6. Use the dir command to see the list of available file types.

If you want binary data such as in the Microsoft Word version, type bin, and then press ENTER.

To subscribe to the Windows Sockets mailing list

· Send electronic mail to listserv@sunsite.unc.edu with a message body that contains subscribe winsock your email-address.

You can use the same procedure to subscribe to additional mailing lists called winsock-hackers and winsock-users.


Appendix E - RAS Reference

This appendix presents information on Remote Access Service (RAS), and Windows NT 4.0 RAS, in three sections. The first section gives an overview of the most important modem compatibility standards and how they work within RAS. The second section is a series of quick-reference charts to give you a high-level perspective of how RAS works during a call to a Windows NT RAS server. The last section contains reference tables for RAS server and client computers that detail the different versions of RAS and the features they support.


RAS and Modem Compatibility Standards

The following information is an overview of the most important modem standards, how they can be categorized into four compatibility levels, and how they pertain to RAS and RAS data compression. This information, along with the RAS online Help topic "Modifying MODEM.INF," also enables you to implement unsupported modems with RAS versions 1.x, RAS for Windows for Workgroups 3.11, and RAS for Windows NT versions 3.1, 3.5, and 3.51.

You can apply most of the information to RAS for Windows 95; however, RAS for Windows 95 does not use a Modem.inf file. Instead, it uses Telephone Application Programming Interface (TAPI), which relies on entries in the Windows 95 registry for modem initialization. To implement unsupported modems with RAS for Windows 95, it is recommended that you obtain a modem driver from the modem manufacturer.

Windows NT 4.0 RAS also includes support for TAPI as well as supporting new modems through the Universal Modem Driver (Unimodem). RAS continues to support modems for older legacy systems. To configure a previously installed unsupported modem to work with RAS, add an entry for that modem in the Modem.inf file.


Supported Media

Depending on the RAS version, RAS supports X.25, ISDN, Null Modem, and asynchronous modem communication. RAS does not support synchronous communication and therefore cannot communicate with a synchronous serial port. Synchronous communication synchronizes the transmission by controlling the timing and the duration of data signals.

Asynchronous communication means that each byte is framed with a start and stop bit. RAS sends data asynchronously to the serial port, and the serial port sends data asynchronously to the modem. The asynchronous modem then strips the start and stop bit from each byte (a byte is also referred to as character) and converts the characters into blocks that are then sent synchronously (not asynchronously) to the other modem by using an error control protocol. The other modem disassembles these synchronous blocks, and frames each character with a start and stop bit before sending it on to the serial port of the RAS server. The serial port then sends it to the RAS server service. This process occurs during a communication call similar to that shown in Figure E.1.

Leased line communication using asynchronous serial ports and either asynchronous or synchronous modems can be implemented under some circumstances, as long as RAS can treat the connection as an asynchronous null modem connection. Some modems support both synchronous and asynchronous communication.


Asynchronous Communication

To understand asynchronous modem communication using RAS, you need to understand the following four compatibility levels in relation to RAS:

  • Modem Command Language
  • Modem Modulation Standards
  • Modem Error Control Standards
  • Modem Data Compression Standards and RAS Data Compression

Figure E.1 shows these four compatibility levels being implemented during a WAN connection. The different levels are shown below the section of the asynchronous RAS link to which they apply:

  • modem command language affects command compatibility between RAS and the local modem, modem modulation standards affect the telephone line speed;
  • compatibility between two modems, modem error control standards affect the local and remote modem level of error control compatibility;
  • modem compression standards affect the local and remote modem data compression compatibility; and
  • RAS data compression affects data compression between the local and remote computer.

In the diagram, the RAS client is on the right side and the RAS server on the left side, and they are connected over external modems.

Notice that a RAS client or server acts as Data Terminal Equipment (DTE), and a modem acts as Data Communications Equipment (DCE).

Figure E.1 Modem Compatibility Standards


RAS and the Modem Command Language

For a modem to be compatible with any communication software running on the local computer, the software must be compatible with the modem command language, also referred to as the modem command set. The command set configures the other three compatibility levels of the modem according to the needs of the local software (RAS), the supported modem standards of the modem being called, and the users' preferences. For certain modems, the modem command set works between the local and remote modems as well as between the local communications software and the local modem.

Command set compatibility between RAS modem drivers and the local modem is advantageous, but not a requirement. Many manufacturers advertise that their modem is 100 percent compatible with the popular Hayes AT command set, or that it is compatible with another popular modem's command set. This generally means that the modem uses the same commands as Hayes modems for basic operations such as dial, hang up, reset, and answer. It does not imply that the modem uses the same commands for configuration of modulation, error control, or data compression. However, if your modem is not compatible with any supported modem's command set, you can customize the RAS modem driver by modifying the Modem.inf file (or Modems.inf file in RAS versions 1.x) to make it compatible with virtually any modem's command set. For additional information on modifying the Modem.inf file, see the RAS Help topic "Modifying Modem.inf."

Command set compatibility between the local modem and the remote modem is not a requirement for RAS. Command set compatibility between the local and remote modem is only important if both modems are designed to be configurable by a command received from the other modem. For example, an administrator may call from home and issue a command to change the default settings during the next power up of the modem in the office; however, this specialized feature is not important during RAS communication.


RAS and Modem Modulation Standards

The modem modulation standards affect the telephone line speed compatibility between two modems, as shown in the following Table E.1. For two modems to communicate, their modulation standards must be compatible.

The modulation standard only defines the speed or permitted speed range between the modems. The speed between the computer and the modem can be different and depends on the serial hardware, the microprocessor speed in the computer, and whether or not hardware flow control or XON/XOFF software flow control is enabled.

Table E.1 shows the most popular modulation schemes in the left column and their corresponding speed range in bits per second (bps) in the right column.

Table E.1 Modulation Schemes and Modem Speeds

Popular modulation schemes | Modem-to-modem speed
V.22 (ITU-T (formerly CCITT) Standard) | 1200 bps
V.22 bis (ITU-T (formerly CCITT) Standard) | 2400 bps
V.32 (ITU-T (formerly CCITT) Standard) | 4800 to 9600 bps
V.32 bis (ITU-T (formerly CCITT) Standard) | 4800 to 14400 bps
V.fc and V.fast (Proprietary Modulation Schemes) | 2400 to 28800 bps
V.34 (ITU-T (formerly CCITT) Standard) | 2400 to 28800 bps

Figure E.2 shows that modulation standards take effect only on the modem-to-modem (DCE-to-DCE) link. Speeds between DTE and DCE are independent of modem modulation standards and often differ from the DCE-to-DCE speed. When speeds are different, hardware flow control or software flow control support is required so that data is not lost when transmission speed between the modems is less than transmission speed between the DTE and DCE, or when transmission between the modems is temporarily delayed due to retransmission of data that was corrupted during transmission. RAS versions 1.0 and 1.1 do not support hardware or software flow control. RAS versions 1.1a and later support hardware flow control.

Figure E.2 also displays the different modulation standards below the DCE-to-DCE link to which they apply. The column to the right of the center column displays the RAS clients' DCE-to-DTE speeds that occur in relation to the DCE-to-DCE speeds on the same row in the center column. Depending on your modem's capabilities, these speeds should be set in the corresponding RAS client versions that are displayed in the far right column. The highest supported DTE-to-DCE speeds that should be set on the RAS server (depending on its modem[s] capabilities) are displayed in the column to the left of the center column. The rightmost column lists the RAS client versions and the leftmost column lists the RAS server versions whose highest supported modulation rate corresponds to the modulation standard in the center column.

For example, in the "9600 bps, V.32" entry in the center column, the columns to the left and right show that the DTE-to-DCE speeds are also 9600 bps, and that this was the highest supported modulation mode of RAS versions 1.0 and 1.1.

Figure E.2 Modulation Standards and RAS

*RAS 1.0 and 1.1 were tested only with US Robotics V.32 bis modems at 14400 bps line speed. The modems were configured for V.42, V.42 bis, and V.32 bis. The OS/2 1.3 LAN Manager RAS 1.0 or 1.1 server had an intelligent DigiBoard installed.


Modem Speed and Modulation Change During a Connection

When connecting, modems do not always negotiate their fastest built-in modulation rate. Depending on the quality of the phone line connection and the quality of the modem hardware, two modems may negotiate a certain modulation standard, but may not use the maximum speed defined in that standard. For example, two V.34 modems, made by the same or different manufacturers, may negotiate a modulation rate in 2400-bps increments somewhere between 2400 bps and 28800 bps. They may agree to use 2400 bps because of noise in the telephone line.

Even though the line speed may be only 2400 bps, these V.34 modems are still using the V.34 modulation scheme. V.34 modulation also enables the modems to change the line speed dynamically during a call, in response to changes in the phone line quality. Other modulation standards may also enable the modems to connect at slower speeds, but may not enable the modems to dynamically adjust the line speed during a connection.

To change to a different modulation scheme, as opposed to just changing the speed within a modulation scheme while the modems have a connection, the modems need to support an error control protocol that supports this functionality. The non-standard MNP10 error control protocol is an example. However, the MNP10 protocol is needed only if the modem is not a V.34 modem and only if the modem needs to downshift from 4800 bps V.32/V.32 bis to 2400 bps V.22 bis (or upshift, accordingly).

RAS is usually oblivious to the dynamic speed changes. However, MNP10 modulation does change, and very slow connections that may occur with cellular modems or with low quality telephone lines may cause time-out problems in the RAS network protocols. Only Windows 95 supports cellular modem connections.

Table E.2 displays the fastest possible modulation mode likely to be negotiated when modems configured with the same or different modulation modes attempt to make a connection. This table assumes that modems with different modulation configurations and capabilities are configured to enable them to negotiate up or down to the highest modulation standard that the other modem supports. If both modems are not configured to negotiate to a different modulation, and their modulation settings differ, they cannot establish a connection.

For example, if a V.22 bis (2400 bps) modem and a V.32 bis (14400 bps) modem try to establish a connection and the V.32 bis modem is not configured to negotiate down to V.22 bis, the modems are unable to establish a connection. If the V.22 bis modem is not configured to negotiate down, but the V.32 bis modem is configured to negotiate down, then the modems can connect at V.22 bis (but not at V.22).

Table E.2 Modulation Modes

V.34 | V.fc/V.fast | V.32 bis | V.32 | V.22 bis | V.22
V.22 | V.22 | V.22 | V.22 | V.22 | V.22
V.22 bis | V.22 bis | V.22 bis | V.32 bis | V.22 bis | V.22
V.32 | V.32 | V.32 | V.32 | V.22 bis | V.22
V.32 bis | V.32 bis | V.32 bis | V.32 | V.22 bis | V.22
V.fc/V.fast (V.32 bis if V.fc/V.fast is not supported by answering modem) | V.fc/V.fast | V.32 bis | V.32 | V.22 bis | V.22
V.34 | V.fc/V.fast (V.32 bis if V.fc/V.fast is not supported by calling modem) | V.32 bis | V.32 | V.22 bis | V.22

Note

V.fc and V.fast are proprietary modulations that use modulation technology similar to V.34. Therefore, two V.fc or two V.fast modems from different manufacturers may not be able to connect at V.fc or V.fast, respectively, and may have to negotiate down to V.32 bis. Also, the use of the V.fc and V.fast names may be inconsistent between manufacturers, making it difficult for a buyer to determine compatibility between these modems. The V.34 standard does not include support for V.fc and V.fast. Therefore, some V.34 modems that do not support V.fc or V.fast fall back to V.32 bis when connecting with a V.fc or V.fast modem.


How to Make Unsupported Modems Work in pre-Windows NT 3.5 RAS Versions

How to Make Unsupported Modems Work
in pre-Windows NT 3.5 RAS Versions

You may be able to make RAS 1.1a, RAS for Windows for Workgroups 3.11, and RAS for Windows NT version 3.1 work with an unsupported modem (for example, a V.fc,V.fast, or V.34 modem, which is unsupported in these versions). If you want to use a V.fc, V.fast, or V.34 modem, it is recommended that you use a RAS client computer that has a 486 processor or later, and a serial port that has a 16550 UART chip or later. If problems occur, configure your modem to use V.32 bis.

The easiest way to get an unsupported modem supported under RAS for Windows for Workgroups 3.11 or RAS for Windows NT 3.1 is to obtain a modem that is supported in RAS for Windows NT 3.5 or 3.51. The following procedure assumes that you have a modem that is supported in Windows NT 3.5 or 3.51. If your modem is not supported in Windows NT 3.5 or 3.51 or you have RAS 1.1a, skip the following procedure, but read the rest of this chapter, and then follow the instructions in the Help topic "Modifying MODEM.INF."

To make an unsupported modem work

1. From the RAS for Windows NT 3.5 or 3.51 MODEM.INF file, copy the section that applies to your modem.

2. Load MODEM.INF into a text editor and append the copied section to the RAS for Windows for Workgroups 3.11 or Windows NT 3.1 MODEM.INF file.

3. Remove the lines that start with the following words from the section you appended:

DETECT_STRING=

DETECT_RESPONSE=

Note

RAS modem autodetection is not supported in RAS for Windows for Workgroups 3.11 and RAS for Windows NT 3.1.

4. Save MODEM.INF, and then quit the text editor.

5. Restart your computer.

6. Depending on whether you have Windows NT 3.1 or Windows for Workgroups 3.11, continue with the following corresponding section.

To make an unsupported modem work in Windows for Workgroups 3.11

1. Restart the RAS client software, and then choose Configure from the Setup menu.

2. Select your modem from the Device field, and then click OK.

RAS is now ready to use your modem.

To make an unsupported modem work in Windows NT 3.1

1. Start Control Panel, and then choose the Network icon.

2. Select Remote Access Service from the list of Installed Network Software, and then click Configure.

3. In the Remote Access Setup dialog box, click Configure.

4. In the Attached Device box, select the modem name that corresponds to the section you just copied to Modem.inf, and then click OK.

RAS is now ready to use your modem.


RAS and Modem Error Control Standards, Modem Data Compression Standards, and RAS Data Compression

Error control and modem compression are optional features that are available with most modems made in the last few years. For reliable connections, the local and remote modem error control standards must be compatible; and for improved throughput, their modem data and RAS data compression standards must be compatible.

Table E.3 shows the error control and modem data compression standards available with most modems. If you use modem compression, use the error control standard in the cell above the compression value. For instance, if you want to enable error control and modem compression, MNP4 is used with MNP5 or V.42 is used with V.42 bis. MNP4 error control cannot be combined with V.42 bis compression, nor can V.42 error control be combined with MNP5 compression. MNP4 and MNP5 are older standards and are less efficient than V.42 and V.42 bis.

Table E.3 Modem Error Control and Compression Protocols

Modem Error Control Protocol | MNP4 | V.42 w/ LAPM | MNP10 for cellular and land modem connections
Modem Compression Protocol | MNP5 (up to 2:1 compression) | V.42 bis (up to 4:1 compression) | V.42 bis or MNP5

(MNP = Microcom Networking Protocol)

Note

MNP10 is a new, nonstandard, reliable connection protocol not available on most modems. It was designed to overcome cellular modem signal distortion; however, it also makes land connections more reliable. It is not compatible with the Motorola MC2 cellular protocol, nor the AT&T EC2 cellular protocol, as of July 1995. MNP10 is combined with V.42 bis compression.

Figure E.3 illustrates modem error control standards, modem compression standards, and RAS software data compression. The Figure has three horizontal sections whose titles you can find in the center column directly below the modem-to-modem link graphic at the top of the Figure. To read the information in this Figure, decide which of the following three sections you want to focus on: Modem Error Control, Modem Data Compression, or RAS Data Compression. Then find that section in the center column and read the entries to the left and right in the same horizontal row. This enables you to determine whether the standard or feature also applies to the modem-to-computer link, and which RAS client versions and server versions support the modem or RAS feature in this section.

Figure E.3 Modem Error Control Standards, Modem Compression Standards, and RAS Software Data Compression

n RAS for Windows for Workgroups 3.11, Windows NT 3.1, Windows NT Advanced Server 3.1, Windows NT Workstation 3.5 or later, Windows NT Server 3.5 or later, Windows 95.

1 AsyBEUI applies to RAS versions 1.x only.

2 NetBEUI applies to RAS for Windows for Workgroups 3.11, and NBF applies to Windows NT versions 3.1, 3.5, and 3.51.

3 In case you have not disabled your RAS software compression on the Options menu of your RAS client, check the size of the RASMAC.386 files. If it has only 27193 bytes, it does not have RAS compression. If RASMAC.386 has 49209 bytes, then it has RAS compression support. The file with RAS compression support can be obtained on the Windows NT 3.5 U.S. Service Pack 2 CD in the SUPPORT\RAS directory.

4 In case you have not disabled your RAS software compression on the Options menu of your RAS client, check the size of the ASYNCMAC.SYS file. If it has only 33732 bytes, it does not have RAS compression. The releases of ASYNCMAC.SYS with 53188 bytes and 53716 bytes have RAS compression support. The files with RAS compression support can be obtained on the Windows NT 3.5 U.S. Service Pack 2 compact disc in the SUPPORT\RAS directory.

5 RAS 1.0 and 1.1 were tested only with US Robotics V.32 bis modems at 14400 bps line speed. The modems were configured for V.42, V.42 bis, and V.32 bis. The OS/2 1.3 LAN Manager RAS 1.0 or 1.1 server had an intelligent DigiBoard installed.


Modem Error Control

The first section of the preceding Figure E.3 shows that modem error control (MNP4, V.42 [LAPM], MNP10) standards take effect only between modems (DCE-to-DCE link). For RAS versions 1.0 and 1.1, these standards are not supported; however, in RAS version 1.1a and later these standards are activated.

MNP4 is the oldest and least efficient of the three error control standards; V.42 is newer and more efficient than MNP4; and MNP10 is the newest (nonstandard) protocol, although it is not available in many modems. MNP10 is designed to enable change of modulation modes during connections and to operate under extremely adverse environments where V.42 fails. Error control between computer and modem (DTE and DCE) is handled automatically by the RAS protocol by encompassing the entirety of the connection¾not only the connection between DTE and DCE, but the connection between RAS client and RAS server (DTE-to-DTE).


Modem Data Compression

The second section of Figure E.3 shows that modem data compression (MNP5, V.42 bis) standards take effect only between modems (DCE-to-DCE link). For RAS versions 1.0 and 1.1, these standards are not supported. However, if you are using RAS version 1.1a or later, you should activate modem compression (along with hardware flow control) if you are calling a Windows for Workgroups 3.11 or Windows NT RAS server. You should not activate modem compression if you are calling a RAS 1.0 or 1.1 OS/2 version 1.3 server with LAN Manager 2.1 or later. For more information, see the footnote 5 following Figure E.3.


RAS Data Compression

The third section of Figure E.3 shows that RAS data compression and decompression happen between computers (DTE-to-DTE link) without involving modem compression. The modem receives RAS-compressed data and just passes it along to the other modem. Thus, modem compression is not involved in this part of the Figure. With RAS data compression, MNP5 modem compression must be turned off in order to prevent redundancy, because data that are already highly compressed by RAS might grow larger before transmission if MNP5 modem compression is enabled simultaneously.

RAS data compression can be four times as efficient as MNP5, and about twice as efficient as V.42 bis modem data compression, unless a previously compressed file is transmitted. V.42 bis can detect whether it is about to expand data that it is supposed to compress. V.42 bis can also automatically suspend itself until the data is once again compressible. It is advised that you leave V.42 bis enabled at all times, but not use MNP5 with RAS data compression.

To avoid data loss due to data buffer overflow, you must enable hardware flow control in the RAS client whenever you are using modem compression or RAS data compression. You may turn hardware flow control on in the RAS user interface of the following RAS versions: Windows for Workgroups 3.11, Windows 95, Windows NT versions 3.1, 3.5, and 3.51. RAS versions 1.0 and 1.1 do not support hardware flow control. RAS version 1.1a requires that a hardware flow control command be set in the Modems.inf file on the command.init line containing the modem initialization string for your modem.

Note

RAS 1.1a ships with the Mcomp.inf file that issues hardware flow control and maximum baud rate commands for all modems supported by that file. To use hardware flow control with a supported modem, you must save the Modems.inf file (which contains modem commands that disable hardware flow control) and copy the Mcomp.inf file to the name Modems.inf.


RAS and Unsupported Modems

If you have an unsupported modem or want to customize the Modem.inf file and want to use compression, and you are using RAS versions later than 1.x on the RAS server and client, it is recommended that you turn on V.42 bis modem compression and RAS software data compression. If you want to use RAS data compression, leave the most efficient error control protocol that is available on your modem turned on. For additional information, see the RAS Help topic "Modifying Modem.inf."

To use modem compression with an unsupported modem on the RAS 1.1a client (that does not have the RAS data compression feature), append a custom modem section to the MODEMS.INF file and create an initialization string that enables hardware flow control, V.42 bis compression, and V.42 error control, if available. Be sure to check that your modem is not already supported in the RAS 1.1a MCOMP.INF file that ships with RAS 1.1a. To create your custom modem section, model your section after an existing section in MCOMP.INF.


Modem Standard Combinations Supported by the Different RAS Versions

Modem Standard Combinations Supported by
the Different RAS Versions

Table E.4 is a historical view of the different RAS versions and the modem standard combinations they supported when they were released. Newer RAS versions support all down-level modem compression and error control combinations. The table shows only the most important standard combinations. If there is more than one column for a RAS version, the rightmost column displays the highest modem standards supported by that RAS version.

The leftmost column of that RAS version shows a combination of standards that may occur with less capable modems. For example, the highest modulation rate RAS 1.1a supported at the time of release is V.32 bis; this means it also supports V.32 and V.22 bis which were supported by RAS 1.1 and 1.0. Because this table is only a historical view, it does not reflect that an older RAS version can possibly support a newer modulation standard than is shown in the table. For example, the table shows RAS for Windows for Workgroups 3.11 as supporting only V.32 bis as the highest modulation scheme. This is because V.fc, V.fast, and V.34 modulation scheme modems did not exist yet and therefore were not available for testing. However, RAS for Windows for Workgroups 3.11 may work properly with a V.34 modem in the right configuration. To make it work properly, you may have to use a computer with one or more of the following components:

  • 486 or later processor
  • 4 MB of RAM
  • An asychronous serial board that has a 16550 UART chip

Table E.4 History of RAS Versions and Supported Modem Standards

RAS 1.0

RAS 1.1a*

RAS 1.1a*

RAS for Windows for Work-groups version 3.11

RAS for Windows NT versions 3.1, 3.5, and 3.51

Remote Network Access for Windows 95 (RNA)

Hayes AT, etc.

Hayes AT, etc.

Hayes AT, etc.

Hayes AT, etc.

Hayes AT, etc.

Hayes AT, etc.

V.22 bis (2400 bps) and V.32 (9600 bps)

V.32
(9600 bps)

V.32 bis (14400 bps)

V.32 bis

Windows NT 3.1: V.fc, V.fast
(28800 bps); Windows NT 3.5 and 3.51: V.34
(28800 bps)

V.34
(28800 bps)

Not Supported

MNP4 (may also use V.42)

V.42 with LAPM (may also use MNP4)

V.42 with LAPM (may also use MNP4)

V.42 with LAPM (may also use MNP4)

V.42 with LAPM (may also use MNP4)

Not Supported

MNP5 (may also use V.42 bis if V.42 is enabled)

V.42 bis (may also use MNP5 if MNP4 is enabled)

Use RAS data compression along with V.42 bis 1(may also use MNP5 with MNP4 enabled and RAS data compression disabled)

Use RAS data compression along with V.42 bis 1 (may also use MNP5 with MNP4 enabled and RAS data compression disabled)

RAS data compression is automatically used. Enable V.42 bis 1 (may also use MNP5 with MNP4 enabled)

*RAS 1.0 and 1.1 were tested only with US Robotics V.32 bis modems at 14400 bps line speed. The modems were configured for V.42, V.42 bis, and V.32 bis. The OS/2 1.3 LAN Manager RAS 1.0 or 1.1 server had an intelligent DigiBoard installed.

1 If an uncompressed file is transmitted between two Microsoft RAS computers, RAS software compression increases throughput significantly more than V.42 bis compression. Do not enable modem compression (MNP5) along with RAS software compression, because it may decrease throughput.

Note

RAS clients running version 1.0 or 1.1 on the MS-DOS platform should be upgraded to at least RAS version 1.1a, which can be obtained from Microsoft at no charge. RAS server version 1.0 and 1.1 on the OS/2 1.3 platforms were never updated. In general, for RAS 1.x versions on MS-DOS or OS/2 1.3, it is recommended that you upgrade to RAS for Windows for Workgroups 3.11, RAS for Windows 95, or Windows NT 4.0 because of improved performance, new features, and the new, easier-to-use interface.


RAS Communication Quick Reference

If you are a network administrator, consultant, or support engineer, you can use the following quick reference tables to gain a high-level perspective of how RAS works over a WAN connection. These quick reference tables are high-level diagrams that show you at what point which RAS client features (of any Microsoft RAS version to date) execute when you make a call to a Windows NT RAS server.


How to Read the Diagrams

Specifically, these diagrams show how a call flows from a RAS client over different media (telephone lines, an ISDN line, or an X.25 network) through third-party security (or other) devices into the RAS server's port (serial or ISDN) and through the RAS server's architectural software layers to the RAS server service and, eventually, the RAS server. For a specific RAS client, you can also see whether it supports modem pools and other third-party pre- or post-connect devices (via pre- and post-connect scripts in the Switch.inf file or RAS Terminal pop-up screens), whether it supports Pad.inf scripts for X.25 communication, and at what point during a call these scripts or Terminal screens execute.

The tables include the full path of all possible, but not necessary, events that can happen during a RAS call. To see the possible flow of events when a RAS client initiates a call to a Windows NT RAS server, first determine what type of communication medium you will be using: telephone lines, an ISDN line, an X.25 dial-up, or an X.25 with an Eicon card. Then, using the table specific to your situation, follow the path from the RAS client to the RAS server.


Information Not Included in the Diagrams

The diagrams do not show specific Windows NT RAS client security features for calling up third-party PPP or SLIP servers. To learn more about available Windows NT security features, see the Help topic "Configuring Security." Note that Windows NT RAS can function as a SLIP client, but not as a SLIP server.

The diagrams also do not show direct serial (null modem) connections. For additional information about null modem connections, see Appendix B, "RAS Cabling," in the Microsoft Windows NT Networking Supplement.


ISDN Notes

When you call from a RAS client by using ISDN, the Pre-connect script/Terminal and Post-connect script/Terminal options are not available. This is because there is no ISDN standard defined on how ASCII characters are to be transmitted. For a detailed explanation of ISDN, see the Microsoft Knowledge Base article "Integrated Services Digital Network (ISDN)" (Q99767).

Figure E.4 RAS Client using an ISDN Line

Figure E.5 RAS Client using Telephone Lines

1 RAS 1.x: no scripts or Terminal; Windows 95: no scripts
2 not in RAS 1.x
3 not in RAS 1.0

Figure E.6 RAS using X.25 (Client uses a modem)

Figure E.7 RAS using X.25 (Client uses an X.25 Eicon card)


Microsoft Remote Access Version Features

The following tables list the most important features of all RAS server and client versions that were released before October 1995. The first table lists the features of RAS server versions; the second table lists the features of RAS client versions.

Table E.5 RAS Server Versions

RAS version | Proprietary MS Protocol support | PPP support (protocols tunneled through PPP Protocol) | SLIP support (protocols tunneled through SLIP Protocol) | Medium
RAS 1.0 | AsyBEUI 1 | No | No | Serial
RAS 1.1 (no 1.1a available) | AsyBEUI | No | No | Serial; X.25
Windows for Workgroups 3.11 "Point-to-Point Server"; Supports only access to its own resources | NetBEUI, which is backward compatible with AsyBEUI | No, but third-party PPP TCP/IP software is available | No | Serial; ISDN; No internal X.25 board support
RAS for Windows NT 3.1 | Uses NBF 2 | No | No | Serial; ISDN; X.25
RAS for Windows NT 3.1 | Uses NBF | No | No | Serial; ISDN; X.25

Flow control support | Highest tested bps rate for modems (not ISDN lines) | Number of simultaneous RAS ports (incoming calls) supported | Types of modems tested
No | 9600 bps | 16 ports | Analog; Null Modem
No | 9600 bps (V.32) 3 | 16 ports (13 with x.25 card) | Analog; Null Modem
Yes | 19200 bps (using V.32 bis, V.42, and V.42 bis) | 1 port only (RAS client may access only server's local drives. No network access) | Analog; Null Modem
Yes | 57600 bps (using V.32 bis, V.42, and V.42 bis) | 1 port only | Analog; Null Modem
Yes | 57600 bps (using V.32 bis, V.42, and V.42 bis) | 64 ports | Analog; Null Modem

RAS version | Proprietary MS Protocol support | PPP Support (protocols tunneled through PPP Protocol) | SLIP Support (protocols tunneled through SLIP Protocol) | Medium
RAS for Windows NT 3.5 | Supports NBF | NBF, IPX, TCP/IP | No SLIP server functionality | Serial; ISDN; X.25
RAS for Windows NT 3.51 | Supports NBF | NBF, IPX, TCP/IP | No SLIP server functionality | Serial; ISDN; X.25
Remote Network Access for Windows 95 (RNA) | Supports NBF | NBF, IPX | No SLIP server functionality | Serial; No internal X.25 board support

Flow control support

Highest tested bps rate for modems (not ISDN lines)

Number of simultaneous RAS ports (incoming calls) supported

Types of modems tested

Yes

57600 bps (using V.34, V.fc/V.fast, V.42, and V.42 bis)

Windows NT 3.5 Server: 256 ports. Windows NT 3.5 Workstation: 1 port

Analog; Null Modem

Yes

57600 bps (using V.34, V.fc/V.fast, V.42, and V.42 bis)

Windows NT 3.51 Server: 256 ports. Windows NT 3.51 Workstation: 1 port

Analog; Null Modem; certain PCMCIA modems 4

Yes

57600 bps (using V.34, V.fc/V.fast, V.42, and V.42 bis)

1 port only (RAS client may access server's drive and network resources)

Analog; Null Modem; PCMCIA modems; certain cellular modems 5

A: Compatible with Windows NT 3.1, Windows NT Advanced Server 3.1, and Windows for Workgroups 3.11 RAS compression. To achieve RAS software compression compatibility with Windows NT 3.5 Workstation or Server clients, you must install Windows NT 3.5 SP2 on the Windows NT 3.5 Workstation or Server computer that is acting as the RAS client.

B: Compatible with a Windows NT 3.5 Workstation or Server RAS client. To achieve RAS software compression compatibility with Windows NT 3.1, Windows NT Advanced Server 3.1, or Windows for Workgroups 3.11 RAS clients, you must install Windows NT 3.5 SP2 on your Windows NT 3.5 Workstation or Server computer that is acting as a RAS server.

1 Used in RAS 1.x.

2 NetBEUI Frame Protocol (NBF) which is backward compatible with AsyBEUI and NetBEUI (Windows for
Workgroups 3.1)

3 Modem error control (MNP4, V.42) and modem compression (MNP5, V.42 bis) are not supported, with the following exception: 19200 bps was tested with US Robotics V.32 bis modems and an intelligent DigiBoard on a server running OS/2 version 1.3 with LAN Manager 2.1 and RAS 1.1 using V.42 error checking and V.42 bis modem compression.

4 Consult the Windows NT 3.51 Hardware Compatibility List (HCL) for a listing of supported PCMCIA modems. If your modem is not listed, you can check the Windows NT 3.51 Modem.inf file contents to see whether your PCMCIA modem was included after the HCL was printed.

5 Consult the updated Windows 95 Hardware Compatibility List (HCL) on the Microsoft Internet Web server.

Table E.6 RAS Client Versions

RAS version | Proprietary MS Protocol support | PPP Support (protocols tunneled through PPP Protocol) | SLIP Support (protocols tunneled through SLIP Protocol) | Medium
RAS 1.0 | AsyBEUI 1 | No | No | Serial
RAS 1.1 | AsyBEUI | No | No | Serial; X.25
RAS 1.1a | AsyBEUI | No | No | Serial; X.25
RAS 1.0 | AsyBEUI | No | No | Serial
RAS for Windows for Workgroups 3.11 | NetBEUI; compatible with AsyBEUI | No, but third-party PPP TCP/IP software is available | No | Serial; ISDN; X.25 dial-up only 3
RAS for Windows NT 3.1 | Uses NBF 2 | No | No | Serial; X.25; ISDN
RAS for Windows NT Advanced Server 3.1 | Uses NBF | No | No | Serial; X.25; ISDN
RAS 1.1 | AsyBEUI | No | No | Serial; X.25

Flow control support |  | Support for scripts to interact with third party devices (X.25 dial-up and security hosts) |  | Interactive Terminal screen 5 |  | Highest tested bps rate for modems (not for ISDN) |  | Types of modems tested
No |  | No |  | No |  | 9600 bps |  | Analog; Null Modem
No |  | X.25 dial-up: Use PAD.INF |  | No |  | 9600 bps (V.32) 4 |  | Analog; Null Modem
Yes |  | X.25 dial-up: Use PAD.INF |  | No |  | 19200 bps (tested with V.32 bis, V.42, and V.42 bis enabled |  | Analog; Null Modem
No |  | No |  | No |  | 9600 bps |  | Analog; Null Modem
No |  | X.25 dial-up: Use PAD.INF |  | No |  | 9600 bps 4 |  | Analog; Null Modem
Yes |  | X.25 dial-up: Use PAD.INF; Third-party intermediary security devices: Use SWITCH.INF file |  | Yes |  | 19200 bps |  | Analog; Null Modem
Yes |  | X.25 dial-up: Use PAD.INF; Third-party intermediary security devices: Use SWITCH.INF file |  | Yes |  | 57600 bps (using V.32 bis, V.42, and V.42 bis) |  | Analog; Null Modem
Yes | X.25 dial-up: Use PAD.INF; Third-party intermediary security devices: Use SWITCH.INF file |  | Yes |  | 57600 bps (using V.32 bis, V.42, and V.42 bis) |  | Analog; Null Modem

RAS version

Proprietary MS Protocol support

PPP Support
(protocols tunneled through PPP Protocol)

SLIP Support (protocols tunneled through SLIP Protocol)

Medium

RAS for Windows NT 3.5

Supports NBF

NBF, IPX, TCP/IP

TCP/IP

Serial; X.25; ISDN

RAS for Windows NT 3.51

Supports NBF

NBF, IPX, TCP/IP

TCP/IP

Serial; X.25; ISDN

Remote Network Access for Windows 95 (RNA)

Supports NBF

NBF, IPX TCP/IP

TCP/IP

Serial; X.25 dial-up only 3

1 Used in RAS 1.x.

2 NetBEUI Frame Protocol (NBF) which is compatible with AsyBEUI and NetBEUI (Windows for Workgroups 3.11)

3 Internal X.25 card not supported on Windows for Workgroups 3.11

4 Modem error control (MNP4, V.42) and modem compression (MNP5, V.42 bis) are not supported, with the following exception: 19200 bps was tested with US Robotics V.32 bis modems and an intelligent DigiBoard on a server running OS/2 version 1.3 with LAN Manager 2.1 and RAS 1.1 using V.42 error checking and V.42 bis modem compression.

5 Interactive Terminal screen can be invoked to log on to third-party PPP hosts or intermediary security devices.

6 Consult the Windows NT 3.51 Hardware Compatibility List (HCL) for a listing of supported PCMCIA modems. If your modem is not listed, you can check the Windows NT 3.51 Modem.inf file contents to see whether your PCMCIA modem was included after the HCL was printed.

Flow control support

Support for scripts to interact with third party devices (X.25 dial-up and security hosts)

Interactive Terminal screen 5

Highest tested bps rate for modems (not for ISDN)

Types of modems tested

Yes

X.25 dial-up: Use PAD.INF; Third-party intermediary security devices: Use SWITCH.INF file

Yes

57600 bps (using V.34, V.fc/V.42, and V.42 bis)

Analog; Null Modem

Yes

X.25 dial-up: Use PAD.INF; Third-party intermediary security devices: Use SWITCH.INF file

Yes

57600 bps (using V.34, V.fc/V.42, and V.42 bis

Analog; Null Modem; certain PCMCIA modems 6

Yes

Use SCRIPTER.EXE 0 for scripting connections with:- X.25 dial-up providers; third-party intermediary security devices; SLIP dial-up servers; PPP dial-up servers

Yes

57600 bps

Analog; Null Modem; PCMCIA modems; certain cellular modems i

A: Compatible with Windows NT, Windows NT Advanced Server 3.1, and Windows for Workgroups 3.11 RAS compression. To achieve RAS software compression compatibility with Windows NT 3.5 Workstation and Server RAS servers, you must install the Windows NT 3.5 SP2 on the Windows NT 3.5 Workstation or Server that is acting as the RAS server.

B: Compatible when calling a Windows NT 3.5 Workstation or Server that is acting as a RAS server. To achieve RAS software compression compatibility with Windows NT 3.1, Windows NT Advanced Server 3.1, or Windows for Workgroups 3.11 RAS servers, you need to install Windows NT 3.5 SP2 on your Windows NT 3.5 Server or Workstation that is acting as a RAS client.

0 Windows 95 ships with SCRIPTER.EXE in the \ADMIN\APPTOOLS\DSCRIPT directory. The Windows 95 PLUS! software package of tools contains an upgraded version of SCRIPTER.EXE. Note SCRIPTER.EXE does not support pre-connect scripts to communicate with modem pool equipment. Instead, check the Bring Up Terminal Window Before Dialing option in the Option dialog box of the Properties of your connection to communicate interactively with your modem pool or pre-connect device.

i Consult the updated Windows 95 Hardware Compatibility List (HCL) on the Microsoft Internet Web server*


Appendix F - Routers and Switches

As networks increase in size, powerful computers and sophisticated applications drive the need for greater network bandwidth, performance, and scalability. Users are concerned with sending and receiving data quickly and reliably.

This appendix first provides an overview of the routing and switching technologies. It then describes the routing and switching equipment selected and installed at Terra Flora, the fictitious case study described in Chapters 4 and 5 of this book, and gives the technical and business reasons for those choices.

Note Terra Flora is a totally fictitious corporation. The names of companies, products, people, characters, and data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted.


Routing

The routing process allows messages (or data packets) to be delivered from a node on one network to a node on another network using the most appropriate, efficient path (or route). Routing environments employ routers, which function at the network layer of the OSI model (described in Chapter 1 of this book).

Routers direct data packets to the proper network and deliver them to the appropriate node on that network. The router uses routing protocols, a set of rules governing the exchange of information between nodes, to direct packets to their destination. The sending node (referred to as source) and receiving node (referred to as destination) must use either the same protocols or a protocol converter in order to communicate. Routers also allow data packets to be transmitted over dissimilar networks, such as Ethernet, Token Ring, and FDDI, without having to be translated.

Determining the most appropriate, efficient path is protocol-specific. Some protocols determine the path by hop count, which is the number of routers between the source and the destination; other protocols determine the path by analyzing the available bandwidth and calculating which route provides the best quality of service.

In a routing environment, each physical destination must be uniquely identified. Most routing protocols are based on an addressing scheme that uses a network, and a node number that identifies each node.

When a computer on an internetwork wants to communicate with a node on another network, the network layer software creates a packet. The packet contains the data to be sent, the address of the sender (source address), and the address of the destination (destination address).

The following diagram illustrates how packets break down information, such as the sender, sender address, destination address, and data.

Figure F.1 Data Packet Structure

The packet is put inside the appropriate frame for transmission across the network.

The network layer software also determines whether the destination resides on the local network or another network. If the destination address is on another network, the data packet is sent to the router that is attached to the local network. When the router receives the data packet, it removes the frame encapsulating the data packet and examines the destination address of the network-layer packets to find on which network the node resides.

Figure F.2 Packet Routing Across Multiple Networks

The router then compares the network information to its routing table, which contains directions on how to get to various places on the internetwork. There can be a number of networks and routers between a source and destination. When the destination's network is found in the table, the router puts the network-layer packet into the appropriate frame for the next network over which the packet will be transmitted, and sends it to the next network in the direction of the destination node. Each router between the source and destination network functions in this manner.

When the router attached to the network containing the destination node receives the packet, it removes the frame encapsulating the network-layer packet and compares the destination network address to its routing table.

When the router determines that it is directly attached to the destination network, it examines the packet for the destination node number, which is compared to the router's Address Mapping Table. This table correlates the packet's network-layer address to the device's Media Access Control (MAC) address. When a match is found, the router puts the data from the packet into the appropriate frame and sends it to the destination node.


Switching

Switching uses temporary connections for routing information. This communications method is widely implemented in local area networks and provides better performance on the LAN than routers in two ways:

  • First, switches provide a means of directing a frame to the appropriate output port, typically using the data-link layer addressing. The hardware itself forwards the frame to the output port. Routers use software programs on the network to route frames. Because the data-link layer does not use software to forward frames to the proper route, performance is improved.
  • Second, switches improve performance by enabling communication between logical groupings of users. Only one communication at a time can take place in a routing environment. The computers must wait until the line is free to communicate. Switches act as bridges, allowing the messages to be routed from one port on the switch to another. There is no requirement to wait until the communication finishes before communicating.

Switching technology uses switches, which are multiport devices that create temporary paths to send frames directly to a device based on its MAC address. There are three basic switching technologies: Configuration, Frame, and Cell. Another technology, Frame-to-Cell translation, enables the migration to cell-based backbones without changes to the host network's interface.

Configuration switching, or port switching, allows individual ports to be assigned to individual segments within a multi-segmented network hub. This provides the equivalent of an intelligent patch panel for network centers and wiring closets. Port assignments are performed when devices are initially attached to networks. This type of switching offers the ability to segment networks quickly for better performance. Configuration switching operates at the physical level and is transparent to end systems and upper-layer protocols.

Frame switching is a connectionless technology that provides cost-effective bandwidth to the workgroup and to multiplexed, low-speed traffic from the wiring closet onto high-speed down links. Operating at the data-link layer, frame switches "learn" the destination MAC addresses of each attached computer. Through the MAC address of each received frame, the switch forwards the packet to the output port attached to the computer with the same MAC address. The output port can be directly attached to the computer, to a shared access segment with multiple users, or to another frame switch, which, in turn, is connected to the destination. Frame switching supports both Ethernet Frame switching and Token Ring switching. Ethernet Frame switching supports shared or dedicated 10-Mbps or 100-Mbps connections. A Token Ring switch, also referred to as a segment switch, is a high-capacity, high port-density frame-relaying engine that forwards data simultaneously, among all ports, at wire speed (4/16-Mbps).

Cell switching, also called asynchronous transfer mode (ATM), is a high-speed technology that switches fixed-length, 53-byte cells at speeds of 155-Mbps and higher. Designed to carry voice, video, and data traffic, cell switching supports asynchronous traffic. Cell switching also supports different classes of traffic: loss-sensitive, delay-sensitive, delay-variance sensitive, and various combinations of these.


Backbone Link Node

Backbone Link Node (BLN) is the Bay Networks multiprotocol router/bridge. The symmetric multiprocessor architecture of BLN satisfies the high-performance and availability requirements of backbone internetworks using, for example, 100BASE-T, FDDI, HSSI, ATM, and SNA. Its symmetric multiprocessor architecture uses multiple MC68060- and MC68040-based Fast Routing Engines (FRE), multiple dual PowerPC microprocessor-based ATM Routing Engine (ARE) processor modules, and Bay Networks 1-Gbps Parallel Packet Express (PPX). The BLN provides 300,000 pps forwarding performance when equipped with the MC68060-based FRE. The dual PowerPC-based ARE supports 155 Mbps full-duplex virtual network routing to provide connectivity between multiple virtual LANs over a single ATM interface.

The BLN supports 4 FRE/ARE processor modules, 16 LAN interfaces, and 32 serial interfaces. A BLN configured with symmetric multiprocessors, redundant LAN interfaces, processor interconnects, power supplies, and software image storage is completely fault resilient. A redundant router capability also provides another level of network fault tolerance.

28000 Series Ethernet/Fast Ethernet Switches

For bandwidth-intensive applications, the Bay Networks 28000 series of switches enhance existing Ethernet LANs and provide 2 gigabits per second (Gbps) of internal switching and scalable 10/100 megabits-per-second (Mbps) dedicated bandwidth to support high-demand networks. These features enable the switch to provide scalable, dedicated bandwidth to attached end users, shared-media segments, servers, and high-end workstations.

All 28000 series switches include two high-speed, front-panel expansion ports for supporting direct 200 Mbps, full-duplex connection to other switches. Up to seven 28000 switches can be linked in a single stack, providing a scalable solution. The 28000 switches support redundant links between devices, in which one link automatically assumes standby status to provide a backup data path in the event of a primary-link failure.

Optivity: Comprehensive SNMP-based Network Management

All Bay Networks routers, intelligent hubs, and high-speed switches are fully manageable through the industry's best and most sophisticated suite of integrated network management, Bay Networks Optivity Enterprise family of network management applications which includes:

  • Optivity LAN provides comprehensive switching hubs and remote troubleshooting of client/server problems.
  • Optivity ATM delivers management services for Bay Networks-based ATM networks.
  • Optivity Design & Analysis focuses on enterprise network planning, analysis, and reporting.
  • Optivity Internetwork performs real-time router performance monitoring and status reporting.


Routing and Switching on Terra Flora Networks

In Chapter 4 of this book, we proposed a plan for uniting the three independent and diverse networks of the fictitious company, Terra Flora. One of the company's main goals was to centralize all administration.

Note Terra Flora is a totally fictitious corporation. The names of companies, products, people, characters, and data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted.

Terra Flora elected to use Bay Networks products, which combine a distributed management support foundation with SNMP-based tools for comprehensive router configuration, monitoring, and control. They will implement the Bay Networks Switched Internetworking Service (BaySIS) architecture. This extensible switched internetworking architecture is comprised of four basic services¾transport, policy, operation, and design¾which are implemented across the enterprise network. In this way, Terra Flora will integrate multiprotocol routing, switching, and shared-media and wide-area solutions into a cohesive, switched topology, all managed by a single network management system.

The Bay Networks Access Stack Note (ASN) router has a stackable architecture. Up to four ASN units are supported in one stack. An ASN stack supports up to 40 network interfaces and 200,000 pps forwarding performance, providing a superior path for growth. The MC68040 processor in the ASN's integrated design maintains high forwarding and filtering rates, regardless of the number of protocols and network interfaces used, even when processing Simple Network Management Protocol (SNMP) management inquiries.

The ASN meets the connectivity needs of the Terra Flora remote branch offices by offering modularity and flexibility for building configurations. The ASN provides network connectivity through a selection of net modules and adapter modules. An ASN can support up to four net modules, such as 100BASE-T, 10BASE-T Ethernet, 4/16 Mbps Token Ring, FDDI, Synchronous, and ISDN BRI, to meet a wide variety of connectivity requirements. Wide-area services, such as PPP, X.25, Frame Relay, SMDS, HDLC encapsulation, and ATM DXI, are supported by the ASN synchronous interface.

The method used to accomplish this consolidation of resources and information is described next.

The following diagram of the network shows the NENTS40B0FO1, NENTS40DIV01, NENTS40ENT01, EUNTS4ENT01, and EUNTS40DIV01 servers running multi-provider router (MPR) software. MPR passes requests to the various network providers configured in the system. These servers are connected to a Bay Networks Backbone Link Node (BLN) router through T1 links.

Figure F.3 Remote Enterprise Multi-provider Routing

The BLN creates a multi-protocol, collapsed, WAN backbone that provides a centralized wide-area infrastructure. The BLN is also connected to another BLN over a T3 link which is attached to two Bay Networks 28000 Series Fast Ethernet switches to form a multiprotocol LAN backbone. These two switches appear logically on the Terra Flora network diagram as three switches. One 28000 switch connects to the Terra Flora Enterprise level; the second 28000 switch connects to the Terra Flora Division, Department, and Desktop levels.

The ASN is connected to the first BLN by means of a dedicated leased line to provide access to branch servers and corporate systems. The Bay Networks router is configured to support a dial-on-demand feature, which is used when additional capacity is required between the corporate and remote regional offices. For example, during monthly end processing, transmission of data frequently exceeds the 128K capacity of the leased line. The Bay Network's dial-on-demand feature then establishes a second connection to provide additional bandwidth.

Recovery from leased line failure is provided through the ASN dial backup feature, which provides a two-point, fault-tolerance measure. Two lines are configured at Terra Flora. The second line is activated or used only when the first line goes down. This means that although two lines are available, usage charges apply only to the line that is being used. This reduces operational costs by delivering the connection only when needed and ensuring continued operation in the event of a network failure.

The entire network infrastructure is managed by the Bay Networks Optivity network management tools. These tools enable the network manager to configure the routers and switches, monitor and evaluate the network, and react to problems on the network from a central console.

The collapsed WAN backbone interconnects the Terra Flora LANs and computing devices across long distances by way of the T1 and T3 links. The LAN backbone ensures that traffic is directed to the destination over the best possible route and, when coupled with the switches' dedicated high-speed connections, ensures high data throughput. Because routing is employed on both the LAN and WAN backbones, all resources, such as nodes, servers, and computers, can interoperate, regardless of the type of network they are on and the distance between them.

Because of this connectivity, users at the New York retail store now have access to the applications and records contained in servers NENTS40B0FO1, NENTS40DIV01, NENTS40ENT01, EUNTS4ENT01, and EUNTS40DIV01, as well as to all information and applications at the Enterprise, Division, Department, and Desktop levels.

Security measures can be put in place in the router to block access to particular portions of the network. For example, filters can be configured in any of the BLNs to drop data destined for a network based on source address or destination address. The data packet information is examined and, if it is being sent to a specific server, the data will be discarded, thus limiting access to the network.

In the network diagram, the routers allow access from regional remote retail stores to corporate resources. Data is transmitted from these remote locations over WAN links, ensuring that individuals in the corporate and regional offices have needed information to satisfy current and future customer needs. This information is also passed to the appropriate corporate offices to maintain records, ensuring that all stores have adequate merchandise to sell to the consumer. Sales information from the retail stores can be sent in a timely fashion to the Enterprise and Division computers for processing inventory management, billing purposes, and so forth.

Stocking information, changes in products, sales incentive programs, advertising literature, and other information can be easily transmitted from corporate headquarters to the retail stores and all other remote Terra Flora sites over the internetwork.

The routers determine the best possible paths for sending data and avoiding breakdowns in communications. Through the router's lookup table, changes in the network are reported to the routers and the tables are updated with information about the new configuration. This enables IP traffic to be rerouted if, for example, a network change prevents the sent message from reaching its destination. This ensures continued communications.

Corporate data, such as employee lists, resource materials, and accounting facilities, are also accessible from anywhere no the internetwork through routing. Authorized users can access this information from their offices and interoperate with others around the corporation, using a variety of applications.

The Bay Networks Optivity console functions as a centralized point of administration for managing all network resources. Management servers offer a number of services including Logon Authentication, replicated User Account databases, centralized Network services, Name Resolution services, and Backup Services at the Enterprise level. These provide a consistent, master copy of common information and resources. A centralized architecture of file and print application servers is in place to provide heterogeneous file and print interfaces, integration services, backup services, and intranet services. All of these servers are accessible throughout the internetwork through the routers.

The configuration of the Bay Networks equipment is as follows:

BLN Base Unit with:

  • Quad-port Ethernet Intelligent Link Module with 32 MB memory
  • Single-port High-Speed Serial Interface (HSSI) Intelligent Link Module
  • Quad-port Synchronous Intelligent Link Module with 32 MB memory
  • Dual-port Multichannel T1 Intelligent Link Module
  • Backbone Node Corporate Software Suite Version 10.0

BLN Base Unit with:

  • Quad-port Ethernet Intelligent Link Module with 16 MB memory
  • Single-port High-Speed Serial Interface (HSSI) Intelligent Link Module
  • Quad-port Synchronous Intelligent Link Module with 16 MB memory
  • Single-port Multichannel T1 Intelligent Link Module with 8 MB memory
  • Backbone Node Corporate Software Suite Version 10.0

28000 Series Switch

  • Model 28115 Fast Ethernet Switch
  • 16-port 10/100 Ethernet Switch

ASN Base Unit

  • Dual Ethernet Net Module
  • Dual Synchronous Net Module
  • Multimode FDDI Net Module
  • 32 MB DRAM
  • ASN Corporate Software Suite Version 10.0

Network Management Software

  • Optivity for OpenView (MS-DOS-compatible version)


Appendix G - NetBIOS Names

Microsoft networking services running on a Windows NT-based computer are identified by using NetBIOS names. NetBIOS names can be used to identify a unique computer or a special group of computers. NetBIOS names are 16 characters in length and the 16th character is a special character used by most Microsoft networking services. Various networking service and group names are registered with a WINS server by direct name registration from WINS-enabled computers or by broadcast on the local subnet by non-WINS enabled computers.

The nbtstat command is a utility that you can use to obtain information about NetBIOS names. In the following example, the nbtstat -n command produced this list of registered NetBIOS names for user "Davemac" logged on to a computer configured as a primary domain controller and running under Windows NT Server with Internet Information Server.

Name | 16TH |  | Type |  | Description
DAVEMAC1 | <00> |  | UNIQUE |  | workstation service name
DAVEMAC1 | <20> | UNIQUE |  | server service name
DAVEMACD | <00> | GROUP |  | domain name
DAVEMACD | <1C> | GROUP |  | domain controller name
DAVEMACD | <1B> | UNIQUE |  | master browser name
DAVEMAC1 | <03> | UNIQUE |  | messenger name
INet~Services | <1C> | GROUP |  | Internet Information Server group name
IS~DAVEMAC1.... | <00> | UNIQUE |  | Internet Information Server unique name
DAVEMAC1+++++++ | <BF> | UNIQUE |  | network monitor name

NetBIOS Unique Names

The following table lists the default 16th byte value appended to unique NetBIOS computer names by various Microsoft networking services.

Table G.1 16th Byte Character for Unique Names

16th Byte | Identifies
<00> | Workstation service name. In general, this is the name that is referred to as the NetBIOS computer name.
<03> | Messenger service name used when receiving and sending messages. This is the name that is registered with the WINS server as the messenger service on the WINS client and is usually appended to the computer name and to the name of the user currently logged on to the computer.
<1B> | Domain master browser name. This name identifies the primary domain controller and indicates which clients and other browsers to use to contact the domain master browser.
<06> | RAS server service
<1F> | NetDDE service
<20> | Server service name used to provide sharepoints for file sharing.
<21> | RAS client
<BE> | Network Monitor agent
<BF> | Network Monitor utility

NetBIOS Group Names

The following table lists the default 16th byte character appended to commonly used NetBIOS group names.

Table G.2 Default 16th Byte Character for NetBIOS Group Names

16th Byte

Identifies

<1C>

A domain group name, which contains a list of the specific addresses of computers that have registered the domain name. The domain controller registers this name.

WINS treats this as a domain group, where each member of the group must renew its name individually or be released. The domain group is limited to 25 names. When a static 1C name is replicated that clashes with a dynamic 1C name on another WINS server, a union of the members is added, and the record is marked as static. If the record is static, members of the group do not have to renew their IP addresses.

<1D>

The master browser name that is used by clients to access the master browser. There is one master browser on a subnet. WINS servers return a positive response to domain name registrations but do not store the domain name in their databases. If a computer sends a domain name query to the WINS server, the WINS server returns a negative response. If the computer that sent the domain name query is configured as h-node or m-node, it will then broadcast the name query to resolve the name.

<1E>

A Normal group name. Browsers can broadcast to this name and listen on it to elect a master browser. These broadcasts are for the local subnet and should not cross routers.

<20>

A special group name called the Internet group that is registered with WINS servers to identify groups of computers for administrative purposes. For example, "printersg" could be a registered group name used to identify an administrative group of print servers.

_MSBROWSE_,

Instead of a single appended 16th character, "_MSBROWSE_," is appended to a domain name and broadcast on the local subnet to announce the domain to other master browsers.


MS Windows NT Server 4.0 Resource Guide

This book is dedicated to creating self-sufficient system administrators!

Contributors to this book include the following:

Managing Editor
Sonia Marie Moore

Lead Technical Editor
Pamela Miller

Technical Editors
John Andrilla, J. Elise Ellinghausen, Kate Robinson, Megan Sheppard

Proofreader
Kimberly O'Neal

Writing Manager
Peggy Etchevers

Technical Writers
Janet Anderson, Janice Breyer, Peter Costantini, Chris Dragich, J. Elise Ellinghausen, Peggy Etchevers, Sharon Kay

Software Program Managers:
Louis Kahn, Ryan Marshall

Software Developer
Martin Holladay

Production Manager
Karye Cattrell

Production Lead
Nikole Faith

Production Team
Jay French, Patrick Ngo, Cathy Pfarr, Keri Segna, Jeff Weaver, Todd White

Indexers:
Jane Dow, Ronnie Maier, Barbara Sherman

Lead Graphic Designer:
Chris Blanton

Design Support Team:
Johnni Cutler, Flora Goldthwaite, Amy Iffland, Casey McGahan, Wendy Salvatori, Gabriel Varela, Sue Wyble, Jan Yeager

Technical Consultants:
Cliff Hudson, Eugene Baucom, Phillip Carver, Joseph Dadzie, Scott Field, Jerry Gallagher, Joseph Holman, Terence Hosken, Eric Hough, John Jacobs, Richard Lerz, Tom Lindley, Jim Livingston, Janice Marsh, Oshoma Momoh, Joseph Pagano, Jim Truchon, Tom White, David Winkler, and numerous other hardworking Windows NT Developers, Program Managers, and Product Support Specialists

Product Support Liaisons:
Roger Bruist, Todd Hafer

Technical Marketing Liaisons:
Ty Carlson, Robert Lilleness

Microsoft Corporation

Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation.

© 1995 Microsoft Corporation. All rights reserved.

Microsoft, MS, MS-DOS, XENIX, CodeView, and QuickC are registered trademarks of Microsoft Corporation in the USA and other countries.

Microsoft may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft.

IBM is a registered trademark of International Business Machines Corporation.

Intel is a registered trademark of Intel Corporation.

Lotus is a registered trademark of Lotus Development Corporation.

Tandy is a registered trademark of Tandy Corporation.

Document No. | xxxx
 | 12345-6

Printed in the United States of America.


Introduction

Welcome to the Microsoft® Windows NT® Server Resource Kit: Windows NT Server Resource Guide.

The Microsoft Windows NT Server Resource Kit for version 4.0 consists of three new volumes and a single compact disc (CD) containing utilities for both Windows NT Workstation and Windows NT Server. An online version of the new, comprehensive Windows NT Workstation Resource Guide is also available on the CD. Update books for the Windows NT Server Resource Kit will be released on a semi-annual basis. They will contain new information and major revisions of existing topics.

The Windows NT Server Resource Guide presents detailed information that is specific mainly to the Windows NT Server operating system, plus topics that are either new for version 4.0 or reflect issues that our Product Support people consider timely and important. This information is intended to be an in-depth, technical supplement to the printed and online documentation included as part of the Windows NT Server version 4.0 product. It does not replace that information as the source for learning how to use the product features and programs. It is also supplementary to the information presented in the Windows NT Workstation Resource Guide, which is available in online format on the CD.

This Introduction includes the following types of information you can use to get started:

  • The first section outlines the contents of this book, so that you can quickly find pertinent technical details.
  • The second section introduces the Windows NT Server Resource Kit CD.
  • The third section describes the support policy for the Windows NT Server Resource Kit.


About the Windows NT Server Resource Guide

This book includes the following chapters.

Part I, About Windows NT Server

Chapter 1, "Deploying Windows NT Server," discusses special considerations for deploying Windows NT Server 4.0. In general, you can deploy Windows NT Server using the techniques described for deploying Windows NT Workstation in Part I, "Windows NT Workstation Deployment," of the Windows NT Workstation Resource Guide.

Chapter 2, "Printing," describes the Windows NT printing architecture and flow of control, including printing from all possible network clients. Descriptions of each printing component, including the spooler and print server services, are included, as well as a printing troubleshooting guide.

Part II, Reliability and Recoverability

Chapter 3, "Disk Management Basics," describes managing and understanding disks to provide you with a basic understanding of disk hardware and how Windows NT accesses disks. The chapter also describes the Windows NT startup process so that you can troubleshoot problems effectively and recover from them.

Chapter 4, "Planning a Reliable Configuration," covers topics such as disaster planning, backup strategies, and mass storage strategies.

Chapter 5, "Preparing for and Performing Recovery," describes what information you should back up and how to use those backups to recover from problems.

Chapter 6, "Troubleshooting Startup and Disk Problems," discusses what you can do to isolate startup problems, along with possible causes of and how to recover from disk problems.

Chapter 7, "Disk, File System, and Backup Utilities," describes each of the utilities mentioned in the previous chapters and how to use them.

Part III, Windows NT Server Troubleshooting

Chapter 8, "General Troubleshooting," identifies tools that are available in Windows NT to help you troubleshoot problems. The chapter also contains information about troubleshooting hardware problems and how to use the information in the Registry to determine why services are not working correctly.

Index to this Windows NT Server Resource Guide.

Glossary is available online in the Windows NT Workstation Resource Guide.


Resource Kit Compact Disc

The CD that accompanies the Windows NT Server Resource Kit contains utilities that apply to information in the Windows NT Workstation Resource Guide, the Windows NT Server Resource Guide, the Windows NT Server Networking Guide, and the Windows NT Server Internet Guide. This new CD replaces all previous ones. It includes a collection of information resources, tools, and utilities that can make networking and working with the Windows NT platform even easier.

Note

The utilities on this CD are designed and tested for the U.S. version of Windows NT version 4.0. Use of these utilities on any other version of Windows NT may cause unpredictable results.

A large Help file with explanations and user actions for the majority of the messages included in Windows NT version 4.0, and a large Help file of Performance Counter Definitions are just two of the major items included on the Windows NT Server Resource Kit CD. Updates to these files and others will be provided, when available, on the Microsoft Internet web site for the Windows NT Resource Kits. See the Rktools.hlp file for the exact site address, as well as the addresses of other Microsoft information sites.

After installing the Windows NT Server Resource Kit, please refer first to the following three files:

  • The Readme.wri file, which contains a complete list of all the tools and utilities on the Windows NT Server Resource Kit CD and additional setup instructions for some of them.
  • Either the Rkdocw.hlp (for Windows NT Workstation) or the Rkdocs.hlp (for Windows NT Server) file, which provides a single entry point for all of the major components of the Resource Kit's online documentation.
  • The Rktools.hlp file, which provides an overview of the Resource Kit tools and utilities and basic instructions on how to use many of them, along with links to additional documentation and, in some cases, to the actual program files.

The most current corrections to those tools and utilities and their documentation, as well as the POSIX and Perl source code files, are available on the Internet at the following Microsoft FTP site:

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt40/

The Windows NT Server Resource Kit CD includes a wide variety of tools and utilities to help you work more efficiently with both Windows NT Workstation and Windows NT Server. The following notes describe some of the enhancements made to the existing tools and utilities and introduce new ones that have been added for this version 4.0 release.

Batch Tools

  • KiXtart 95, Kix32.exe, is a logon script processor and/or enhanced batch language for Windows NT and Windows 95 workstations in a Windows Networking environment. You can use it to do such things as display user information, connect to network resources, read/edit the Registry, and add/change program groups.

Computer Administration/Configuration Tools

  • SrvInstW is a wizard for installing and deleting services and device drivers. This is a GUI form of the Instsrv.exe application that now also has increased functionality for detailing service parameters.

Computer and Network Setup Tools

  • SysDiff.exe enables you to pre-install applications, including those that do not support scripted installation, as part of an automated setup.

Computer Diagnostic Tools

  • Remote Kill is a service with both GUI and command-line clients. It enables a user to enumerate and kill a process on a remote computer. It also combines some of the functionality of Tlist.exe and Kill.exe.
  • ShowAcls is a utility that enumerates the access rights for files, folders, and trees. It also allows masking to enumerate only specific ACLs.

Desktop Tools

  • Desktop Themes from the Windows 95 Plus Pack are included now along with several new Windows NT-specific themes. These themes include a variety of visual, sound, and symbolic components that can enhance the look and feel of your Windows NT 4.0 desktop. Each desktop theme includes a background wallpaper, a screen saver, a color scheme, and a set of sounds, cursors, icons, and fonts.
  • MultiDesk, Multidsk.exe, is a desktop switching program for Windows NT 4.0. It customizes the desktop wallpaper and colors, and separates executing programs into new desk spaces.

Disk/Fault Tolerance Tools

  • DiskProbe, Dskprobe.exe, is a sector editor for Windows NT Workstation and Windows NT Server that enables a user with local Administrator rights to edit, save, and copy data directly on the physical hard drive that is not accessible in any other way.
  • DiskMap produces a detailed report on the configuration of the hard disk that you specify. It provides information from the Registry about disk characteristics and geometry, the Master Boot Record, and the Partition Table for all the partitions on the disk.

File Tools

  • ForFiles is a utility that enables batch processing of files in a folder or tree. You can run a command or give arguments to certain files. For example, you can run the type command on all files in a tree with the *.txt extension. Or you could execute every batch file (*.bat) on the C:\ drive with the "myinput.txt" filename as the first argument.
  • LogTime is a utility that logs the date and time stamp for batch file calls.
  • SetX is a utility that sets User vs. System environment variables.

Internet and TCP/IP Services/Tools

  • Web Based Administration of Windows NT Server, WebAdmin, is an ISAPI DLL that will enable remote administration of Windows NT Server by means of shipping HTML browsers, such as Internet Explorer 2.0 and above, from Windows®, Macintosh, and UNIX platforms. Its purpose is to assist administrators when they do not have access to their traditional tools, such as when they are away from their normal workspace or "roaming."
  • dbWeb is a gateway between Microsoft Open Database Connectivity (ODBC) data sources and the Internet Information Server (IIS). You can use dbWeb to publish data from an ODBC data source and provide familiar World Wide Web (WWW) hypertext navigation. While allowing users to create queries, dbWeb enables you to filter the data and sources that users can access and display.
  • The Beta version of our Telnet Server, Telnetd.exe. You can use it to run command-line utilities, scripts, and batch files from operating system-independent clients. It is not intended to be a full, commercial-grade Telnet solution.

Network Diagnostic Tools

  • SrvInfo.exe is a command line utility that displays local or remote computer-configuration information, including such things as whether it is a Server or a Workstation, the version, domain, PDC, IP address, CPU type and revision, drives, file systems, available drive space, mappings, services and status, network cards and bindings, and system up time.
  • Updated and additional MIBs are included.

Network/Server Administration Tools

  • Group Copy, GRPCPY, is a utility that enables you to copy the usernames in an existing group to another group that is in the same or another domain or a Windows NT computer. You must have at least Account Operator privileges to the domains with which you want to work.
  • command-line session remotely, within which you may launch any other application. Few tools besides Remote Console run applications remotely. REMOTE is not a service, but simply redirects standard input and output, so console programs that take control of the video memory and the keyboard do not work with REMOTE. Along with RCMD and RSH, Remote Console offers you a new way to run consoles remotely and to take control of a CMD session.

Registry Tools

  • The Registry Entries Help file, Regentry.hlp, has been updated again for this newest version. The chapter in the Windows NT Workstation Resource Guide that corresponded to this Help file has been discontinued.
  • Over 10 new command-line Registry programs have also been added for searching, retrieving, and replacing keys in both local and remote Registries.

Tools for Developers

  • PULIST is a utility that enumerates system processes and dumps process owners and IDs. You can use it against local or remote computers.
  • Api Monitor, APIMON, is a utility that enables you to monitor the API calls that a process is making. This utility incorporates the functionality of the Application Profiler that will no longer ship with the Windows NT Workstation Resource Kit.
  • CpuStress is a utility that loads down the processor, which is useful for evaluating how a system performs under heavy usage.
  • Heap Monitor, HEAPMON, is a utility that enables you to view system heap information.

User Account Administration Tools

  • Delete Profile, DELPROF, is a utility that deletes user profiles on Windows NT.
  • SU now includes a GUI interface along with other major additions. SU enables you to start a process that is running as an arbitrary user.
  • AddUsers has been updated to include such things as home-directory creation, global and local group deletion, and the ability to set the parsing token for the input/output (I/O) file.


Chapter 1 - Deploying Windows NT Server

Windows NT Server can be deployed to a large number of computers in the same way that Windows NT Workstation is deployed. The tools and techniques for doing so are described in Part 1, "About Windows NT Server" and Appendix A, "Answer Files and UDFs" of the Windows NT Workstation 4.0 Resource Guide.

There are some issues to be considered when deploying Windows NT Server that are not a factor in deploying Windows NT Workstation. These include which licensing mode to use, whether the server is to be a domain controller, and server-specific services that you might want to install.

Answer files and Uniqueness Database Files (UDFs) provide most of the tools you need for specifying options while deploying Windows NT Server. These are described in Chapter 2, "Customizing Setup" and Appendix A, "Answer Files and UDFs" of the Windows NT Workstation 4.0 Resource Guide. In particular, see the end of Appendix A for answer file entries that apply only to Windows NT Server.


Choosing a Licensing Mode

When installing Windows NT Server, you must specify whether the server is licensed in "per seat" or "per server" mode. You can provide this information in an answer file, as described in Appendix A, "Answer Files and UDFs" of the Windows NT Workstation 4.0 Resource Guide. For the installation to be completely unattended, you must supply this information in the answer file.


Installing a Domain Controller

When installing Windows NT Server, you can specify that the server be a member of a Workgroup or a Domain, or you can set the computer to be a domain controller. For the installation to be completely unattended, you must supply this information in the answer file.

The answer file entries for adding a server to a Workgroup or Domain are the same as those for workstations. To set the computer to be a domain controller, add the entry described under "Installing a Domain Controller" and "Setting the Server Role" in Appendix A, "Answer Files and UDFs" of the Windows NT Workstation 4.0 Resource Guide.


Replacing a Primary Domain Controller (PDC)

If the primary domain controller (PDC) is not available, and you want to configure a new PDC rather than promoting an existing backup domain controller (BDC), a new security identifier (SID) will be created for the domain. If the old PDC is then brought back on-line, it will not be able to process logon requests because it does not know the domain SID. To use both servers on the domain, you will need to reinstall Windows NT on one of them, while the other is available as a PDC. For more information see Chapter 1, "Managing Windows NT Server Domains" of the Windows NT Server Concepts and Planning Guide.


Installing Specific Services

To install network services, you will need to create one or more sections in the answer file in which you list the service you want to install. You can give these section any name you want. The sections you create must be specified with a line in the [Network] section of the answer file. The syntax is as follows:

[Network] InstallServices = services_list_section[, services_list_section] . . .

Then, in the section you create, list the services you want to install. Parameters are provided in a third section, which you also create and give any name you want, as in the following example:

[Network] InstallServices = ServiceList [ServiceList] SNMP = SNMPParameters [SNMPParameters] Accept_CommunityName = MicrosoftCommunity Send_Authentication = YES Any_Host = NO Limit_Host = HostSystem ….. ….. …..

The value to the left of the equals sign in the section you create to list the services is the same as the key for the service in the Registry(SNMP in the [ServiceList] section, in this example). The values for the parameters are also the same as those used in the Registry. Registry entries are documented in Part 5, "Windows NT Registry," and in the online help.

The following table lists server-specific services and the key used to specify them:

Service Name | Key
Alerter | AlertNames
Browser | Browser
DHCP Server | DHCPServer
FTP Server | FTPsvc
Internet Server | InstallInternetServer
NetBIOS over TCP/IP | NetBt
NetLogon | NetLogon
Remote Access (RAS) | RemoteAccess
Server | LanmanServer
WINS | WINS


Fault Tolerance Issues

If you are installing Windows NT on a mirrored partition, you must disable mirroring before deployment, and then reestablish mirroring after installation is complete.

Mirrored partitions are a feature you may have implemented in an existing installation of Windows NT Server, in which a copy of a partition on one disk drive is maintained on another disk drive. If the primary disk fails, no data is lost, since all information written to the primary disk was also written to the secondary disk.


Chapter 2 - Printing

By using Windows NT Server as your network print server, you have a seamless way to print, no matter what operating systems your networked computers use. If your workstation computers are running Windows NT 4.0, network printing is as easy as "point and print." For Windows NT and Windows 95 workstation computers, you don't need to install a printer driver manually on the workstation computer before printing with Windows NT. Print resources seem to be provided automatically from each application.

Note Although you can certainly print locally from a Windows NT Server print server, this chapter concerns itself primarily with remote printing and regards the Windows NT Server as a dedicated print server. For information about printing locally from a print server, see the Windows NT 4.0 Workstation Online Resource Guide.

This chapter begins with a glossary of terms used throughout the rest of the chapter. The glossary is followed by an overview of the Windows NT printing process and the flow of control. After you have a clear picture of the printing process and are comfortable with the terms, you can move on to read in-depth descriptions of each component of the printing architecture based on the network protocols and operating systems of your networked computers. The chapter concludes with sections on print security, troubleshooting, and some common questions and answers.

For additional information about printing with Windows NT Server or Windows NT Workstation, refer to the following documentation.

Documentation Source | Descriptions
Microsoft Knowledge Base | An effective and consistent resource for troubleshooting printing problems.
Microsoft Technet | Microsoft White Papers, TechEd, and other articles are available on the Microsoft Technet CD.
Support Fundamentals for Windows NT, Chapter 13, "Printing with Windows NT" | A Microsoft Press self-paced training manual.


Glossary of Printing Terms

A print device is the actual hardware device that produces printed output—what you call a "printer" in casual conversation.

Print-device resolution is measured in dots per inch (DPI). The higher the DPI, the finer the resolution.

A printer, or logical printer, is the software interface between the operating system and print device. The printer determines how the document gets to the printing devices (for example, by means of a local port or to a remote print share) and to other parameters of the printing process. A single printer can send print jobs to multiple print devices, and multiple printers can send jobs to a single print device. For more detail about printers and print devices, see "Planning How Users Access Printers" in Microsoft Windows NT Server Concepts and Planninge. In the NetWare and OS/2 environments, this software interface is called a queue.

In Windows NT terminology, a queue is a group of documents waiting to be printed.

Print jobs are source code that contain both data and commands for print processing.

Print jobs are classified into data types based on what modifications, if any, the spooler must make to the job for it to print correctly. For example, one data type requires no modifications, whereas another data type requires the addition of a form feed to the end of the job.

The print spooler is a collection of dynamic-link libraries (DLLs) that receives, processes, schedules, and distributes print jobs.

Spooling is only one of the processes performed by the spooler. Spooling is the process of writing the contents of a print job to a file on disk. This file is called a spool file. In the event of power loss during printing, the spool file prevents loss of data so the print job can resume once power is restored. Despooling means reading the contents from a spool file and sending those contents to a print device.

Rendering means creating a print job. An application calls the graphics device interface (GDI). GDI takes the document information sent by the application, calls the printer driver associated with the target print device, and creates a print job in the printer language of the print device. The print device has "firmware" that interprets the submitted printer language and creates a bitmap for each page.

A print server is the computer that connects one or more print devices to the network and shares them with other networked computers. A print server can also be a special hardware device that connects a print device to the network with a net tap on one side and a parallel or serial port on the other side.

Although a Windows NT Workstation can function as a print server, and a Windows NT Server can function as a print client, this chapter considers the print server to be a Windows NT Server. For information about using a Windows NT Workstation as a peer-to-peer print server for a small LAN (10 or fewer connections), see the Windows NT 4.0 Workstation Online Resource Guide.

A downlevel server is a print server running a Windows product that is not Windows NT 4.0—for example, Windows for Workgroups or Windows NT 3.x.

Creating a printer means connecting to the print device, either over the network or over a serial or parallel port, naming the printer, and installing the printer driver. To create a printer, run the Add Printer wizard, and click the My Computer option. You'll be asked to install the printer driver and specify a port.

Connecting to a printer means connecting to the share on the computer that created the printer. To connect to a printer, run the Add Printer wizard, and click the Network printer option. You won't be required to install the printer driver. Only Windows NT and Windows 95 clients can "connect to" a printer shared out by a Windows NT 4.0 print server.

A print client is the computer that sends print jobs over the network to the print server. Print clients are sometimes also called client computers.

A client application is any application that creates a print job. The client can be an application on the print server or on a client computer on the network.

Network-interface printers are print devices connected directly to the network by means of their own network cards.

Print server services are software modules on the print server that receive print jobs and determine if the spooler should alter them. Different print server services support print jobs from various clients. For example, Services for Macintosh (SFMSRV) supports print jobs from Macintosh clients.

Printer drivers are software programs that enable applications to communicate fully and properly with print devices. Each print device can require unique codes and commnds to make available its special features, such as two-sided printing or custom paper sizes.

Anything described as local means that it exists on the same computer. For example, a print client seeks a printer driver locally (on the same computer) before downloading the driver from the print server.


Overview of the Printing Process

In the following overview of remote printing, Windows NT 4.0 Server is considered to be the print server. Some processes, or the software components that perform them, are slightly different for non-Windows NT print clients. For more details about different print clients, see "Print Clients" later in this chapter.

Figure 2.1 Windows NT Remote Printing Process

1. A user at a client computer chooses to print a document.

If the client is running any Windows operating system and is printing from a Windows application, the application calls the graphics device interface (GDI). GDI calls the printer driver associated with the target print device. Using the document information from the application and the print device information from the printer driver, GDI renders the print job in the printer language of the print device. The application then calls the client side of the spooler (Winspool.drv).

If the client is running a non-Windows operating system or is using a non-Windows application on a Windows operating system, another software component that functions similarly to GDI performs the same task.

2. The client computer delivers the print job to the print server.

If the client is running Windows NT, the client side of the spooler (Winspool.drv) makes a remote procedure call (RPC) to the server side of the spooler (Spoolss.exe), which makes a direct application programming interface (API) call to the router (Spoolss.dll). The router polls the remote print providers, and the Windows remote print provider (Win32spl.dll) makes an RPC to Spoolss.exe on the print server, which receives the print job over the network.

If the client is running another Windows operating system or is a Windows NT client who created a local printer port and redirected output to a network server (\\server\printer), the print job goes to the client computer's NetBIOS redirector. The redirector uses the protocol driver to send the job over the network to the print server's protocol, which delivers the job to the Windows NT Server service on the print server.

If the client is a UNIX computer or any computer running LPR software, the print job goes to the TCP/IP protocol, which sends it over the network to the print server's LPD service.

If the client is a Macintosh computer, the print job goes to AppleTalk, which sends it over the network to Services For Macintosh (SFMMON) on the print server.

3. The router or print server service receives the print job.

On the print server, print jobs from Windows NT clients using Windows applications are enhanced metafiles (EMF). Some print server services for non-Windows NT clients assign a data type and others leave the data type blank. Print jobs with no data type assume the default data type in the Print Processor dialog box on the print server. For more information, see "Data Types" later in this chapter.

4. The router or print server service passes the print job to the local print provider on the server (a component of the spooler), which spools the print job (writes it to disk).

5. The local print provider polls the print processors. When a print processor recognizes the job's data type, that print processor receives the print job and alters it (or not) according to its data type to ensure that the job prints correctly.

6. Control of the print job passes to the separator page processor, which adds a separator page, if specified, to the front of the job.

7. The job is despooled to the print monitor.

If the print device is bi-directional, the job first goes to a language monitor, which handles bi-directional communication with the printer and then passes the job to the port monitor.

If the print device is not bi-directional, the job goes directly to the port monitor, which transmits the print job to the print device or to another server over a specific communications channel.

8. The print device receives the print job, translates each page into a bitmap, and prints it onto paper or another medium.


Print Jobs

Print jobs are not simply data: They are source code that contains both data and the commands for processing the data. The client application (with the graphics engine and the printer driver) creates print jobs. For example, Microsoft Word 7.0 combines data objects such as text, fonts, and graphics with information from a printer driver to create source code for a document—the print job.


Data Types

Because each type of print client (for example, UNIX clients and Windows NT clients) creates print jobs a little differently, a variety of print server services are required to receive and prepare the jobs. Some print server services assign print jobs a data type, which tells the spooler whether and how to modify the print job in order to print correctly. Some services leave the data type blank (in which case the default data type in the Print Processor dialog box on the print server is assigned).

If you create a printer, the default data type is EMF (if the printer is a PCL printer) or RAW (if the printer is Adobe PostScript). To change the default data type, use the following procedure:

To change the default data type for a printer you have created

1. Click Start, and then click Settings.

2. Click Printers.

3. Click to select the printer for which you want to change the data type.

4. Click Properties on the File menu.

5. Click the General tab.

6. Click the Print Processor button.

7. In the Default Datatype list, click the data type.

8. Click OK in each dialog box.

The following sections describe the different data types.


EMF

Print jobs from Windows NT 4.0 clients are enhanced metafiles (EMF). Instead of the RAW printer data being generated by the printer driver, EMF information is generated by the Graphical Device Interface (GDI) before spooling. After the EMF is created, control is returned to the user, and the EMF is interpreted in the background on a 32-bit printing subsystem spooler thread and sent to the printer driver.

EMF files are more portable than RAW files. An EMF file can be printed on any print device, whereas a RAW file can be printed to only one print device model. In addition, the set of EMF files that represent all pages in a print job are typically smaller than a RAW file that contains the same print job.

The first portion of the print job's rendering is done on the client computer. The last portion is rendered on the print server. This is especially helpful when the print job is a very large file, because the client application is not tied up for the entire rendering time. This data type also ensures that fonts specified on the client computer are the same ones used by the print server.


RAW

The RAW data type tells the spooler not to alter the job at all—that the print job is ready to print as is. Most jobs from downlevel Windows clients are the RAW data type.


RAW [FF Appended]

This data type tells the spooler to assume the job is from an application that does not append a form-feed character (0x0C) to the end of each job. Without a trailing form-feed, the last page of the job does not print when sent to a PCL print device. The spooler appends a form-feed character to the end of the print job but makes no other alterations. None of the print server services supplied with Windows NT assign this data type, but you can set the default data type Print Processor dialog box to this type so that it affects jobs from Windows Network clients.


RAW [FF Auto]

This data type is similar to the RAW [FF Appended] data type, but RAW [FF Auto] tells the spooler to check for a form-feed character at the end of the job. It does not add a form feed if one is already present, and it makes no other alterations. None of the print server services supplied with Windows NT assign this data type, but you can set the default data type Print Processor dialog box to this type so that it affects jobs from Windows network clients.


TEXT

The TEXT data type tells the spooler that the job consists of ANSI text. The spooler uses the current print device driver to create a new print job that prints the text of the original job using the print device's factory default font, form, orientation, and resolution listed in the Document Properties dialog box. This is useful when the print job consists of simple text and the target print device (for example, a PostScript printer) cannot interpret simple text jobs.

Text files consist of numeric values from 0 to 255, where each value is mapped to a particular character or symbol. Several character-mapping schemes (character sets) are in common use, and text files contain no indication of which character set to use when displaying or printing the file. The TEXT data type assumes the ANSI character set, so it might print some characters incorrectly if the application that created the job does not use the ANSI character set. Most character sets are identical for the values 0 through 127, so this problem usually affects extended characters (those with values from 128 through 255).

The following table shows five examples in which common character sets use different numbers to represent the same character. The PC-850 character set is commonly used by MS-DOS®-based applications in Europe; ANSI is used by Windows-based applications; PC-437 is commonly used by MS-DOS-based applications in the United States; Roman-8 is the default PCL character set.

Character | PC-850 | ANSI | PC-437 | Roman-8
Lowercase C Cedilla | 135 | 231 | 135 | 181
Lowercase AE Diphthong | 145 | 230 | 145 | 215
Lowercase N Tilde | 164 | 241 | 164 | 183
Lowercase Eth | 208 | 240 | - | 228
Lowercase Eszet | 225 | 223 | 225 | 222


PSCRIPT1

This data type indicates that the print job consists of PostScript code from a Macintosh client and that the target printer is a non-PostScript print device. The spooler interprets the PostScript code and creates a bitmap of the page. GDI32 and the printer driver can convert the bitmap into the language of the target print device.


Print Devices

Print devices are the machines we call "printers." They produce hardcopy output by interpreting the printer language and creating a bitmap for each page.

Print devices have their own input and output channels; jobs can be directed to input channels such as parallel or serial cables or network adapters. Output can be produced on different media, including paper, film, or fabric.

Print devices have their own internal processors which can be proprietary or general-purpose (such as the Motorola 680xx-series chips in Apple LaserWriter devices). Incoming data is stored in the print-device RAM, which can range from a few bytes to a hundred megabytes. Each print device has software stored in ROM, called "firmware," which interprets the programming language of a print job's source code. Examples of programming languages are PostScript, PCL, and HP-GL/2.


Printer Drivers

Printer drivers are the software that enables an application to communicate with the variety of available print devices, regardless of the device type, model, or programming language interpreter.

In general, printer drivers are composed of three files that work together as a printer-driver unit:

  • A printer graphics driver. This file renders device driver interface (DDI) commands from the graphics engine to commands that a print device can understand. Each graphics driver renders a different printer language. For example, a Pscript.dll renders PostScript printer language.
  • A printer interface driver. This file provides the user interface you see when you configure a printer.
  • A characterization data file. This file provides information about the configuration capabilities of a specific make and model of print device, including what resolutions it is capable of, whether it can print on both sides of the page, and what paper sizes it can accept.

These three files work as a unit. For example, when you set up and configure a new printer, the interface driver queries the characterization data file and then displays the available choices. Then, when you print, the graphics driver queries the interface driver about your selections so that it can create the proper printer commands.

Printer drivers are generally not binary-compatible across hardware-processor platforms. Consequently, printer drivers must be installed on the Windows NT print server for each Windows NT client hardware platform. For example, when x86-based clients running Windows NT Workstation are served for printing by a Alpha AXP-based Windows NT Server, you must install printer drivers on the Alpha AXP-based print server.

The Windows NT and Windows 95 print client first attempts to use a local printer driver. If none is available, the Windows NT print server downloads the printer driver to the client computer's hard disk. The client application then uses its copy to create the print job.

In previous versions of Windows NT, printer drivers ran in user mode. With Windows NT 4.0, printer drivers run in kernel mode, thus reducing memory requirements and improving performance. For more information about user and kernel modes, see Chapter MESMegan E. Sheppard5 "Windows NT Workstation Architecture," in the Windows NT Workstation Resource Guide.

Note Print clients running Windows NT 4.0 won't be able to use printer drivers downloaded from a print server running an earlier version of Windows NT. You'll need to make sure that the client computer has the 4.0 printer drivers, or better yet, use 4.0 on your print servers. A print server running Windows NT 4.0 can supply earlier version printer drivers to downlevel Windows print clients, if necessary.

Platform-specific printer drivers are available for the following:

  • Intel x86-based computers running Windows NT 4.0, 3.5, or 3.51 and Windows 95
  • MIPS RISC-based computers running Windows NT 4.0, 3.5, or 3.51 and Windows 95
  • Digital Alpha AXP-based computers running Windows NT 4.0, 3.5, or 3.51 and Windows 95
  • IBM PowerPC running Windows NT 4.0, or 3.51 and Windows 95

Print devices can be classified as one of three types: raster, PostScript, or plotter. To support these three classes of print devices, Windows NT provides the following generic printer drivers:

  • Universal printer driver
  • PostScript printer driver
  • HP-GL/2 plotter driver


Universal Printer Driver

The Universal printer driver (Unidriver) is sometimes referred to as the raster driver because it supports raster graphics printing. The Unidriver can carry out requests on most types of printers. Each print device vendor provides a device-specific minidriver (called a characterization file) that works with the Unidriver to communicate with its print devices.

This driver includes support for 24-bit color, scaleable TrueType fonts, device fonts, compression-run length encoding (RLE), and Tag Image File Format (TIFF) version 4.0.MESMegan E. Sheppard It also includes mechanisms that provide for smaller, more efficient bitmaps. These mechanisms include ignoring whitespace and supporting rules. (Hewlett-Packard LaserJet and compatible print devices use rules to print repeating elements on a page—such as bullets in a list—by repeating the information from a single bit of source code.)

The Universal printer driver consists of the following component files:

  • Rasdd.dll is the printer graphics driver for printer languages based on raster (bitmap) images, including PCL and most dot-matrix printer languages.
  • Rasddui.dll is the printer interface driver.
  • Raster minidriver is the characterization data file. The filename for this component depends on the print device or printer family. Check the documentation that accompanies your print device.

The Windows NT Universal driver is a generic, text only (TTY) driver. It prints only text, and it prints it in the native font of the print device, regardless of any formatting in the original document.


PostScript Printer Driver

The Windows NT PostScript driver uses Adobe version 4.2-compatible PostScript printer description (.ppd) files. (Windows NT does not use the .wpd or .mpd files used by Windows 3.1). This driver supports key features, including binary transfer compression from Level II, resolution, and paper source.

The component files of the Windows NT PostScript printer driver are as follows:

  • Pscript.dll is the printer graphics driver.
  • Pscriptui.dll is the printer interface driver.
  • x.ppd is the PostScript printer description (PPD) characterization data file.

Note PPD files are the only printer driver files that are generally binary-compatible across processors and platforms.


HP-GL/2 Plotter Printer Driver

The Windows NT plotter driver supports a variety of plotters that use the HP-GL/2 language. Windows NT does not support HP-GL. The output from the Windows NT plotter driver requires a plotting device that can process all of the enhancements built into the HP-GL/2 language.

The Windows NT plotter driver consists of the following component files.

  • Plotter.dll is the printer graphics driver.
  • Plotui.dll is the printer interface driver.
  • x.pcd is the characterization data file.


Establishing Printers

With Windows NT 4.0 you can establish printers with the Add Printer wizard or by using Point and Print.

Windows NT 4.0 provides the Printers folder to manage printing. Within it, the Add Printer wizard simplifies the task of establishing printers You can open the Printers folder in the following ways:

  • Click Start, point to Settings, and then click Printers.
  • In My Computer, double-click the Printers folder.
  • In Control Panel, double-click the Printers folder.

To establish a printer with the Add Printer wizard

  • In the Printers folder, double-click the Add Printer icon.

The Add Printer wizard leads you through the process of setting up and configuring a printer. The only differences between establishing a network printer and a local printer are as follows:

  • If you are establishing a local printer, you must install a printer driver. This action "creates" the printer on your computer. You can share the printer with other network computers.
  • If you are establishing a remote printer, you must specify the path to the network printer or browse to find its network location. This action "connects to" the printer on the print server.

To install a printer using Point and Print

1. Open the Printers folder.

2. Double-click Network Neighborhood.

3. Click the print server.

4. Drag the printer icon to your Printers folder.

This action "connects to" the printer on the print server.


Creating vs. Connecting to a Printer

The method used to establish a printer on a client computer dictates the configuration of the client computer in relation to the printer. The following table details the various methods.

Connection Method | Windows NT Sending Software | Required Network Protocols | Windows NT Receiving Software
Connect to network printer in Add Printer wizard | Spoolss.exe | TCP/IP, NetBEUI, NWLink | Spoolss.dll
Create local printer in Add Printer wizard and Print To options for a UNC device | Windows NT Workstation Service (NetBIOS redirector) | TCP/IP, NetBEUI, NWLink | Windows NT Server service
Create local printer and Print To options for an LPR port | LPR (Lpr.exe) Port Print Monitor | TCP/IP | TCP/IP (LPD) Print Service
Create local printer using Chooser and Print To options for an AppleTalk device | AppleTalk Print Monitor | AppleTalk | Services For Macintosh

Notice that only Windows NT and Windows 95 client computers can actually "connect to" a network printer served by a Windows NT print server. When a Windows NT or Windows 95 print client initiates a print request, the required printer driver is downloaded from the Windows NT print server if it is not already on the client's hard disk. All other client computers must "create" the printer—that is, they must install the printer driver directly on their hard disks, specify a port, name the printer, and so on.

Windows NT and Windows 95 print clients can also create a remote printer served by a Windows NT print server. Each method has advantages and disadvantages. Connecting to a remote printer is easier and faster than creating one. If the Windows NT client has connected to a printer, the print job doesn't spool on the client machine, so no spool options are available. (Windows 95 clients always spool locally and again remotely.) The "connected" client also cannot queue print jobs locally. Creating a printer gives the user more control, but that control is not always needed.


Specifying Virtual Printer Memory

You can change the amount of virtual memory that your PostScript printer has available for storing fonts. The PostScript driver uses a default setting recommended by the printer manufacturer for virtual memory.

To determine the right value, copy the Testps.txt file (supplied with the Windows NT Resource Kit) to the printer, and use the recommended virtual memory value printed on the resulting page.

To change your PostScript printer's virtual memory

1. Click Start, point to Settings, and then click Printers.

2. Click to select the printer.

3. Click Properties on the File menu.

4. Click the Device Settings tab.

5. Double-click Available PostScript memory.

6. Type the value from Testps.txt in the Change Settings box.

7. Click OK.


Print Clients

Print clients send print jobs to a Windows NT print server. The print server services or the spooler receive the print job as an input/output (IO) request that must be directed to the appropriate system process.

Each print server service uses different logic to determine how the job should be altered. The following sections describe protocols, general architecture, and process logic for each of the following types of print client:

  • Windows NT network clients
  • Windows NT local clients

For information about printing locally see the Windows NT Workstation Online Resource Guide.

  • Windows 95 network clients
  • 16-bit Windows network clients
  • MS-DOS network clients
  • UNIX clients
  • NetWare clients
  • Macintosh clients

All Windows print clients receive printer alerts confirming successful prints or indicating errors. To disable printer alerts on a specific machine, add the following entry to that computer's [Network] section of the System.ini file:

SendPrintMessages=no

Note Disabling WinPopup does not disable printer alerts.


Windows NT Network Clients

Windows NT network clients can use any of the following network protocols to send print jobs to a Windows NT Server print server:

  • NetBEUI
  • NWLink
  • TCP/IP
  • AppleTalk

If the Windows NT client computer connects to a printer, it sends print jobs to the server by making remote procedure calls from the client's print router to the server's print router. If the client created the printer, the print server service handles delivery of the print job.

Windows NT print clients now use enhanced metafile (EMF) data type instead of RAW. EMF allows the print job to be spooled to the server and rendered at the server into the appropriate print format. Remote rendering significantly speeds up the client computer's return to task.

Windows NT network clients need not worry about printer drivers, because if the client doesn't have a needed driver, it is automatically installed on the client's hard disk from the Windows NT server when the client begins its print operation. If, however, the client computer is running Windows NT 4.0 and the server is running an earlier version, the printer drivers won't work. A Windows NT 4.0 print server can supply earlier version of printer drivers where necessary, but a Windows NT 4.0 client cannot use earlier versions of printer driver.


Windows 95 Network Clients

Windows 95 print clients send print jobs to a Windows NT print server by using one of the following MS Network client redirectors:

  • LAN Manager
  • Microsoft Network Client 3.0 for Windows

The MS-Network redirectors send jobs by using the following protocols:

  • NetBEUI
  • NWLink
  • TCP/IP

Windows 95 generates EMF data type, which always spools locally. Spool files are played back locally to generate RAW data type before being sent to the print server. The print server spools the RAW file again.

The Windows NT print server receives print jobs from Windows 95 clients through the Windows NT Server service.


16-bit Windows Network Clients

There is little difference between the different versions of the 16-bit Windows platforms. They all support printing from MS-DOS-based applications and from Windows-based applications by using the 16-bit printer driver installed on the computer. They typically send jobs to a Windows NT print server by using one of the following MS Network client redirectors:

  • LAN Manager
  • Microsoft Network Client 3.0 for Windows
  • Windows for Workgroups built-in redirector

The MS-Network redirectors send jobs by using the following protocols:

  • NetBEUI
  • NWLink
  • TCP/IP

The Windows NT print server receives the job through the Windows NT Server service, which typically does not alter the print job. 16-bit Windows clients might also run third-party software for sending jobs to other print servers, such as LPR software for sending print jobs to UNIX print servers. This software is often able to send jobs to Windows NT as well.


MS-DOS Network Clients

MS-DOS clients usually use an MS Network client redirector to send print jobs to Windows NT print servers. They typically use the NetBEUI or TCP/IP protocol, but they might also print with third-party software (such as an LPR utility). Some MS-DOS-based applications create print jobs that contain only ASCII text. Unlike Windows clients that share the same driver for a particular print device, those MS-DOS-based client applications contain an internal version of the driver for each specific print device. This internal driver might not be the correct version of the driver. Often you can modify the driver and printer settings within the MS-DOS-based application or by using an accompanying utility. Check the documentation for the application or utility.

MS-DOS-based applications might not be network-aware, meaning that the application does not allow for a network redirector to forward the print job over the network to a print server. Some network-unaware applications try to print by directly dictating to the parallel port hardware, or they might rely on MS-DOS to control printing and be unable to print correctly to a network print server. Other network-unaware applications assume that they have exclusive control of the printer and therefore don't properly terminate their print jobs. As a result, nothing else prints until the application terminates. You might need to consider upgrading to a network-aware application in order to print over the network.


UNIX Clients

Windows NT supports UNIX printing clients by providing the TCP/IP Print Server (LPD) service. This service can receive print jobs from UNIX systems or other operating systems—including Windows NT—that have LPR client software. The client software must support RFC 1179. This is problematic, because many systems do not support this specification. Others that claim to support it do not implement it entirely, or they supply private extensions to the specification that their users have come to rely on but that don't exist except on that system. For more information about how to correct problems printing from systems that don't comply with RFC 1179, see "Line Printer Monitor (Lpdmon.dll)" later in this chapter.

The LPR protocol does not pass detailed error status information back to the LPR client. If anything goes wrong, from severe problems (such as the server being too busy to process requests) to print device problems (such as running out of paper), the LPR protocol reports the same error condition.


NetWare Clients

NetWare clients use IPX/SPX-compatible transport to send print jobs over the network to the Windows NT print server. The server must have installed Microsoft File and Print Services for NetWare. This utility, which is a separate product from Windows NT, enables the NetWare client to see the Windows NT printers as print queues.


Macintosh Clients

Macintosh clients send jobs over AppleTalk to a Windows NT print server. To the Macintosh client, the Windows NT computer looks like another AppleTalk device in a zone—either an AppleShare print server or a standalone print device. On the Windows NT Server computer, the SFMSRV receives the jobs. For more information about SFMSRV see, "Services for Macintosh Service" later in this chapter, and "Services for Macintosh Print Processor (SFMPSPRT)" and "Macintosh Port Monitor (SFMMON)" later in this chapter.


Print Server Services

Print server services are the software on the Windows NT print server that receive print jobs from specific types of network clients, determine whether the spooler should alter them, and then send them to the spooler by calling the spooler application program interface (API).

Each print server service uses different programmatic logic and makes different assumptions about print jobs from its supported print clients. These differences are detailed in the sections describing each service.

Windows NT Server provides the following print server services:

  • Windows NT Server Service
  • TCP/IP Print Server Service—known as Line Printer Daemon (LPD)
  • Services For Macintosh (SFMSRV)

In addition, other print services may be installed, such as:

  • Microsoft File and Print Services for NetWare (FPNW)

The following table lists each print server service and the type of print client processed by the service.

Service | Registry Name | Supported Clients
Windows NT Server service | Server | MS Network clients using NetBIOS redirectors on MS-DOS, Windows, Windows for Workgroups, or Windows NT computers
Services for Macintosh | Sfm | AppleTalk clients on Macintosh computers
TCP/IP Print service | Lpdsvc | LPR (line printer) clients on UNIX or Windows NT computers where the TCP/IP protocol is used
File and Print Services for NetWare | FrnwMESMegan E. Sheppard | Computers running NetWare client software where IPX/SPX compatible transport protocol is used


Windows NT Server Service

The Windows NT Server service receives jobs from applications and computers that are using the MS Network client and NetBIOS redirectors. This includes print clients using any of the following:

  • Windows NT

The Windows NT Server service receives jobs from Windows NT clients only if the client has created the printer in his or her own machine. If the client has connected to the printer, the print job goes directly to the server's spooler. For more information about creating versus connecting to a printer, see "Creating vs. Connecting to a Printer" earlier in this chapter.

  • LAN Manager
  • MS Network Client (often used on clients running MS-DOS alone or MS-DOS with Windows Versions 3.0, 3.1 or 3.11)
  • Windows For Workgroups
  • Windows 95

The Windows NT Server service does not set the data-type value when it submits the print job to the spooler. Instead, the spooler uses the default data type specified in the Print Processor dialog box on the print server. You can change the default data type. For more information, see "Data Types" earlier in this chapter.

Note If you select EMF or PSCRIPT1, the print spooler ignores this data and instead uses the RAW data type to process print jobs. Detailed information on print spooler processing of data types is provided later in this chapter in the "Print Processors" section.


TCP/IP Print Service (LPD)

The TCP/IP Print service is generally referred to as LPD, which stands for line printer daemon (or "service"). LPD receives print jobs from line printer remote (LPR) clients. LPR clients are often on UNIX systems, but LPR software exists for most operating systems, including Windows NT.

LPR is one of the network protocols in the TCP/IP protocol suite. It was originally developed as a standard for transmitting print jobs between computers running Berkeley UNIX. The LPR standard is published as Request For Comment (RFC) 1179. Previous versions of Windows NT supported TCP/IP printing as documented in RFC 1179, which describes an existing print server protocol widely used on the Internet for communicating between line printer daemons but does not specify an Internet standard. Different implementations support different options.

Windows NT 4.0 has added enhancements to support the most popular and requested options. Windows NT now suppots multiple data files per control file, and when used in "print through" mode as an intermediate spooler, it correctly passes the hostname parameter through the Windows printing subsystem. Windows NT 3.5x sent all TCP/IP print jobs from Windows NT computers from TCP ports 721 through 731. If enough jobs were sent in quick succession the ports could become a bottleneck causing a delay. For Windows NT 4.0 LPR print jobs are sourced from any available reserved port between 512 and 1023.

The LPR protocol does not pass detailed error status information back to the LPR client. If anything goes wrong, from severe problems (such as the server being too busy to process requests) to print-device problems (such as running out of paper), the LPR protocol reports the same error condition.

LPD receives jobs from LPR clients and submits them to the spooler. LPR clients always send a "control file" (actually, a data structure within the print job) containing administrative information with each print job. LPD assigns a data type based on the control commands in that control file.

If the client sends the f, o, or p control command, the LPD assigns the TEXT data type to the print job—which tells the spooler to edit the job to make sure it prints. If the client sends the l control command, the LPD assigns the RAW data type to the print job—which tells the spooler the print job needs no editing to print correctly. For more detail about data types, see "Data Types" earlier in this chapter.

Control commands are documented in the LPR specification, Request For Comment (RFC)1179, sections 7.17 through 7.29. For detailed information about RFC 1179, refer to the Windows NT Knowledge Base article, "Text of RFC1179 Standard for Windows NT TCP/IP Printing," reference number Q124734.

Note Notice that all the control commands defined in RFC 1179 are case sensitive. Notice also that many printer languages, including PCL, rely heavily on the ESC control character, which the f control command causes to be filtered from the print job. Do not use the f control command when sending print jobs that contain printer commands.

Because LPD assigns a data type explicitly, the default data type found in the Print Processor dialog box has no effect on print jobs received by LPD. To change the behavior of LPD, you must reconfigure the LPR client application to send a different control command with the print job. To reconfigure a LPR client application, consult the documentation for the application.


File and Print Services for NetWare

Microsoft File and Print Services for NetWare (FPNW) is a Windows NT Server utility that makes Windows NT Server look like a NetWare 3.x-compatible file and print server to computers running NetWare client software. Windows NT Server integrates into NetWare environments with IPX/SPX Compatible Transport.

Using FPNW, NetWare clients can print to printers attached to Windows NT print servers or to NetWare-compatible printers attached directly to the network. The Windows NT printers appear as print queues on a NetWare network. To create printers, the NetWare client should select LPT1 port for a printer attached to the Windows NT print server. For a network-attached printer, the clients selects either NetWare_Pserver_0 or NetWare_Pserver_1 port.


Services for Macintosh Service

The Services For Macintosh service (SFMSRV) receives print jobs from Macintosh clients. From the client's perspective, a printer shared through this service looks just like a share on an AppleShare server or a stand-alone AppleTalk print device.

The SFMSRV assigns the RAW data type to all jobs targeted to PostScript printers and also assigns the PSCRIPT1 data type to all jobs targeted for non-PostScript print devices. For additional information about processing of Macintosh print jobs, refer to the section "Services for Macintosh Print Processor (SFMPSPRT)" later in this chapter.


Print Spooler

The preceding sections described network print clients, print server services, print jobs, data types, and print devices. These are entities at the beginning and end of the printing process. The following sections describe the Windows NT print spooler components and the processing that takes place on a Windows NT print server after the print job is created and before the print job reaches the print device.

The following figure shows the main spooler components used to process jobs on a Windows NT print server. Each component uses the services of the component directly below it.

Figure 2.2 Print Spooler Components

As shown in the figure, the components below the client and above the print device are collectively called the spooler. The spooler is a series of 32-bit virtual device drivers and DLLs consolidated into a single architecture. It provides smooth background printing by using background thread processing. This means that the spooler passes data to the printer only when the printer is ready to receive more information. In Windows NT, the spooler components are implemented as a service that you can stop and restart from the Services icon on the Control Panel or from the command line by using the Net Stop Spooler and Net Start Spooler commands.

Important If you stop the spooler service, you will not be able to print until you start it again.

The spooler components reside on both the Windows NT print server and on the Windows NT client computer. Client computers running a different operating system might have different components, and they might interact differently with the Windows NT print server's spooler components. The following table lists the components of the Windows NT spooler:

Spooler Component | Description
Router | Winspool.drv, Spoolss.exe, Spoolss.dll.
Local Print Provider | Localspl.dll
Remote Print Providers | Win32sp.dll for Windows print servers. Nwprovau.dll for Netware print servers.
Print Processors | Winprint.dll Sfmpsprt.dll
Print Monitors | Localmon.dll Hpmon.dll Lprmon.dll Sfmmon.dll MARKVISION DECMON

Each spooler component is described in more detail in the following sections.


Router

When a Windows NT application has a print job it wants to send to the printer, it communicates with the client side of the spooler (Winspool.drv). This file makes an RPC to the server side of the spooler (Spoolss.exe), which makes a direct API call to the router (Spoolss.dll—which is also on the server side of the spooler).

The router passes control of the print job to the appropriate print provider. In the case of local printing, the local print provider takes the print job. If the print is going to a server on the network, the router passes the print job to the appropriate remote print provider—the Windows remote print provider or the Novell NetWare print provider.

Do not confuse the software router component of the Windows NT spooler with the physical hardware router used in networks.


Remote Print Providers

When a client computer connects to a remote printer and sends a print job to it, the router polls each remote print provider on the client computer. The router passes control of the print job to the first remote print provider that recognizes the printer name.

Windows NT supplies the following remote print providers:

  • Windows Network print provider (Win32spl.dll) transfers jobs to Windows Network print servers (such as print servers running Windows NT or Windows for Workgroups).
  • Novell NetWare print provider (Nwprovau.dll) transfers jobs to Novell NetWare print servers.

Note Neither of these remote print providers performs spooling.

Windows Network Print Provider

If the local copy of the Windows network print provider, Win32spl.dll, recognizes the printer name, it performs additional processing based on the type of print server to which the job is going. If the print server is running Windows NT, Win32spl.dll makes remote procedure calls to the router (Spoolss.dll) on the print server. The router receives the print job over the network and passes it to the local print provider as if one of its own local clients had submitted it.

If the remote print server is a downlevel server, Win32spl.dll sends a message to the Windows NT NetBIOS redirector. The redirector forwards the job over the network to the downlevel server.

The functions provided by the Windows network print provider are illustrated in the following figure.

Figure 2.3 The Windows Network Print Provider (Win32spl.dll)

Novell NetWare Remote Print Provider

If the NetWare print provider (Nwprovau.dll) recognizes the printer name when polled by the router, it takes control of the print job. The NetWare print provider sends a message to the NetWare workstation service (Nwwks.dll), which in turn passes control to the NetWare redirector. The NetWare redirector transmits the print job over the network to the NetWare print server.

Note To send print jobs over Windows NT to a NetWare print server, you must install Gateway Services for NetWare. To receive print jobs from NetWare print clients, you must install File and Print Services for NetWare.

Figure 2.4 The NetWare Print Provider (Nwprovau.dll)


Local Print Provider (Localspl.dll)

The local print provider writes the print job contents to a spool (.spl) file and tracks administrative information (such as user name, document name, and data type) in a shadow (.shd) file. By default, both files are written to %systemroot%\SYSTEM32\SPOOL\PRINTERS.

If, however, the hard drive partition containing Windows NT Server doesn't have sufficient disk space to accommodate the spool files, you can change the location of spool files by changing the server properties.

To change the location of spool files

1. Create a new spool file directory.

2. Click Start, and then point to Settings.

3. Click Printers.

4. Click Server Properties on the File menu.

5. Click the Advanced tab.

6. In the Spool Folder box, type the path for the new spool file directory.

7. Click OK.

Note You must create a directory for the new spool file location. If you attempt to spool directly to the root (C:\ or D:\, for example) the spool file will revert to the default spool directory.

Spooling a print job to a file protects the print job by saving it on disk. Should the print server suffer a power failure or other serious event before printing all jobs in the queue, the spool and shadow files on the server's hard disk preserve each job and prevent any loss of data once processing resumes.

By default, spool and shadow files are deleted after the job prints. However, you can enable spooler event logging to get valuable information about printer traffic, hard disk space, and other printing maintenance issues.

To enable spooler event logging

1. In the Printers folder, click the printer to select it.

2. Click Server Properties on the File menu.

3. Click the Advanced tab.

4. Click Enable spooler event logging to add a check mark.

5. Click OK.

Next, LOCALSPL polls the installed print processors (such as Winprint.dll and Sfmpsprt.dll) to see if one of them recognizes the job's data type set. If the data type is not set, the Winprint.dll print processor receives the job and uses the default data-type set Print Processor dialog box on the print server.

You can set a new default location or override the default location on a printer-by-printer basis by manually editing the Registry. However, before doing so, read the "Spool File Security" section later in this chapter.

Enhanced Metafile (EMF) Spool Files

Enhanced metafiles (EMF) are one type of spool file used by the default Windows NT print spooler. EMF spool files reduce the time between the initiation of a print request and when control is returned back to the operating system. This is done by storing only the GDI function calls that produce the graphic object the application wants printed. The much more time-consuming execution of function calls can then be carried out later, in the background, when the spool file is "played back."

The way EMF spool files are encoded also provides the advantage of printer device-independence. In other words, a picture measuring 2 inches by 4 inches on a VGA display and stored in an EMF maintains those original dimensions whether it is printed on a 300 dpi laser printer or on a 75 dpi dot matrix printer.

RAW Spool Files

If the print job's data type is RAW, the spool file's data type is RAW. These files are device-dependent. The spooled data is destined and formatted for a particular device and does not need to be printable on a different device. An example of a RAW spool file is an encapsulated PostScript (EPS) file, which is formatted to be understood by the PostScript printer for which it is destined, but which is just RAW data to the Windows NT spooler.


Print Processors

A print processor works in conjunction with a printer driver to despool the spooled print jobs during print spool file playback.

Print processors are the components that make necessary alterations to print jobs, based on the data type of the print job. A print processor might recognize only one data type, or it might recognize several data types. Windows NT supplies the following print processors:

  • Windows print processor (Winprint.dll)
  • Macintosh print processor (Sfmpsprt.dll)

A print device vendor might develop a custom print processors if:

  • The vendor develops its own printer driver.
  • Microsoft print processor.

Additional print processors can be supplied by third-party software vendors to support custom data types.

Windows Print Processor (Winprint.dll)

This print processor supports five data types: EMF, RAW, RAW [FF Auto], RAW [FF Appended], and TEXT. For a detailed description of each data type, see "Data Types" earlier in this chapter.

Services for Macintosh Print Processor (Sfmpsprt.dll)

This print processor is available only with Windows NT Advanced Server version 3.1 or Windows NT Server version 3.5, 3.51, and 4.0. By default, this print processor (SFMPSPRT) is installed only when Services For Macintosh is installed on the Windows NT Server computer.

SFMPSPRT supports the PSCRIPT1 data type. This data type indicates that the job is Level 1 PostScript code from a Macintosh client, but the target printer is not a PostScript printer. The spooler sends the PostScript code through a Microsoft TrueImage® raster image processor (RIP), supplied with Services for Macintosh. The raster image processor creates a series of one-page, monochrome bitmaps at a maximum of 300 DPI. The Windows NT print spooler sends the rasterized images, or bitmaps, to the print driver for the target printer. The print driver returns a job that prints the bitmaps on the page.

Because the RIP bitmaps are monochrome (black and white) and not more than 300 DPI, the target printer driver produces final output that is monochrome and not more than 300 DPI, even if the target printer driver supports color or higher resolutions. The restrictions are in the RIP software itself, not in the Windows NT printer drivers.

Several third-party Win32® RIP packages are commercially available for Windows NT version 3.1 and above for those who need a higher-end RIP.


Print Monitors

Windows NT 4.0 supports two kinds of print monitors: language monitors and port monitors.

A language monitor is necessary to support bi-directional print devices. A bi-directional print device supports two-way communication between the print device and the spooler running on its print server. The language monitor allows the spooler to configure and monitor the status of a bi-directional printer. A language monitor can also add data (such as printer control information) to the print stream. When you create a printer, you install a printer driver. If a language monitor is associated with that printer driver, all data that flows from the printer driver to the print device goes through the language monitor before it goes through the port monitor and out to the printer.

Two-way communication between computer and print device allows a system administrator to configure the printer and to monitor printer status. The spooler running on the computer can request configuration and status information from the printer, and the printer can send unsolicited status information to the computer (such as the fact that the paper tray is empty). A common language is necessary for the two devices to understand each other.

The language monitor supplied with Windows NT 4.0 uses Printer Job Language (PJL). If a print-device vendor uses a printer language other than PJL, that vendor can develop a language monitor for it. A vendor might also develop a language monitor to add data, such as printer-specific control information, to the print stream going to a single directional printer.

Port monitors control the I/O port to which the physical print device is connected. The local print monitor executable (Localmon.dll) supplied by Microsoft controls parallel and serial I/O ports that may have a print device connected to them. Print devices connected to different types of I/O ports such as SCSI or Ethernet ports on a network card or adapter, are controlled by vendor-developed port monitors.

The print monitors supplied with Windows NT are described in the following sections.

  • Local print monitor (Localmon.dll)
  • Hewlett Packard Network Port print monitor (Hpmon.dll)
  • Line Printer (LPR) Port print monitor (Lprmon.dll)
  • Macintosh print monitor (Sfmmon.dll)
  • Digital Network Port print monitor (Decpsmon.dll)
  • LexMark Mark Vision print monitor (Lexmon.dll)
  • PJL Language Monitor (Pjlmon.dll)

The Ports tab of the Printer Properties dialog box lists the default Windows NT ports.

By default, the list includes only standard ports controlled by the local print monitor, Localmon.dll. When you want to print over other communications channels (to a network-attached printer, for example), you must create a new port.

To create a new port

1. Click the Start button, and then point to Settings.

2. Click Printers.

3. Click Add New Port.

4. Click to select the port monitor that controls the type of communications channel you want to use.

5. Insert the disk or type the network path to the port monitor files.

6. Click OK in each dialog box.

Print monitors often depend on other software components and appear in this list only when you have installed the components they require. For example, the Hewlett-Packard Network print monitor transmits print jobs by using the DLC network protocol. This monitor appears in the list only if you have installed the DLC protocol.

Each monitor displays its own user interface, which you use to create a new port and configure a printer to use it. To reconfigure the new port (if the monitor allows reconfiguration), click the Configure Port button on the Ports tab of the Printer Properties dialog box.

When you read about each print monitor in the following sections, remember that each is associated with a data communications channel, not with the print device at the other end of that channel. In most cases, the port monitor is unaware of the make or model of the print device it is communicating with, nor does it need this information. Also, although different port monitors might use the same network protocol, this does not make them interchangeable. For example, both the Digital Network Port print monitor and the LPR Port print monitor use the TCP/IP protocol, but they send data over that protocol in very different ways.

Local Print Monitor (Localmon.dll)

The local print monitor, Localmon.dll, sends print jobs to local devices. These include familiar ports like LPT1 and COM1. Use of the less familiar FILE and Other ports are described below.

The FILE port appears in the default port list on the Ports tab of the Printer Properties dialog box. When you send jobs to a printer that uses this port, the local print monitor prompts you for the name of a file in which the print job should be stored.

If you select Other from the list of ports in the Print To box on the Printer Properties dialog box, and select the Local Port option, the local print monitor prompts you to enter a port name. Some possibilities include:

  • An explicit filename, such as C:\DIR\FILENAME. All jobs sent to this port are written to the named file. Each new job overwrites the last one.
  • The name of a print share, such as \\SERVER\PRINTER. Jobs sent to this port are transferred over the network to the named share by the network redirector. This can be useful if you need to send jobs to a network print server, but you want the job to spool locally as well as on the print server.
  • The NULL port. Use this port to test whether network clients are able to send jobs. Simply pause the printer set to use this port, send a job from a network client, look at the printer in Print Manager to confirm that it arrived, and resume the printer. Jobs sent to NULL are simply deleted from the system without wasting paper or delaying real print jobs.

Hewlett-Packard Network Port Print Monitor (Hpmon.dll)

The Hewlett-Packard Network print monitor, Hpmon.dll, sends print jobs to HP JetDirect adapters. This includes both the network adapters commonly installed in print devices (such as the LaserJet 4 Si) and the JetDirect device (which connects a parallel print device to the network).

Although many JetDirect devices can communicate over several different network protocols, including DLC, IPX, TCP/IP, and AppleTalk, Hpmon.dll is specific to DLC; you must load the DLC protocol to use this print monitor.

The DLC protocol is bridgeable, but not routable. This means that if a Windows NT print server is on one physical subnet and a JetDirect device is on another physical subnet, the server can send jobs to the JetDirect if the two subnets are joined by a bridge but cannot send jobs if the two subnets are joined by a router.

The DLC protocol can be bound to multiple network adapters, but the HP print monitor software can only manage printers over one network adapter, and it must be either adapter 0 or adapter 1. If your Windows NT computer has multiple network adapters, make sure all the HP JetDirect-equipped printers are on the same physical subnet.

When you install, reinstall, or upgrade Windows NT, it assigns a number to each network adapter in your computer. The adapter with the lowest I/O base address is assigned the number 0; the adapter with the next lowest I/O base address is assigned the number 1, and so on. If you later add another network adapter, it is assigned the next unused number, regardless of its I/O base address. Later, if you upgrade or reinstall Windows NT, each adapter is again assigned a number based on its I/O base address. If the third adapter has a lower I/O base address than either of the other two, then the numbering changes. In this case, HPMON looks for JetDirect cards through the wrong network adapter on the server.

To correct adapter numbering after an upgrade

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click the Network icon.

3. Click the Adapters tab.

4. Remove each adapter that has an incorrect number.

5. Add the adapters back in the order that corresponds with their I/O addresses (the lowest address getting the lowest number).

6. Click OK.

You can configure ports managed by Hpmon.dll as either job-based or continuous connection. The setting affects all ports at once:

  • With job-based connection, a print server connects to the JetDirect adapter, sends a print job, and disconnects when the job is finished printing. This enables other print servers to connect and print.
  • With continuous connection, a print server connects to the JetDirect adapter and maintains the connection until either the print server or the adapter is rebooted, preventing other servers from connecting. The main advantage of continuous connection is that all users are validated by the Windows NT security model, and every print job access can be audited.

For more information about auditing printing, see the Windows NT 4.0 Workstation Resource Guide.

Note If you configure two Windows NT print servers to send jobs to the same JetDirect device, configure both servers for job-based connections. If you configure one of the print servers for continuous connection, it prevents the job-based server from connecting to the print device.

Line Printer Port Monitor (Lprmon.dll/Lpr.exe)

Windows NT supplies a command line utility (Lpr.exe) and the LPR Port print monitor (Lprmon.dll). Both act as clients sending print jobs to an LPD service running on another computer. As mentioned previously, Windows NT also supplies an LPD service, the TCP/IP Print service, which receives print jobs sent by LPR clients, including UNIX computers and other Windows NT computers using the TCP/IP protocol.

To send print jobs, the LPR clients needs the network address of the LPD print server and the name that the LPD service associates with its print device. LPR sends print jobs to LPD along with instruction on how to process the job and the name of the print device.

When you add an LPR port while connecting to the LPR print server, you'll be asked in a dialog box to supply information identifying the print server (host) and the name of the printer. You can supply either the IP address or the host name of the server. The server can be one of the following:

  • UNIX computer
  • Windows NT computer
  • Windows for Workgroups computer with a 3rd-party LPD
  • network adapter, such as an HP JetDirect or Emulex NetJet

For example, let's say you're connecting to a printer named LABLASER on a UNIX computer whose IP address is 11.22.33.44, and whose name (defined in the hosts file on your Windows NT computer) is UNIXBOX. You can enter either "UNIXBOX" or "11.22.33.44" (without the quotation marks) in the Name Or Address Of Host Providing LPD box. You would enter LABLASER in the Name Of Printer On That Machine box.

To obtain the IP address of a network adapter, check the adapter's documentation. Some adapters provide a character-based application that you can access either by network connection or by directly connecting to the adapter by means of a serial-to-serial port cable.

If the server is a UNIX computer, and you don't know a valid name for the printer, you can often find it by looking at the /etc/printcap file on the UNIX computer. Each entry corresponds to a print queue ("printer" in Windows NT terminology) on the UNIX computer. Fields in these entries are separated by ":" characters, and for readability an entry can be broken over several lines by ending a line with a "\" character and beginning the next line with a space or tab character. The first field of each entry lists valid names for the queue, separated by "|" characters.

Continuing the LABLASER example, we might find entries like the following in the printcap file on the computer named UNIXBOX:

lp|lablaser|The_Lab_Printer:\ :lp=/dev/ttya:br#9600:\ :lf=/usr/spool/lpd/lablaser-err:\ :sd=/usr/spool/lpd/lablaser:

The first line in this example defines a print queue with three valid names: lp, lablaser, and The_Lab_Printer. You can use any of these names in the second field of the LPR Port dialog box previously shown.

Note This example is provided for illustrative purposes only. The UNIX system documentation is your best source of detailed information on your system's printcap file. Also note that the term "queue" is the UNIX term. Its Windows NT equivalent is "printer."

When the LPR Port print monitor receives the LPD server's network address and the proper queue name, it can send print jobs and processing instructions.

The LPR Port print monitor sends the l command by default, whereas the command line Lpr.exe utility sends the f command by default. With the Lpr.exe utility, use the -o command if you want to override the default on a job-by-job basis. To change the default command for a particular printer controlled by the LPR Port print monitor, you must modify a Registry parameter. Use the Registry Editor (Regedt32.exe) to find the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\ LPRPort\Ports\<portname>\<IP Address or Host name>:<printer name>

In this key, add a value named PrintSwitch with type REG_SZ, and enter the control command you want to use. For instance, enter the letter "f" (without the quotation marks) if you want to use the f command by default.

Some UNIX computers do not follow the control commands alone when deciding how to process a print job. For instance, if you send an ASCII text file with an l command (which tells the spooler not to alter the print job) to a PostScript printer, it does not print correctly. Consequently, many UNIX systems have added software that converts scans jobs that arrive with the l command. If the scanner finds PostScript commands, the job goes directly to the printer. If no PostScript is found, the added software adds the PostScript code so that the job prints correctly.

If you send PostScript jobs from a Windows NT computer using LPR, and the printer controlled by the UNIX server prints the PostScript code instead of interpreting it, the UNIX server might have a scanner that does not recognize the output from the Windows NT PostScript driver as valid PostScript code. If this happens, you might need to reconfigure Windows NT to use the o control command by default.

If the client sends the f, o, or p control command, the Windows NT TCP/IP Print service assigns the TEXT data type to the print job—which tells the spooler to edit the job to make sure it prints. If the client sends the l control command, the Windows NT TCP/IP Print service assigns the RAW data type to the print job—which tells the spooler the print job needs no editing to print correctly. For more detail about data types, see "Data Types" earlier in this chapter.

Control commands are documented in the LPR specification, Request For Comment (RFC)1179, sections 7.17 through 7.29. For detailed information about RFC 1179, refer to the Windows NT Knowledge Base article, "Text of RFC1179 Standard for Windows NT TCP/IP Printing," reference number Q124734.

LPD-compliant print devices must supply one or more names for each of their print queues, even though these devices often have only one possible destination for the print jobs they receive. Each print-device manufacturer chooses naming conventions independently. Some, like the HP JetDirect adapter, accept any string as a legal print queue name. In comparison, the Emulex NetJet adapter accepts only two strings, and these are case sensitive, and default to TEXT and PASSTHRU. These strings are configurable. To find the names supported by any specific adapter, check its documentation, or contact the vendor's technical support group.

Remember that the local print provider spools print jobs, and that it despools them to the print monitors. In Windows NT, after LPRMON receives a job from the local print provider, it spools it a second time as a temporary file in the SYSTEM32 subdirectory. LPR must include an accurate byte count in the control file, and it cannot get that byte count from the local print provider. Instead, it respools the data to a temp file, finds the size of that temp file, and sends that size in the control file to the LPD server.

The most common problem people encounter when printing from UNIX systems to a Windows NT print server is that their print jobs are processed as TEXT data type instead of RAW data type, as they would be on a UNIX system. This happens because the UNIX systems almost always send the f control command, expecting that the control command isn't too important, because the TCP/IP (LPD) server parses the job to identify what data type to use and how to alter the job. However, Windows NT relies on the control command to determine the data type. As a result, the LPD service on Windows NT assigns the TEXT data type to most jobs.

To correct this problem, reconfigure the LPR client to send the l control command so the LPD will assign the RAW data type.

Macintosh Port Monitor (Sfmmon.dll)

The Macintosh port monitor, Sfmmon.dll, transmits jobs over a network using the AppleTalk protocol to network-attached print devices, such as the Apple LaserWriter family. It also lets you send jobs to AppleTalk spoolers, regardless of the print device that the spooler is attached to.

This monitor is available on both Windows NT Workstation and Windows NT Server computers and enables any Windows NT-based computer to send local print jobs to AppleTalk print devices. However, only Windows NT Server has a Macintosh print server component, so only a Windows NT Server computer can receive print jobs from Macintosh clients.

Some print devices process non-PostScript print jobs incorrectly if they receive those jobs over AppleTalk. Also, some print devices process PostScript jobs incorrectly if those jobs contain binary data and arrive over any protocol other than AppleTalk. These problems result from restrictions in those print devices; they do not indicate that the Windows NT Server print server is transmitting the jobs incorrectly.

Digital Network Port Monitor (Decpsmon.dll)

The Digital Network Port print monitor, Decpsmon.dll, sends print jobs to Digital Equipment Corporation's Digital PrintServer print devices and to other Digital Equipment Corporation print devices (such as the DEClaser 5100 and the DECcolorwriter 1000).

Windows NT supplies the TCP/IP network protocol, but does not supply the DECnet™ protocol. If you want to use DECnet, you must contact Digital Equipment Corporation to obtain it.

LexMark Mark Vision Print Monitor (Lexmon.dll)

LexMark's Mark Vision print monitor (Lexmon.dll) sends print jobs to LexMark MarkNet print devices (such as the MarkNetXL) and to network adapters (such as the MarkNetXLe). This print monitor uses any of the following protocols:

  • DLC
  • TCP/IP
  • IPX


PJL Monitor (Pjlmon.dll)

The PJL Language Monitor, which Windows NT 4.0 supplies, "speaks" printer job language (PJL). Any bi-directional print device that uses PJL can use PJL Language Monitor. For example, PJL is the language that implements all the bi-directional communication between an HP LaserJet 5Si (a bi-directional print device) and its print server.


Bi-directional Printing

Bi-directional communication allows applications to query the print device directly to determine its capabilities. It also provides the benefit of configuring printer driver settings on the server without user intervention. The printer driver can automatically determine how much memory the printer has, what printer fonts are available, and so on.

Bi-directional print devices can send unsolicited messages to Windows NT and to applications. For example, the print device might send an "out of paper" or "printer offline" message. Bi-directional communication enables much more detailed status reporting on a wider variety of information, such as low toner, paper jams, maintenance needs, and so on.

To take advantage of bi-directional printing, you must have the following:

  • A bi-directional print device.
  • An IEEE 1284-compliant cable (a cable that has "1284" printed on it).
  • A correctly configured port. (Some parallel ports are set to IBM AT-compatible mode by default; in this case, you need to set the port to IBM PS/2 mode.)


Printer Properties

Printer properties include everything about a printer—from what port you use to what security features you want to implement. For detailed information, see "Setting Up Print Servers" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

To set or change printer properties

1. Click Start, and then point to Settings.

2. Click Printers.

3. In the Printers window, click the printer to select it.

4. Click Properties on the File menu.

5. On the Printer Properties sheet, click the tab you want.

The tabs are described in the following table.

Click OK.

Tab | Description
General tab | Displays general information about the printer, such as its physical location, a descriptive comment, and the printer driver installed. You can also add or customize a separator page, select a vendor-supplied print processor, and print a test page.
Ports tab | Displays the computer's physical ports. You can also add, configure, and delete virtual ports.
Job Scheduling tab | Displays the times the printer is available, its priority level, and spooling options.
Sharing tab | Displays the share status and share name.
Security tab | Permissions button lets you set the level of access for different types of users. Auditing button lets you set up printing users and events to be tracked. Ownership button displays printer owner.
Device Settings tab | Displays everything from paper tray sizes to font substitutions table for that printer. Use it to download soft fonts, install font cartridges, increase printer virtual memory, etc.


Separator Page Files

Separator pages—also called burst pages, header pages, or banner pages—print before each print job. They typically identify the computer that created the job, the time it was created, and so on. The local print provider contains an interpreter that reads commands from a separator page file to produce separator pages.

By default, separator page files are stored in the %systemroot%\SYSTEM32 directory. To use a separator page file, click the Separator Page button on the General tab of the printer's Printer Properties sheet. Either type the name of the Separator Page file, or browse through the directories and select a file. Windows NT provides four separator page files; you can use them as is, or modify them to create your own custom separator page files.

The following table lists the separator page files included with Windows NT.

Filename | Purpose | Compatible with
Sysprint.sep | Prints a page before each document | PostScript
Pcl.sep | Switches dual-language HP printer to PCL printing | PCL
Pscript.sep | Switches dual-language HP printer to PostScript printing | PostScript

To create a custom separator page file, copy and rename one of the supplied files, and then edit it. The following table provides the escape codes you can use. The separator file interpreter replaces these escape codes with appropriate data, which is sent to the printer.

Escape code | Function
\ | The first line of the separator file must contain only this character. The separator file interpreter considers this the separator file command delimiter. This table assumes that character is a \ character.
\N | Prints the user name of the person who submitted the job.
\I | Prints the job number.
\D | Prints the date the job was printed. The representation of the time is the same as the Time Format in the International section on the Control Panel.
\Lxxx | Prints all the characters (xxx) following it until another escape code is encountered.
\Fpathname | Prints the contents of the file specified by pathname, starting on an empty line. The contents of this file are copied directly to the printer without processing.
\Hnn | Sets a printer-specific control sequence, where nn is a hexadecimal ASCII code sent directly to the printer. To determine the specific numbers, see your printer manual.
\Wnn | Sets the width of the separator page. The default width is 80 characters; the maximum width is 256. Any printable characters beyond this width are truncated.
\B\S | Prints text in single-width block characters until \U is encountered.
\E | Ejects a page from the printer. Use this code to start a new separator page or to end the separator page file. If you get an extra blank separator page when you print, remove this code from your separator page file.
\n | Skips n number of lines (from 0 through 9). Skipping 0 lines simply moves priting to the next line.
\B\M | Prints text in double-width block characters until \U is encountered.
\U | Turns off block character printing.


Print Security

To limit user access to your network printers and spool file directory, use Windows NT security. You can provide additional security by managing print jobs from Macintosh clients or by forwarding print jobs to other print servers.


Printer Security

To specify security attributes on a printer-by-printer basis, use the Security tab in the Printer Properties dialog box. The most efficient way to establish security attributes is to assign permission levels to different user groups. For example, you could give all nonadministrative users in a department the Print level of permission and all managers Full Control permission.

The following table summarizes printer security permissions.

Type of permission | Level of access
Full Control | Enables complete access and administrative control.
Manage Documents | Enables a person to change the status of any print job submitted by any user. Does not permit control of the printer status.
Print | Allows user to send print jobs to the printer and to control pause, resume, or delete for his or her own jobs.
No Access | Explicitly denies access to a specific printer.

The installation-default printer permissions are different for Windows NT Server and Windows NT Workstation computers. By default, the following print permissions are assigned on a Windows NT Server computer:

  • Full Control permission for the Administrator, Server Operator, and Print Operator groups
  • Manage Documents permission for the Creator Owner group
  • Print permission for all users

To change security permissions

1. Click Start, and then point to Settings.

2. Click Printers.

3. Click to select the printer whose settings you want to change.

4. Click Properties on the File menu.

5. Click the Security tab.

6. Click Permissions.

7. Click to select the group whose permission you want to change, and then select the permission level from the Type Of Access dropdown list.

To add a group, click the Add button. To remove a group, select it, and then click the Remove button.

8. Click OK in each dialog box.


Security for Macintosh Clients

Although native Macintosh networking provides support for file security, it does not provide support for print device security. The AppleTalk protocol contains no mechanism that supports client user name or password. Macintosh clients, therefore, cannot identify themselves on the network, and the Windows NT print server cannot impose user-level security on Macintosh clients. If a Macintosh client is physically able to send a job to a print device or print server, that client implicitly has permission to do so.

You can, however, enforce one set of printer permissions on all Macintosh users as a group. The Macintosh client must start the MacPrint service by logging on using a user account. By default, it logs on as the System account. The System account has Print permission on all local print devices, so any Macintosh client can send a job to any of the Windows NT computer's local printers. To limit the permissions for Macintosh clients, create a new user account, giving it the printer permissions you want the group to have. Then set the Macintosh client MacPrint service to log on using this account.

Note The System account on one computer does not have permission to access resources on other computers. Macintosh clients that start the MacPrint service by logging on as System user cannot send jobs to printers that forward jobs to other print servers. The solution is to configure the Macintosh client MacPrint service to log on as another user, one which has permission to print on all the print servers to which print jobs are forwarded.


Spool File Security

To implement spool file security, change the default spool directory to an NTFS partition and directory where write permission is limited on a user-by-user basis.

When a print job prints locally, the local print provider spools the job to disk during processing. By default, the Everyone group has Change permission in the default spool directory. This allows all user print jobs write access to the default spooler directory.

A print job that cannot be spooled to disk during processing does not print. If the spool directory location is changed, all users who need to print must have Change permission for the new spool directory.

As described in the "Local Print Provider" section, the spool file (SPL_) and the shadow file (SHD) are written to the default spooler directory: %WINNT\SYSTEM32\SPOOL\Printers

For instructions on changing the default spool file directory, see "Local Print Provider" ealier in this chapter.

To override the default location for one specific printer

1. Start the Registry Editor (Regedt32.exe).

2. Find the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Print\Printers

3. Find the key for the printer:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Print\<Printername>

4. Add a new SpoolDirectory setting, and as its value provide the path to the spool directory that this printer should use.

Note You must create a directory for the new spool file location. If you attempt to spool directly to the root (C:\ or D:\, for example), the spool file will revert to the default spool directory.

The change in the Registry takes effect after you stop and restart the Spooler service.


Registry Security

Most printing-related Registry settings reside in the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print

An administrator can use the Registry Editor to assign read-only access to these subkeys. Users with read-only access cannot add or configure printers, because the read-only access does not allow changes of these subkeys.

Windows-based applications also use the following subkey in the Registry to find information about available printers.

HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\ CurrentVersion\PrinterPorts

Users with read-only access to this subkey cannot add new printers that are recognized by Windows-based applications.


Forwarding Jobs

To forward a print job to a different Windows NT print server, a Windows NT print server uses a null session. By default, the null session is disabled, preventing job forwarding. To enable job forwarding and null-session support, manually edit the following Registry subkey:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ LanmanServer\Parameters

In this subkey is a value named NullSessionShares. Add a new line containing the share name for the printer. This change does not take effect until you stop and restart the Spooler service.


Troubleshooting Printing Problems

Troubleshooting Windows NT printing problems can be a challenge because of the number of variables involved in printing and the number of different clients and print devices that Windows NT supports.

Windows NT has a modular printing architecture, with a module for each major task (such as receiving jobs from network clients). By adding new modules you can easily add functionality (such as support for a new type of network client). This modularity gives Windows NT a great deal of flexibility, making it able to support a wide variety of client operating systems, applications, data objects, network configurations, spooling options, and print devices. That flexibility comes at a cost, however, because each additional configuration adds its own possible points of failure.

Successful troubleshooting depends on your ability to quickly rule in or rule out general categories of points of failure. The modularity makes this fairly easy: Network printing, for example, consists of seven processes that always occur in the same order. By testing one of the processes, you can determine whether the problem is occurring in that process, before it, or after it.

The following are the seven basic processes involved in a network printing job:

1. An administrator creates a print share on the print server.

2. A client system connects to that share.

3. The client system creates a print job.

4. The client system sends the print job to the print share on the print server.

5. The print server receives, spools, and sometimes modifies the print job.

6. The print server sends the job to the print device.

7. The print device interprets the job and produces hardcopy output.

The basic strategy for troubleshooting printing problems is to use problem symptoms to identify the process, or processes, that are creating the problems. If you still cannot correct the problem after you've located it, your Product Support engineer will be much better able to help you correct it if you have first isolated the process where the problem exists.

To troubleshoot printing problems

1. Identify which of the seven processes is failing.

  • Analyze symptoms to identify the most likely process.
  • Reconfigure that process.
  • Retest with the new configuration.
  • If the problem changes with the new configuration, you probably have the right process. Otherwise, you probably picked the wrong process.

2. Look for documented explanations or solutions from the following sources.

  • Product hardcopy documentation
  • Product online Help documentation.
  • Microsoft Product Support Knowledge Base.

3. If possible, reconfigure the process to avoid the problem in the short term.

4. Implement long term solutions.

To help you implement this strategy, this section presents the seven basic printing processes and gives the following information about each process:

  • A basic description of what the process involves
  • A list of variables that can affect the process
  • Symptoms that would suggest a problem in this process
  • Tests to prove or disprove the suspicion


Printer Definition and Configuration

A print server administrator can use the Add Printer wizard to:

  • Create a local printer.
  • Connect to a remote printer.

Both procedures install and configure a printer driver. Creating a printer gives more control over driver configuration than connecting to a printer, and the administrator can create new printer ports by entering values in the Print To field on the Printer Properties sheet. The administrator can also define form-to-tray mapping, security, and spooler options.

The problem is likely in this process if...

  • You cannot launch the Add Printer wizard, or you cannot browse printers in the Add Printer wizard.
  • You cannot create a new local printer or a new local printer port.
  • The port name and port do not show up or are intermittent.
  • The problem is specific to one printer or to a subset of the printers.
  • You can create another printer (with the same driver, port, and configuration options, but a different name) and the problem does not occur with that new printer.
  • You cannot install a particular printer driver, or the driver for that printer doesn't exist.
  • You cannot share a printer.
  • You cannot establish security on printers.
  • You have problems with forms, separators, pages, fonts, halftones, or printer options.
  • You can delete the printer, stop and restart the spooler, recreate the printer with the same name and configuration, and the problem no longer occurs.


Client Computer Connects to a Shared Printer

A printer is established on a print client computer.

The problem is likely in this process if...

  • You have problems with forms, separators, pages, fonts, halftones or printer options.
  • You can connect to another shared printer, on the same print server, and the problem goes away.
  • You cannot connect to a remote printer.
  • You cannot browse printers in the Add Printer wizard.


Client Application Creates a Print Job

A user on a client system runs an application that composes text and/or graphics to create a print job. The application may interact with a printer driver to create output in a printer language such as PCL, PostScript, or HP-GL/2.

The problem is likely in this process if...

  • The error in one particular print job is not reproducible.
  • You create a simple test document and print it to a file. Transfer that file to a different client system, and print it to a different printer on a different print server, and there it continues to fail.
  • What you see on the screen is not the output that you get.
  • The problem is limited to one particular user or the users in a specific group; one particular client operating system; a particular vendor's printer driver (or a particular version of the printer driver); a particular font or fonts from a particular vendor; certain extended ASCII characters; a particular graphic object, a particular graphic file format (such as EPS, BMP, or TIF); jobs created by a particular application or version of that application; color or shading; incorrect resolution (dots per inch);, or the print job is missing line feeds or form feeds.
  • A different driver works fine.

If the problem persists when you send a simple textprint job from several clients' systems, the problem is likely caused by another printing process.


Client Sends Job to Spooler

The user on the client system sends the job over the network to the print server. The client system's application software or operating system sends the job to the client's transport protocol, to the network adapter, over the network hardware, to the transport software on the print server, and finally to the appropriate print server service on the print server. The print server service (Windows NT Server, Services for Macintosh, or TCP/IP Print) assigns a data type to the print job and submits the print job to the spooler, or leaves it blank.

The problem is likely in this process if the problem is limited to...

  • One particular client redirector (one vendor's software, or one version of that software).
  • One particular network transport—for example, TCP/IP, NWLink, NetBEUI, AppleTalk.
  • One particular make or model of network adapter, or one firmware level.
  • One particular intermediate system for example, one specific router, bridge, hub, or gateway.
  • One particular kind of intermediate system, for example, all jobs from clients on the other side of any router, bridge, or gateway.
  • One particular kind of client, for example MS Network, LPR, or Macintosh clients.

The problem is also likely in this process if...

  • The print job is not started until the application is exited.
  • Pages come out incomplete.
  • The print server has run out of disk space.

Suspect a problem elsewhere if...

  • The print job prints fine on another printer of the same make, model, or version.
  • You send a print job to the spooler in a different way, and the problem does not go away.


Print Server Spooler Processes Print Job

The spooler receives the job from the print server service. If the printer was established by selecting the Network Printer option in the Add printer wizard, the remote print provider sends the job to the print server. Otherwise, the job goes to the local print provider.

Unless otherwise configured, the local print provider spools the job to disk and checks the data type assigned by the print server service. The data type (for example, RAW or PSCRIPT1) determines which print processor receives the job. The data type also effects whether the print processor alters the job or not, and if so, how it alters the job. If the spooler is configured to append a separator file, it does so before sending the job to the print monitor for delivery to the print device.

The problem is likely in this process if...

  • Page size, font, or character set is wrong because of incorrect data type (UNIX).
  • Disk space is limited.
  • You get extra form feeds or no form feed.
  • Changing the default data type affects the problem with MS-Network.
  • The job gets stuck in the printer.
  • The problem is specific to one type of client.
  • Macintosh jobs print in the wrong resolution, have font problems, or print black and white when they should print in color.
  • The problem occurs only when the printer was established using the Add Printer wizard.


Print Server Spooler Sends Job to Print Device

The print monitor receives the job and interacts with local hardware drivers and transport drivers to send the job to its destination. The components in this process are:

  • Print monitors, LOCALMON, redirector, LPRMON, SFMMON, DECMON, or HPMON.MESMegan E. Sheppard
  • Transport protocols (either TCP/IP, NWLink, NetBEUI, or AppleTalk).
  • Network hardware (routers, bridges).

The problem is likely in this process if it is limited to...

  • All print devices accessed by a particular print monitor.
  • All print devices on one segment of the LAN.
  • One make/model/version of a particular print device.
  • One parallel/serial cable.

The problem is also likely in this process if...

  • Sending the same job to the same device by means of a different communication channel by using a different protocol, serial, or parallel port produces a successful print.
  • Trying different parallel or serial cable produces a successful print. If your print device is bi-directional, make sure that the cable has "1284" printed on it. The cable should be six to 15 feet (maximum).
  • If your print device is bi-directional, make sure that the parallel port is set correctly. Some are set to AT-compatible mode by default, which is not bi-directional. Set the port to PS/2 mode in the BIOS to get bi-directional functionality.


Print Device Interprets Job

The final processing at this point is completed by the print device. The print device receives the print job from a hardware port. The print device interpreter interprets the job and produces hardcopy output.

The problem is likely in this process if...

  • The problem is specific to a specific print device, or a print device that is a variation of the same model, make, or revision.
  • Sending same print job to another print device of same make, model, and revision produces a successful print.


Questions and Answers

The following section presents specific questions and answers about Server Printing.


Does the Windows NT print server support UNIX clients running LPSSCHED?

No, it does not support UNIX computers running LPSSCHED. UNIX client computers must have an LPD program installed when used with a Windows NT print server.


How can platform-specific printer drivers be installed?

Microsoft places all new or updated printer drivers onto its electronic services for public download.

Also, a platform-specific printer driver is likely available on another computer in the network.

To install platform-specific printer drivers from another computer in the network

1. Log on the client computer using an user account that has Full Control permission.

2. Double-click Network Neighborhood.

3. Double-click the print server.

4. Click to select a printer.

5. Click Properties on the File menu.

6. Type the location of the printer driver in the Printer Properties dialog box. The printer driver is installed on the print server where it is available to any client computer that has the same hardware platform and is connected to the Windows NT print server.

7. Click OK.


What kind of problems occur when a print job has been assigned an incorrect data type?

Typical problems that occur when there is some error in the data type assignment and consequent job alteration of a print job include the following:

  • LPR client print jobs include PCL or Postscript code, include incorrectly printed extended characters, or print in the print device's default font.
  • The final page of a Microsoft network-based client print job does not print.
  • Extra page prints after a Microsoft network client print job.
  • Microsoft Network client print jobs include PCL or Postscript code, include incorrectly printed extended characters, or print in the print device's default font.
  • Postscript print jobs sent from Macintosh clients do not print in color, print at a lower resolution, or fail.


How many printers can be supported by a Windows NT print server?

The limitation on the number of printers that can be attached to Windows NT print server is dependent on whether the print server is a Windows NT Workstation computer or a Windows NT Server computer. Windows NT Workstation and Windows NT Server have been optimized for different roles in the network:

  • Windows NT Workstation is limited to 10 connections from other computers and should be used as a print server in small-network situations.
  • Windows NT Server has been optimized as a print, file, and application server.
  • Windows NT versions 3.5 and 3.51 are capable of supporting more printers than Windows NT version 3.1.

The limitation on total printers attached to a Windows NT Server print server should be determined by daily requirements for print throughput. Print throughput is determined by the processor capabilities. For example, a print server with approximately 64 meg RAM and a 486/66 or higher processor with a high throughput network card can support 25 to 30 DLC printers or 40 TCP/IP printers.


Chapter 3 - Disk Management Basics

This chapter is about managing and understanding disks. Its purpose is to provide you with a basic understanding of disk hardware and how Windows NT accesses the disks. It also describes the Windows NT startup process, so you know what is happening when you power on your computer. We want you to be able to effectively troubleshoot disk and startup problems.


Why You Should Know About Disks

Disk problems are frequently the cause of startup failures. Some of these problems are the result of hardware errors. But frequently the problem is that Windows NT is unable to find the information about the disk or its contents, usually because of control information corruption. If you know what the control information on your disk should be, you can tell if it has been corrupted.

There are several reasons that Windows NT cannot give your computer complete protection:

  • The security provided by Windows NT is effective only when the operating system is running. If you are running another operating system, or if an unauthorized person can walk up to the computer and restart it, Windows NT cannot provide any protection.
  • External media devices, such as floppy disks and CD-ROMs, provide the physical means for anyone to bypass Windows NT and gain access to your files. You can also introduce viruses from floppy disks or from files that you copy or download from other computers.
  • The transaction logging that the Windows NT file system (NTFS) does for recoverability purposes protects only NTFS metadata.
  • A power failure can cause corruption. So can turning off your computer without going through shutdown.

This following list highlights simple procedures that you can implement to reduce the potential for problems and make it easier for you to recover when problems occur.

  • First, implement physical security. Put your computers in a secure room. Lock them. Use a password on your screen saver. Run virus checks on your computer and on floppy disks before you use them. Or disable the floppy disk, which is supported in some system BIOSs. If you cannot disable the floppy disk in the BIOS, you can physically disconnect it.
  • Develop a preventive maintenance plan and schedule regular maintenance. You might not know about file system problems until you restart your computer, when the Chkdsk program tells you that there are errors or that a volume is Unknown.
  • Back up data that are critical to the operation of the computer when you make changes to them. These data include the Registry, Master Boot Record, and Partition Boot Sectors. You also need a way to start another installation of Windows NT Server if the one you normally use doesn't work, either because hardware failure or corruption makes the primary installation unusable.
  • Know the configuration of the computer. If you have more than one disk with more than one partition, you need to know which data are on which partitions on which disks. For example, which partition is your system partition or your boot partition? If you have implemented volume sets, stripe sets, mirror sets, or stripe sets with parity, which disks are members of which sets?
  • Implement a backup procedure for user data. Users will delete files or make changes to them and then want the old version back. Files can get corrupted when applications crash. A power failure can adversely affect files and disks in many ways. You need to be able to restore individual files, as well as a complete disk's worth of data, or even all of the files on the computer.

This chapter, and the other chapters in the "Reliability and Recoverability" part of this book, provide much more detailed information about the preceding topics. There are more details about disk organization, file systems, and starting your computer in the following chapters of the Windows NT Workstation Resource Guide:

  • Chapter 17, "Disk and File System Basics."
  • Chapter 18, "Choosing a File System."
  • Chapter 19, "What Happens When You Start Your Computer."


About Disks and Disk Organization

This section describes the physical structure of hard disks and floppy disks, and presents an overview of ways to logically organize areas on your disks.

Both hard disks and floppy disks work similar to an old-fashioned record player, with the record turning on the turntable and a needle playing the music. They are also similar to VCRs and stereo cassettes in that disks, cassette players, and VCRs all use a read/write head to access the information that is stored on the magnetic media.

Hard or fixed disks store information on a revolving platter of metal or glass coated with a magnetic material. The disk typically consists of several physical platters on a common spindle. This platter is similar to the record on a record player, except information is usually stored on both sides of a disk platter.

As the disk rotates, a transducer element called the head reads or writes binary data on the magnetic media. There are many methods for encoding data on the disk, such as modified frequency modulation (MFM) and run length limited (RLL). The disk controller logic determines the method used and the density of data on the disk.

Note

There are some state-of-the-art disks and disk controllers that have different hardware and logic than are described in this chapter.


Hardware Terminology

Each disk consists of platters, rings on each side of each platter called tracks, and sections within each track called sectors. A sector is the smallest physical storage unit on a disk, almost always 512 bytes in size.

Figure 3.1 illustrates a hard disk with two platters. The remainder of this section describes the terms used on the figure.

Figure 3.1. Illustration of a hard disk

The cylinder/head/sector notation scheme described in this section is slowly being eliminated. All new disks use some kind of translation factor to make their actual hardware layout appear as something else, mostly to work with MS-DOS and Windows 95. See the section titled "Translation," presented later in this chapter, for more information.

Tracks and Cylinders

On hard disks, the data are stored on the disk in thin, concentric bands called tracks. There can be more than a thousand tracks on a 3½ inch hard disk. Tracks are a logical rather than physical structure, and are established when the disk is low-level formatted. Track numbers start at 0, and track 0 is the outermost track of the disk. The highest numbered track is next to the spindle. If the disk geometry is being translated, the highest numbered track would typically be 1023. Figure 3.2 shows track 0, a track in the middle of the disk, and track 1023.

A cylinder consists of the set of tracks that are at the same head position on the disk. In Figure 3.2, cylinder 0 is the four tracks at the outermost edge of the sides of the platters. If the disk has 1024 cylinders (which would be numbered 0-1023), cylinder 1023 consists of all of the tracks at the innermost edge of each side.

Figure 3.2. Tracks

Heads and Sides

A head is a small transducer that can be positioned over a disk track by using a solenoid or servomotor. The head can change the properties of the magnetic media as it rotates underneath.

There is one head for each side of each platter. The heads are normally attached to a common head-movement mechanism, so that the heads all move in unison. The heads are always positioned at the same logical track on each side of each platter.

Because disk tracks are concentric bands, the heads must move to the track that contains the data to be accessed. The moving of the heads from the current track to the track that contains the next data is called seeking. The heads are moved over the surface of the disk in small increments called steps. Each step corresponds to one track.

Sectors and Clusters

Each track is divided into sections called sectors, and each track on the disk has the same number of sectors. A sector is the smallest physical storage unit on the disk. The data size of a sector is always a power of two, and is almost always 512 bytes.

The Windows NT file systems allocate storage in clusters, where a cluster is one or more contiguous sectors. Windows NT bases the cluster size on the size of the volume.

As a file is written to the disk, the file system allocates the appropriate number of clusters to store the file's data. For example, if each cluster is 512 bytes and the file is 800 bytes, two clusters are allocated for the file. Later, if you update the file to, for example, twice its size (1600 bytes), another two clusters are allocated.

If contiguous clusters (clusters that are next to each other on the disk) are not available, the data are written elsewhere on the disk, and the file is considered to be fragmented. Fragmentation is a problem when the file system must search several different locations to find all the pieces of the file you want to read. The search causes a delay before the file is retrieved. A larger cluster size reduces the potential for fragmentation, but increases the likelihood that clusters will have unused space.

Using clusters larger than one sector reduces fragmentation, and reduces the amount of disk space needed to store the information about the used and unused areas on the disk. Because the FAT file system can use only 16 bits for the cluster number, using clusters enables FAT volumes to be larger than 65,535 sectors. There is more information about the FAT file system and FAT volumes presented later in this chapter.

Figure 3.3 shows a sector and a grouping of four contiguous sectors into a cluster.

Figure 3.3. Sectors and clusters

Translation

Translation is the conversion of physical disk geometry (the number of cylinders on the disk, number of heads per cylinder, and number of sectors per track) to a logical configuration that is compatible with the operating system.

Many state-of-the-art disks now have a feature called Translation Mode. The disk queries the system BIOS (x86-based computers) or firmware (RISC-based computers) to determine the logical parameters the computer needs. If the number of cylinders, heads, and sectors per track the computer needs is within the range supported by the disk, the disk automatically configures itself to match those parameters. If the system BIOS or firmware does not support translation, the disk configures itself to its largest possible size, which is typically around 500 MB.

For example, all SCSI disks use some kind of translation, and many SCSI disks support hot swapping of sectors to fix bad sectors. This means that a SCSI disk maintains a set of unused sectors at the end of a disk. When a used sector goes bad, it is remapped to an unused sector and the data are written to the new sector. Windows NT uses absolute sector notation (also called logical sector notation, or LSN) for accessing disks. The translation of the sector number to the physical sector on the disk is handled by low-level disk device drivers and the hardware.

The translation is especially important when there are more than 1024 physical cylinders on the disk. The section titled "Using Hard Disks With More Than 1024 Cylinders (x86-based Computers)," presented later in this chapter, contains more details. There is also more information in Chapter 5, "Preparing for and Performing Recovery."


Logical Organization: Partitions and Volumes

The Master Boot Record on each hard disk contains an area called the Partition Table that the computer uses to determine how to access the disk. It has room for four entries, called partitions, that you create to make it easier to organize information. A partition must be completely contained on one physical disk.

Use Disk Administrator to create and format partitions. The next figure is a Disk Administrator screen shot for a computer with a single disk.

Figure 3.4. Disk Administrator screen shot of primary partitions and an extended partition

Disk Administrator shows you the layout of each of your disks, including:

  • The size of each disk.
  • The size, label, and file system used for each partition on the disk.
  • The size and location of free space.

The remainder of this section describes partitions, and explains what you see in the Figure 3.4.

There are two types of partitions in the Master Boot Record, primary and extended. A primary partition is one into which you can install the files needed to load an operating system. A primary partition is formatted for a particular file system and is assigned a drive letter. Having multiple primary partitions enables you to install and start operating systems that do not use the same file system, such as Windows NT and UNIX. There are three primary partitions in Figure 3.4, C, D, and L.

You can have one extended partition on a hard disk. An extended partition is effectively a logical disk. Unlike a primary partition, you do not format the extended partition, nor does it get assigned a drive letter. Instead, you can create one or more logical drives within the extended partition, and each logical drive is assigned a drive letter. You format each logical drive for a particular file system.

An extended partition is a method for avoiding the four-partition limit and configuring a hard disk into more than four logical areas. An extended partition entry looks much like a primary partition entry in the Master Boot Record, except that it points to space on the disk that can contain one or more logical drives. The important information about an extended partition is how much of the disk it takes up and where it starts.

Note

In this chapter, and other chapters in the "Reliability and Recoverability" part of this book, the term logical drive means a contiguous area in an extended partition, which is assigned a drive letter.

There is an extended partition in Figure 3.4, but it is not as easy to identify as the primary partitions. The extended partition consists of all the disk area between primary partitions D and L. If there are logical drives on a disk, then you have an extended partition on that disk. If you have free space for which the diagonal lines look like the ones for the 4 MB of free space to the left of primary partition L, then you have an extended partition on the disk.

Figure 3.4 shows an important point. The unpartitioned space at the end of the disk (to the right of primary partition L) cannot be used. You can have only three primary partitions and one extended partition on a hard disk, or four primary partitions. This disk already has the maximum for each of these types.

Note

The distinction between the two areas of free space is that the one to the left of L is free space within an extended partition, while the free space on the right of L, which has a different background pattern, is not a part of any partition.

If you have more than one primary partition or logical drive on a disk, you can format them for different file systems. However, the format program will use the same sector size, number of tracks per cylinder, and number of sectors per track for each partition or logical drive. The cluster size can be different for each one.

The system partition is the partition on a disk that contains the hardware-specific files used in loading and initializing the operating system. Only a primary partition can be used as a system partition. Some programs, such as Disk Administrator and the MS-DOS-based program Fdisk, use the term active partition to refer to the same thing. This book uses the term system partition unless it is specifically describing dialog boxes or menus that use the term active or active partition.

The boot partition is also used in starting the operating system. It contains the operating system files and other support files needed by the operating system. Both a primary partition and a logical drive in an extended partition can be used as a boot partition. The system partition and the boot partition can be the same partition, or they can even be on different disks. There is more information about the system and boot partitions presented later in this chapter and in other chapters in "Reliability and Recoverability" part of the Windows NT Server Resource Guide.

Note

To summarize, you can have as many as four primary partitions on a hard disk. If you have an extended partition on the disk, you can have up to three primary partitions. If the disk does not contain the system partition, you do not need to create any primary partitions. You can use the entire hard disk as an extended partition, and create as many logical drives within it as you want to have.

Windows NT requires that the system partition be a primary partition.

Some computers create an EISA configuration partition as the first primary partition on the hard disk. On these computers, you can only have three other primary partitions on the disk, or two primary partitions and one extended partition.

You create a volume set by combining multiple areas of free space on one or more hard disks into a single logical disk. When you create a volume set, Windows NT uses the HKEY_LOCAL_MACHINE\SYSTEM\DISK Registry subkey to access the areas on the disk(s) that are part of the volume set.

A volume set can be made from:

  • Free space on multiple disks.
  • Multiple areas of free space on one disk.
  • Multiple areas of free space on multiple disks.

You use Disk Administrator to create and extend volume sets. See Disk Administrator Help for information about creating volume sets.

Each volume set can include up to 32 areas of free space from one or more physical disks. When creating a volume set, the free space can be an unallocated area within an extended partition, or an unpartitioned area elsewhere on the disk. Figure 3.4 shows a volume set E, which is made up of two areas in the extended partition on disk 0. Figure 3.4 also shows the two different types of free space. The free space between drives E and L is unallocated space in an extended partition. The free space at the right side of the screen shot is unpartitioned space.

You cannot use volume sets to avoid the limit of four Partition Table entries for a disk. For example, the Disk Administrator screen shot in Figure 3.4 shows three primary partitions (drives C, D, and L) and one extended partition. The free space between the second part of volume set E and the primary partition L is part of the extended partition. It can be used to create one or more logical drives in the extended partition. However, the free space to the right of primary partition L is wasted disk space, because there are already three primary partitions and an extended partition.

You can tell whether free space is unallocated space in an extended partition or is unpartitioned space, because the diagonal lines go in different directions for the two types of free space.

A stripe set, a mirror set, and a stripe set with parity are each composed of identically sized areas on multiple disks. Like volume sets, Windows NT must use the HKEY_LOCAL_MACHINE\SYSTEM\DISK Registry subkey to know how to access the disks. You use Disk Administrator to create these types of volumes. For a description of stripe sets, mirror sets, and stripe sets with parity, see Chapter 4, "Planning a Reliable Configuration." For information about creating and using mirror sets and stripe sets with parity, see Chapter 5, "Preparing for and Performing Recovery."

Volume is the general term that refers to all of the following entities that you can create and use on a computer running Windows NT Server.

  • Primary partition.
  • Logical drive in an extended partition.
  • Volume set.
  • Stripe set.
  • Mirror set.
  • Stripe set with parity.

A volume has a single drive letter assigned to it, and is formatted for use by a file system.

See the section titled "Maximum Sizes," presented later in this chapter, for information about the maximum size of volumes.


Which Programs to Use to Create and Format Volumes

This section provides information about how to create and format volumes. You can create and format a volume in one of the following ways:

  • During Windows NT Setup, you can:
    • Create and format a new primary partition into which to install Windows NT, provided you have enough unpartitioned disk space for the Windows NT installation (approximately 160 MB for Windows NT Server on a RISC-based computer).
    • Format an existing, unformatted volume into which to install Windows NT.
    • When you choose to install Windows NT in an existing FAT volume, you can convert the volume from the FAT file system to the NTFS file system. Converting preserves the data on the volume.
  • If you have Windows NT installed on your computer, you can use Disk Administrator to create and format the volume. You can also use Disk Administrator to reformat an existing volume that is already formatted for the FAT file system or the NTFS file system. Reformatting a volume erases all information about which files used to be on the volume. You can reformat the volume as FAT or NTFS, regardless of what file system it is currently formatted for. For information about Disk Administrator procedures, see the Disk Administrator Help.
  • If you want to specify special options during the format, such as a cluster size to use for a FAT volume, you can run the Format program from the command prompt. To see the options for the Format program, enter format /? at the command prompt.
  • When running Windows NT, you can use the Convert program to convert an existing FAT volume to an NTFS volume, which preserves the data on the volume. For information about using the Convert program, see Chapter 7, "Disk, File System, and Backup Utilities."
  • When you have started MS-DOS, you can use the fdisk command to create a primary partition or logical drive, and use the format command to format the volume for the FAT file system. See MS-DOS Help for information about these commands.
  • On Alpha AXP-based computers and MIPS-based computers, you can use the Arcinst program to create and format volumes.

Note

Converting a volume from the FAT file system to the NTFS file system can take a long time, depending on the amount of fragmentation and size of the FAT volume. For example, converting a 1 GB volume can take up to several hours. The conversion process has to read all of the files to build the information that NTFS needs to have about the data on the volume. When using the Convert program or converting the volume in Windows NT Setup, no status information is displayed to indicate that the conversion is proceeding. Although it looks like the conversion process is hung, it might just be taking a long time. For a large volume, it might be a good idea to run the file system conversion process overnight.

It might be faster to back up the data on the FAT volume to tape or a remote computer, reformat the volume as NTFS, and then restore the data.

If you create a single primary partition that occupies the entire disk, you cannot change the way your disk is organized without deleting the primary partition (which deletes all of the information in it) and creating new, smaller primary partitions or an extended partition. You have to back up the information that you need to save to a backup tape or a disk on a remote computer, reinstall Windows NT, and restore the data to the new volumes that you have created.

If there is no unpartitioned space left on your disk, the Create and Create Extended options on the Disk Administrator Partition menu are not available.

When you use Disk Administrator to create volumes, you have to write the changes to the Partition Table before you can format the volume. You know that you need to write the changes if the Format command is not available (grayed) on the Tools menu. You can write the changes by using one of these methods:

  • Clicking Commit Changes Now on the Partition menu. You can now click the volume, click the Tools menu, and click Format.
  • Exiting Disk Administrator. If you have made changes to your disk configuration, Disk Administrator displays a dialog box that asks whether you want to save changes. Click Yes. You can now restart Disk Administrator, click the volume, click the Tools menu, and click Format.

If you have created a volume but not formatted it, Disk Administrator displays the volume as unformatted. You cannot access the volume in either My Computer or Windows NT Explorer until it has been formatted.

You cannot see an NTFS volume when you are running any operating system other than Windows NT. This means that your drive letters will probably be different when you are running Windows NT and other operating systems. For example, if you have two FAT volumes (C and E), and an NTFS volume (D), and you start the MS-DOS operating system, the second FAT volume will be labeled D. Because MS-DOS does not recognize the NTFS volume, the drive letter that was assigned to the NTFS volume when running Windows NT is used for the second FAT volume when running MS-DOS.

In Disk Administrator, you cannot delete the Windows NT boot partition when you are running Windows NT. You can delete the Windows NT boot partition if it is not the same partition as the system partition and you start another operating system that does not use the Windows NT boot partition as its boot partition.


Formatting Hard Disks and Floppy Disks

Before you can use a hard disk or a floppy disk, you must format the disk.

There are three steps involved in formatting a hard disk:

  • Low-level formatting the disk.
  • Creating primary partitions or logical drives in an extended partition.
  • Doing a logical formatting of the primary partitions or logical drives.

Formatting a floppy disk is much simpler than formatting a hard disk, because there are fewer steps. You cannot create partitions on a floppy disk, so there are only two steps:

  • Low-level formatting the disk.
  • Doing a logical formatting of the disk.

When you format a floppy disk, the format program performs both a low-level format and a logical format, so there is really only one step. However, the low-level format on a floppy disk is not as thorough as on a hard disk.

The rest of this section discusses low-level formatting, creating partitions, and logical formatting.

Low-level Formatting

Each disk vendor provides the low-level format program to use for the disk. Consult your disk documentation or contact the vendor to find out how to do low-level formatting.

Each low-level format program determines the correct sector size to use, the number of tracks, and the number of sectors per track. This format program selects sector size based upon the disk and the information about the sectors in its circuitry. The program for almost all disks used in the United States uses a sector size of 512 bytes. The program also writes error correction and sector identification information for each sector onto the disk.

SCSI disks should always be low-level formatted when put on a new controller. The reason for this is that the translation in use on the disk varies from controller to controller, and can even vary between two identical controllers based upon the controller settings.

On x86-based computers, you must enable the BIOS on the SCSI controller if your system partition is on a SCSI disk. Depending upon your disk configuration, you might need to turn off translation in the SCSI controller. Also make sure that the CMOS has no entries for SCSI disks. For more information about the SCSI controller, see Chapter 5, "Preparing for and Performing Recovery."

There are some older IDE disks that you should not low-level format, because the factory formatting puts information on the disk that a low-level format erases. However, newer IDE disks, and all enhanced IDE disks (also known as EIDE) need to be low-level formatted. You must configure an IDE or EIDE disk in the CMOS before you can use it on the computer. See your hardware documentation for information about changing information in the CMOS.

If you have created and formatted volumes on your hard disk, but are getting errors from the Chkdsk program or other disk scan utilities about bad sectors on your disk, the only way to permanently eliminate them is to do a low-level format. Low-level formatting maps around the bad sectors. However, a low-level format erases all data on the disk. Therefore, be sure to back up any data on the disk before you low-level format it. You then need to create volumes (primary partitions or logical drives in an extended partition), and logically format them before you can restore the data to the disk.

Caution

Do not low-level format IDE hard disks unless the manufacturer's literature describes that you should do so.

Creating Partitions on the Disk

When you create primary partitions or an extended partition on a disk, you logically divide it into one or more areas that can be formatted for use by a file system. The first partition on the disk (whether it is a primary partition or an extended partition) always starts at the outside of the disk, at cylinder 0, head 0, and sector 1. Because partition boundaries are always cylinder boundaries, the smallest partition that you can create on a disk consists of all of the tracks on a single cylinder.

When you have Windows NT installed on your computer, you should use Disk Administrator to create partitions. However, if you are setting up a new computer, you might not have any operating system installed. But you still need to create and format a partition into which to install Windows NT.

On x86-based computers, if you have an MS-DOS bootable floppy disk with the Fdisk program on it, you can start your computer from the MS-DOS floppy disk and create partitions by using Fdisk. On RISC-based computers, you can use the Arcinst program on the Windows NT Server CD to create partitions. Windows NT Setup displays an option to create a partition to use for Windows NT, provided that there is enough unpartitioned space on a hard disk.

Note

On x86-based computers, you might not be able to access all your hard disk when using fdisk. If you have a disk that is larger than 4 gigabytes (GB), MS-DOS cannot see the space beyond 4 GB. Depending on the geometry, this limitation could even be 1 GB, because MS-DOS cannot access volumes that go beyond cylinder 1023. If you have more than 2 SCSI disks, MS-DOS generally does not see any disks after the first two, unless you load a SCSI device driver.

When you create the first partition on a disk (either a primary partition or an extended partition), the program that you use creates the Master Boot Record and writes it to the first sector on the disk (cylinder 0, head 0, sector 1). The Master Boot Record contains the Partition Table, which has information about each partition defined on the disk. When you make any changes to volumes on the disk, such as creating, deleting, or formatting them, the program that you are using updates the Partition Table.

You can configure the entire disk as one primary partition, and logically format it for one file system. Or you can create more than one primary partition, and use different file systems on them. You can also create an extended partition, and create one or more logical drives within the extended partition.

For more information about primary partitions, logical drives, and extended partitions, see "Logical Organization: Partitions and Volumes," presented earlier in this chapter. For more information about the Master Boot Record and Partition Table, see "Disk Sectors Critical to the Startup Process," presented later in this chapter.

Logical Formatting

Before you can write any data to a primary partition or logical drive, you must do a logical format; that is, format it for use by a file system. Logical formatting writes information needed by the file system onto the disk. The information includes:

  • Partition Boot Sector.
  • Changing the System ID field in the Partition Table (hard disk only).
  • File system metadata, including information about available and unused space and location of files and folders.
  • Damaged areas.

When you have Windows NT installed on your computer, you should use Disk Administrator to format the volumes.

On x86-based computers, you can format primary partitions and logical drives for the FAT file system before you install any operating systems by starting the computer from a MS-DOS bootable floppy disk that has the Format program on it. You can use the Format program only for volumes that do not go beyond cylinder 1023.

On Alpha-based computers and MIPS-based computers, you can run the Arcinst program from the Windows NT Server product CD to format partitions on the hard disk.

On both x86-based computers and RISC-based computers, you can create and format a primary partition to use for Windows NT during Setup, provided that there is enough unpartitioned space on a hard disk.


Why Do You Need to Know Your Disk Configuration?

The next Disk Administrator screen shot is used to help you to understand the importance of knowing how the primary partitions and logical drives on your disks relate to each other, and why it is best if you can keep your disk configuration simple.

Note

The key at the bottom of the Disk Administrator screen identifies the types of volumes that are configured on the computer. In the preceding screen shot, there are no stripe sets, mirror sets, or stripe sets with parity configured on the computer. Therefore, you do not see those types of volumes in the screen shot.

All that you can tell by looking at this screen shot is how the disks are configured and which volumes have been created. When using Disk Administrator, you cannot tell what a volume contains, or the order in which the members of a volume set, stripe set, or stripe set with parity were combined to form the volume.

To create a volume set, stripe set, or stripe set with parity

1. Click an unpartitioned area on one of the disks.

2. Holding the CTRL key, click each of the other unpartitioned areas that you want to combine into the volume.

For a volume set or stripe set, click Create Volume Set or Create Stripe Set on the Partition menu. For a stripe set with parity, click Create Stripe Set With Parity on the Fault Tolerance menu.

The order in which you combined the areas on the disks into volume sets, stripe sets, or stripe sets with parity is critical information. It does not matter whether you first create a volume set, and then a stripe set, or the other way around. But it is absolutely critical to know in what order unpartitioned areas were added to a volume set that has been repeatedly extended.

It does not matter in what order you clicked the unpartitioned areas. What does make a difference is the order in which the disks were listed on the Disk Administrator screen when you selected them, and whether that order ever changes (for example, because you changed SCSI IDs). For example, the Disk Administrator screen shot at the beginning of this section has an IDE disk (disk 0) and a SCSI disk (disk 1). If you added a new SCSI disk between these two disks, and changed the SCSI ID of the current disk, you would not be able to access the volume sets on the disk that is currently disk 1.

The information that Windows NT uses to know how to access each of these volumes is in the HKEY_LOCAL_MACHINE\SYSTEM\DISK Registry subkey. The index to that Registry subkey is provided by a four-byte disk signature that is in the first sector of each hard disk. If this disk signature is ever changed, either because you replaced the disk, through corruption, or because someone modified it by using a low-level disk editor, you lose access to the volumes. You need to know the order in which the members of the volume were selected if you ever need to reconstruct the volume by using the FtEdit program (described in Chapter 7, "Disk, File System, and Backup Utilities").

To make matters even more complex, disks have different geometries. The geometry is the number of sectors per track, number of heads (or sides) on the disk, and the total number of cylinders on the disk.

The disk geometry is most important when you are configuring fault-tolerant volumes (mirror sets and stripe sets with parity). Having identical disk geometry is critical when you are configuring your system partition as a mirror set. For the most recoverable configuration, you should have identical primary partitions on both disks of the mirror set. Having different geometries means that you will never be able to start from your shadow disk without using the Windows NT startup floppy disk. Different geometries on the original and shadow system partition also mean that you can never start from your original system partition without using the Windows NT startup floppy disk when you have had to rebuild the disk (due to hardware failure or corruption). For details about mirroring the system partition, see the section titled "Configuring the System Partition on a Mirror Set," in Chapter 5, "Preparing for and Performing Recovery."

Now you have background information about why you need to know your disk configuration, and have an appreciation for the value of a simple configuration.


Disk Sectors Critical to the Startup Process

There are two sectors on the disk that are critical to starting the computer:

  • Master Boot Record.
  • Partition Boot Sector.

These sectors contain both executable code and the data required by the code. For more information about the startup process, see "What Happens When You Start Your Computer," presented later in this chapter. For a description of problems that you might encounter with these two sectors, see Chapter 6, "Troubleshooting Startup and Disk Problems."

Note

Numbers larger than one byte are stored on x86-based computers in little endian format. For example, the sample value for the Relative Sector field in Table 3.1, 0x3F000000, is a little endian representation of 0x0000003F. The decimal equivalent of this little endian number is 63. Because most problems with the Master Boot Record and Partition Boot Sector occur on x86-based computers, the examples of these disk sectors are hexidecimal dumps from x86-based computers.


Master Boot Record

The Master Boot Record, created when you create the first partition on the hard disk, is probably the most important data structure on the disk. It is the first sector on the disk. The location is always track (cylinder) 0, head (side) 0, and sector 1.

The Master Boot Record contains the Partition Table for the disk and a small amount of executable code. On x86-based computers, the executable code examines the Partition Table, and identifies the system partition. The Master Boot Record then finds the system partition's starting location on the disk, and loads an copy of its Partition Boot Sector into memory. The Master Boot Record then transfers execution to executable code in the Partition Boot Sector.

Note

Although there is a Master Boot Record on every hard disk, the executable code in the sector is used only if the disk is connected to an x86-based computer and the disk contains the system partition.

Figure 3.5 shows a hex dump of the sector containing the Master Boot Record. The figure shows the sector in two parts. The first part is the Master Boot Record, which occupies the first 446 bytes of the sector. The disk signature (FD 4E F2 14) is at the end of the Master Boot Record code. The second part is the Partition Table.

Physical Sector: Cyl 0, Side 0, Sector 1 00000000: 00 33 C0 8E D0 BC 00 7C - 8B F4 50 07 50 1F FB FC .3.....|..P.P.. 00000010: BF 00 06 B9 00 01 F2 A5 - EA 1D 06 00 00 BE BE 07 ................ 00000020: B3 04 80 3C 80 74 0E 80 - 3C 00 75 1C 83 C6 10 FE ...<.t..<.u..... 00000030: CB 75 EF CD 18 8B 14 8B - 4C 02 8B EE 83 C6 10 FE .u......L....... 00000040: CB 74 1A 80 3C 00 74 F4 - BE 8B 06 AC 3C 00 74 0B .t..<.t.....<.t. 00000050: 56 BB 07 00 B4 0E CD 10 - 5E EB F0 EB FE BF 05 00 V.......^....... 00000060: BB 00 7C B8 01 02 57 CD - 13 5F 73 0C 33 C0 CD 13 ..|...W.._s.3... 00000070: 4F 75 ED BE A3 06 EB D3 - BE C2 06 BF FE 7D 81 3D Ou...........}.= 00000080: 55 AA 75 C7 8B F5 EA 00 - 7C 00 00 49 6E 76 61 6C U.u.....|..Inval 00000090: 69 64 20 70 61 72 74 69 - 74 69 6F 6E 20 74 61 62 id partition tab 000000A0: 6C 65 00 45 72 72 6F 72 - 20 6C 6F 61 64 69 6E 67 le.Error loading 000000B0: 20 6F 70 65 72 61 74 69 - 6E 67 20 73 79 73 74 65 operating syste 000000C0: 6D 00 4D 69 73 73 69 6E - 67 20 6F 70 65 72 61 74 m.Missing operat 000000D0: 69 6E 67 20 73 79 73 74 - 65 6D 00 00 80 45 14 15 ing system...E.. 000000E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 000000F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000100: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000110: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000120: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000130: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000140: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000150: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000160: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000170: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000180: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000190: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 000001A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 000001B0: 00 00 00 00 00 00 00 00 - FD 4E F2 14 00 00 .........N.... 80 01 .. 000001C0: 01 00 06 0F 7F 96 3F 00 - 00 00 51 42 06 00 00 00 .....?...QB.... 000001D0: 41 97 07 0F FF 2C 90 42 - 06 00 A0 3E 06 00 00 00 A....,.B...>.... 000001E0: C1 2D 05 0F FF 92 30 81 - 0C 00 A0 91 01 00 00 00 .-....0......... 000001F0: C1 93 01 0F FF A6 D0 12 - 0E 00 C0 4E 00 00 55 AA ...........N..U.

Figure 3.5. Hex Dump of the Master Boot Record for an x86-based computer

The disk signature is a unique number at offset 0x1B8 that Windows NT uses as an index to store and retrieve information about the disk in the Registry subkey HKEY_LOCAL_MACHINE\SYSTEM\DISK. The first time that you open Disk Administrator after formatting a hard disk, it displays a dialog box that informs the user that no disk signature was found on the disk. You should select Yes, or Windows NT will not be able to access the disk.

Many destructive viruses can damage the Master Boot Record and make it impossible to start the computer from the hard disk. Because the code in the Master Boot Record executes before any operating system is started, no operating system can detect or recover from corruption of the Master Boot Record. You can use the DiskProbe program on Windows NT Server Resource Kit CD to display the Master Boot Record, and compare it to the Master Boot Record shown in Figure 3.5. There are also utilities on the Resource Kit that enable you to save and restore the Master Boot Record. See Chapter 6, "Troubleshooting Disk and Startup Problems," and Chapter 7, "Disk, File System, and Backup Utilities," for more information.


Partition Table

The information about primary partitions and an extended partition is contained in the Partition Table, a 64-byte data structure located in the same sector as the Master Boot Record (cylinder 0, head 0, sector 1). The Partition Table conforms to a standard layout that is independent of the operating system. Each Partition Table entry is 16 bytes long, making a maximum of four entries available. Each entry starts at a predetermined offset from the beginning of the sector, as follows:

  • Partition 1 0x01BE (446)
  • Partition 2 0x01CE (462)
  • Partition 3 0x01DE (478)
  • Partition 4 0x01EE (494)

The last two bytes in the sector are a signature word for the sector and are always 0x55AA.

The next figure is a printout of the Partition Table for the disk shown in Figure 3.4. When there are fewer than four partitions, the remaining fields are all zeros.

80 01 .. 000001C0: 01 00 06 0F 7F 96 3F 00 - 00 00 51 42 06 00 00 00 .....?...QB.... 000001D0: 41 97 07 0F FF 2C 90 42 - 06 00 A0 3E 06 00 00 00 A....,.B...>.... 000001E0: C1 2D 05 0F FF 92 30 81 - 0C 00 A0 91 01 00 00 00 .-....0......... 000001F0: C1 93 01 0F FF A6 D0 12 - 0E 00 C0 4E 00 00 55 AA ...........N..U.

Figure 3.6. Partition Table from an x86-based computer

The following table describes each entry in the Partition Table. The sample values correspond to the information for partition 1 in Figure 3.6.

Table 3.1 Partition Table Fields

Byte Offset | Field Length | Sample Value | Meaning
00 | BYTE | 0x80 | Boot Indicator. Indicates whether the partition is the system partition. Legal values are: 00 = Do not use for booting. 80 = System partition.
01 | BYTE | 0x01 | Starting Head.
02 | 6 bits | 0x01 | Starting Sector. Only bits 0-5 are used. Bits 6-7 are the upper two bits for the starting cylinder field.
03 | 10 bits | 0x00 | Starting Cylinder. This field contains the lower 8 bits of the cylinder value. Starting cylinder is thus a 10-bit number, with a maximum value of 1023.
04 | BYTE | 0x06 | System ID. This byte defines the volume type. In Windows NT, it also indicates that a partition is part of a volume that requires the use of the HKEY_LOCAL_MACHINE\SYSTEM\DISK Registry subkey.
05 | BYTE | 0x0F | Ending Head.
06 | 6 bits | 0x3F | Ending Sector. Only bits 0-5 are used. Bits 6-7 are the upper two bits for the ending cylinder field.
07 | 10 bits | 0x196 | Ending Cylinder. This field contains the lower 8 bits of the cylinder value. Ending cylinder is thus a 10-bit number, with a maximum value of 1023.
08 | DWORD | 3F 00 00 00 | Relative Sector.
12 | DWORD | 51 42 06 00 | Total Sectors.

The remainder of this section describes the uses of these fields. Definitions of the fields in the Partition Table is the same for primary partitions, extended partitions, and logical drives in extended partitions.

Boot Indicator Field

The Boot Indicator field indicates whether the volume is the system partition. On x86-based computers, only one partition on the disk should have this field set. This field is used only on x86-based computers. On RISC-based computers, the nonvolatile RAM (NVRAM) contains the information for finding the files to load.

System ID Field

For primary partitions and logical drives, the System ID field describes the file system used to format the volume. Windows NT uses this field to determine what file system device drivers to load during startup. It also identifies the extended partition, if there is one defined.

These are the values for the System ID field:

Value | Meaning
0x01 | 12-bit FAT partition or logical drive. The number of sectors in the volume is fewer than 32680.
0x04 | 16-bit FAT partition or logical drive. The number of sectors is between 32680 and 65535.
0x05 | Extended partition. See section titled "Logical Drives and Extended Partitions," presented later in this chapter, for more information.
0x06 | BIGDOS FAT partition or logical drive.
0x07 | NTFS partition or logical drive.

Figure 3.6, presented earlier in this section, has examples of a BIGDOS FAT partition, an NTFS partition, an extended partition, and a 12-bit FAT partition.

When you create a volume set, stripe set, mirror set, or stripe set with parity, Disk Administrator sets the high bit of the System ID field for each primary partition or logical drive that is a member of the volume. For example, a FAT primary partition or logical drive that is a member of one of these volumes has a System ID value of 0x86. An NTFS primary partition or logical drive has a System ID value of 0x87. This bit indicates that Windows NT needs to use the HKEY_LOCAL_MACHINE\SYSTEM\DISK Registry subkey to determine how the members of the volume relate to each other. Volumes that have the high bit set can only be accessed by Windows NT. This bit is called the fault-tolerant (FT) bit.

When a primary partition or logical drive that is a member of one of these volumes has failed due to write errors or cannot be accessed, the second most significant bit is set. The System ID byte is set to C6 in the case of a FAT volume, or C7 in the case of an NTFS volume.

Note

If you start up MS-DOS, it can only access primary partitions or logical drives that have a value of 0x01, 0x04, 0x5, or 0x6 for the System ID. However, you should be able to delete volumes that have the other values. If you use a MS-DOS-based low-level disk editor, you can read and write any sector, including ones that are in NTFS volumes.

Starting and Ending Head, Sector, and Cylinder Fields

On x86-based computers, the Starting and Ending Head, Cylinder, and Sector fields on the startup disk are very important for starting up the computer. The code in the Master Boot Record uses these fields to find and load the Partition Boot Sector.

The Ending Cylinder field in the Partition Table is ten bits long, which limits the maximum cylinder number that can be described in the Partition Table to 1023. The Starting and Ending Head fields are one byte long, which limits this field to the range 0 – 255. The Starting and Ending Sector field is 6 bits long, limiting its range to 0 – 63. However, sectors start counting at 1 (versus 0 for the other fields), so the maximum number of sectors per track is 63.

Since current hard disks are low-level formatted with the industry standard 512-byte sector size, the maximum capacity disk that can be described by the Partition Table can be calculated as follows:

MaxCapacity = (sector size) x (sectors per track) x (cylinders) x (heads)

Substituting the maximum possible values yields:

512 x 63 x 1024 x 256 = 8,455,716,864 bytes or 7.8 GB (GB)

This calculation results in a maximum formatted capacity is slightly less than 8 GB.

However, the maximum cluster size that you can use for FAT volumes when running Windows NT is 64K, when using a 512 byte sector size. Therefore, the maximum size for a FAT volume is 4 GB.

If you have a dual-boot configuration with Windows 95 or MS-DOS, FAT volumes that might be accessed when using either of those operating systems are limited to 2 GB. In addition, Macintosh computers that are viewing volumes on a computer running Windows NT cannot see more than 2 GB. If you try to use a FAT volume larger than 2 GB when running MS-DOS or Windows 95, or access it from a Macintosh computer, you might get a message that there are 0 bytes available.

The maximum size of a FAT volume on a specific computer depends on the disk geometry, and the maximum values that can fit in the fields described in this section. The next table shows the typical size of a FAT volume when translation is enabled, and when it is disabled. The number of cylinders in both situations is 1024.

Translation mode | Number of heads | Sectors per track | Maximum size for system or boot partition
Disabled | 64 | 32 | 1 GB
Enabled | 255 | 63 | 4 GB

Note

RISC-based computers do not have a limit on the size of the system or boot partitions.

If a primary partition or logical drive extends beyond cylinder 1023, all of these fields will contain the maximum values.

Relative Sectors and Number of Sectors Fields

For primary partitions, the Relative Sectors field represents the offset from the beginning of the disk to the beginning of the partition, counting by sectors. The Number of Sectors field represents the total number of sectors in the partition. For a description of these fields in extended partitions, see the section "Logical Drives and Extended Partitions," presented later in this chapter.

Windows NT uses these fields to access all volumes. When you format a volume when running Windows NT, it puts data into the Starting and Ending Cylinder, Head, and Sector fields only for backward compatibility with MS-DOS and Windows 95, and to maintain compatibility with the BIOS interrupt (INT) 13 for startup purposes.

See the section titled "Using Disks With More Than 1024 Cylinders (x86-based Computers)," presented later in this chapter, for more information about the use of these fields.

Logical Drives and Extended Partitions

When more than four logical disks are required on a single physical disk, the first partition should be a primary partition. The second partition can be created as an extended partition, which can contain all the remaining unpartitioned space on the disk.

Note

A primary partition is one that can be used as the system partition. If the disk does not contain a system partition, you can configure the entire disk as a single, extended partition.

Some computers create an EISA configuration partition as the first partition on the hard disk.

Windows NT detects an extended partition because the System ID byte in the Partition Table entry is set to 5. There can be only one extended partition on a hard disk.

Within the extended partition, you can create any number of logical drives. As a practical matter, the number of available drive letters is the limiting factor in the number of logical drives that you can define.

When you have an extended partition on the hard disk, the entry for that partition in the Partition Table (at the end of the Master Boot Record) points to the first disk sector in the extended partition. The first sector of each logical drive in an extended partition also has a Partition Table, which is the last 66 bytes of the sector. (The last two bytes of the sector are the end-of-sector marker.)

These are the entries in an extended Partition Table:

  • The first entry is for the current logical drive.
  • The second entry contains information about the next logical drive in the extended partition.
  • Entries three and four are all zeroes.

This format repeats for every logical drive. The last logical drive has only its own entry listed. The entries for partitions 2-4 are all zeroes.

The Partition Table entry is the only information on the first side of the first cylinder of each logical drive in the extended partition. The entry for partition 1 in each Partition Table contains the starting address for data on the current logical drive. And the entry for partition 2 is the address of the sector that contains the Partition Table for the next logical drive.

The use of the Relative Sector and Total Sectors fields for logical drives in an extended partition is different than for primary partitions. For the partition 1 entry of each logical drive, the Relative Sectors field is the sector from the beginning of the logical drive that contains the Partition Boot Sector. The Total Sectors field is the number of sectors from the Partition Boot Sector to the end of the logical drive.

For the partition 2 entry, the Relative Sectors field is the offset from the beginning of the extended partition to the sector containing the Partition Table for the logical drive defined in the Partition 2 entry. The Total Sectors field is the total size of the logical drive defined in the Partition 2 entry.

Note

If a logical drive is part of a volume set, the Partition Boot Sector is at the beginning of the first member of the volume set. Other members of the volume set have data where the Partition Boot Sector would normally be located.

This Disk Administrator screen shot shows a disk having an extended partition. The extended partition contains a volume set (drive E), two logical drives (drives I and K), and 4 MB of unallocated space. This screen shot is identical to the one shown in Figure 3.4.

The following example is a printout from the DiskMap program of the information in the Master Boot Record (the section titled MBR) and the extended Partition Table entries (the sections titled EBR) for the disk configuration shown in the preceding Disk Administrator screen shot. For information about DiskMap, see Chapter 7, "Disk, File System, and Backup Utilities."

MBR: Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors * 0 1 1 406 15 63 0x06 63 410193 407 0 1 812 15 63 0x07 410256 409248 813 0 1 914 15 63 0x05 819504 102816 915 0 1 934 15 63 0x01 922320 20160 EBR: (sector 819504) Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors 813 1 1 832 15 63 0x87 63 20097 833 0 1 848 15 63 0x05 20160 16128 EBR: (sector 839664) Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors 833 1 1 848 15 63 0x01 63 16065 849 0 1 872 15 63 0x05 36288 24192 EBR: (sector 855792) Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors 849 1 1 872 15 63 0x07 63 24129 873 0 1 905 15 63 0x05 60480 33264 EBR: (sector 879984) Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors 873 1 1 905 15 63 0x87 63 33201 0 0 0 0 0 0 0x00 0 0


Partition Boot Sector

The Partition Boot Sector contains information that the file system uses to access the volume. On x86-based computers, the Master Boot Record use the Partition Boot Sector on the system partition to load the operating system Kernel files, or in the case of Windows NT, the boot loader.

The Windows NT Partition Boot Sector consists of:

  • A jump instruction.
  • The OEM name and version.
  • A data structure called the BIOS Parameter Block.
  • Another data structure called the extended BIOS Parameter Block.
  • The bootstrap code.

The BIOS Parameter Block (bytes 11 through 35 of the Partition Boot Sector) describes physical parameters of the volume. The extended BIOS Parameter Block begins immediately after the BIOS Parameter Block. The length of this structure is different for FAT and NTFS volumes. The information in the BIOS Parameter Block and the extended BIOS Parameter Block is used by disk device drivers to read and configure volumes.

The Partition Boot Sector is the first 512-byte sector at the beginning of the volume. The sector always ends with 0x55AA, which is a sector signature word that marks the end of the sector.

FAT Partition Boot Sector

Table 3.2 describes the fields in the Partition Boot Sector for a volume formatted with the FAT file system. The sample values are the data in the corresponding fields in the hex dump in Figure 3.7, presented later in this section.

Table 3.2 Partition Boot Sector for FAT volumes

Byte Offset (in hex) | Field Length | Sample Value | Meaning
00 | 3 bytes | EB 3C 90 | Jump instruction
03 | 8 bytes | MSDOS5.0 | OEM Name in text
0B | 25 bytes |  | BIOS Parameter Block
24 | 26 bytes |  | Extended BIOS Parameter Block
3E | 448 bytes |  | Bootstrap code
1FE | 2 bytes | 0x55AA | End of sector marker

The following figure is a hex printout of the Partition Boot Sector for a FAT volume. The printout is formatted in three sections:

  • Bytes 0 - 0x0A are the jump instruction and the OEM name.
  • Bytes 0x0B - 0x3D are the BIOS Parameter Block and the Extended BIOS Parameter Block.
  • The rest of the printout is the bootstrap code and the end of sector marker.

    Physical Sector: Cyl 0, Side 1, Sector 1 00000000: EB 3C 90 4D 53 44 4F 53 - 35 2E 30 <.MS-DOS5.0 00 02 08 01 00 ..... 00000010: 02 00 02 00 00 F8 C9 00 - 3F 00 10 00 3F 00 00 00 ........?...?... 00000020: 51 42 06 00 80 00 29 CE - 13 46 30 4E 4F 20 4E 41 QB....)..F0NO NA 00000030: 4D 45 20 20 20 20 46 41 - 54 31 36 20 20 20 ME FAT16 33 C0 3. 00000040: 8E D0 BC 00 7C 68 C0 07 - 1F A0 10 00 F7 26 16 00 ....|h......&.. 00000050: 03 06 0E 00 50 91 B8 20 - 00 F7 26 11 00 8B 1E 0B ....P.. ..&..... 00000060: 00 03 C3 48 F7 F3 03 C8 - 89 0E 08 02 68 00 10 07 ...H........h... 00000070: 33 DB 8F 06 13 02 89 1E - 15 02 0E E8 90 00 72 57 3.............rW 00000080: 33 DB 8B 0E 11 00 8B FB - 51 B9 0B 00 BE DC 01 F3 3.......Q....... 00000090: A6 59 74 05 83 C3 20 E2 - ED E3 37 26 8B 57 1A 52 .Yt... ...7&.W.R 000000A0: B8 01 00 68 00 20 07 33 - DB 0E E8 48 00 72 28 5B ...h. .3...H.r([ 000000B0: 8D 36 0B 00 8D 3E 0B 02 - 1E 8F 45 02 C7 05 F5 00 .6...>....E..... 000000C0: 1E 8F 45 06 C7 45 04 0E - 01 8A 16 24 00 EA 03 00 ..E..E.....$.... 000000D0: 00 20 BE 86 01 EB 03 BE - A2 01 E8 09 00 BE C1 01 . .............. 000000E0: E8 03 00 FB EB FE AC 0A - C0 74 09 B4 0E BB 07 00 .........t...... 000000F0: CD 10 EB F2 C3 50 4A 4A - A0 0D 00 32 E4 F7 E2 03 .....PJJ...2.... 00000100: 06 08 02 83 D2 00 A3 13 - 02 89 16 15 02 58 A2 07 .............X.. 00000110: 02 A1 13 02 8B 16 15 02 - 03 06 1C 00 13 16 1E 00 ................ 00000120: F7 36 18 00 FE C2 88 16 - 06 02 33 D2 F7 36 1A 00 .6........3..6.. 00000130: 88 16 25 00 A3 04 02 A1 - 18 00 2A 06 06 02 40 3A ..%.......*...@: 00000140: 06 07 02 76 05 A0 07 02 - 32 E4 50 B4 02 8B 0E 04 ...v....2.P..... 00000150: 02 C0 E5 06 0A 2E 06 02 - 86 E9 8B 16 24 00 CD 13 ............$... 00000160: 0F 83 05 00 83 C4 02 F9 - CB 58 28 06 07 02 76 11 .........X(...v. 00000170: 01 06 13 02 83 16 15 02 - 00 F7 26 0B 00 03 D8 EB ..........&..... 00000180: 90 A2 07 02 F8 CB 42 4F - 4F 54 3A 20 43 6F 75 6C ......BOOT: Coul 00000190: 64 6E 27 74 20 66 69 6E - 64 20 4E 54 4C 44 52 0D dn't find NTLDR. 000001A0: 0A 00 42 4F 4F 54 3A 20 - 49 2F 4F 20 65 72 72 6F ..BOOT: I/O erro 000001B0: 72 20 72 65 61 64 69 6E - 67 20 64 69 73 6B 0D 0A r reading disk.. 000001C0: 00 50 6C 65 61 73 65 20 - 69 6E 73 65 72 74 20 61 .Please insert a 000001D0: 6E 6F 74 68 65 72 20 64 - 69 73 6B 00 4E 54 4C 44 nother disk.NTLD 000001E0: 52 20 20 20 20 20 20 00 - 00 00 00 00 00 00 00 00 R ......... 000001F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 55 AA ..............U.

Figure 3.7. Partition Boot Sector for a FAT volume on x86-based computer

Table 3.3 shows the layout of the BIOS Parameter Block and the extended BIOS Parameter Block. The sample values correspond to the data in Figure 3.7.

Table 3.3 BIOS Parameter Block and Extended BIOS Parameter Block Fields for FAT volumes

Byte Offset | Field Length | Value | Meaning
0x0B | WORD | 0x0002 | Bytes per Sector. The size of a hardware sector. For most disks in use in the United States, the value of this field is 512.
0x0D | BYTE | 0x08 | Sectors Per Cluster. The number of sectors in a cluster. The default cluster size for a volume depends on the volume size and the file system.
0x0E | WORD | 0x0100 | Reserved Sectors. The number of sectors from the Partition Boot Sector to the start of the first file allocation table, including the Partition Boot Sector. The minimum value is 1. If the value is greater than 1, it means that the bootstrap code is too long to fit completely in the Partition Boot Sector.
0x10 | BYTE | 0x02 | Number of file allocation tables (FATs). The number of copies of the file allocation table on the volume. Typically, the value of this field is 2.
0x11 | WORD | 0x0002 | Root Entries. The total number of file name entries that can be stored in the root folder of the volume.
0x13 | WORD | 0x0000 | Small Sectors. The number of sectors on the volume if the number fits in 16 bits (65535). For volumes larger than 65536 sectors, this field has a value of 0 and the Large Sectors field is used instead.
0x15 | BYTE | 0xF8 | Media Type. Provides information about the media being used. A value of 0xF8 indicates a hard disk.
0x16 | WORD | 0xC900 | Sectors per file allocation table (FAT). Number of sectors occupied by each of the file allocation tables on the volume.
0x18 | WORD | 0x3F00 | Sectors per Track. The apparent disk geometry in use when the disk was formatted.
0x1A | WORD | 0x1000 | Number of Heads. The apparent disk geometry in use when the disk was formatted.
0x1C | DWORD | 3F 00 00 00 | Hidden Sectors. Same as the Relative Sector field in the Partition Table.
0x20 | DWORD | 51 42 06 00 | Large Sectors. If the Small Sectors field is zero, this field contains the total number of sectors in the volume. If Small Sectors is nonzero, this field contains zero.
0x24 | BYTE | 0x80 | Physical Disk Number. This is related to the BIOS physical disk number. Floppy drives are numbered starting with 0x00 for the A disk. Physical hard disks are numbered starting with 0x80. The value is typically 0x80 for hard disks, regardless of how many physical disk drives exist, because the value is only relevant if the device is the startup disk.
0x25 | BYTE | 0x00 | Current Head. Not used by the FAT file system. Therefore, Windows NT uses this field to store two flags: · The low order bit is a dirty flag, used to indicate that Windows NT should run the Chkdsk program against the volume when it starts. · The second lowest bit indicates to that a surface scan should also be run.
0x26 | BYTE | 0x29 | Signature. Must be either 0x28 or 0x29 in order to be recognized by Windows NT.
0x27 | 4 bytes | CE 13 46 30 | Volume Serial Number. A unique number that is created when you format the volume.
0x2B | 11 bytes | NO NAME | Volume Label. This field was used to store the volume label, but the volume label is now stored as special file in the root directory.
0x36 | 8 bytes | FAT16 | System ID. Either FAT12 or FAT16, depending on the format of the disk.

NTFS Partition Boot Sector

Table 3.4 describes the fields in the Partition Boot Sector for a volume formatted with the NTFS file system. The sample values are the data in the corresponding fields in the hex dump in Figure 3.8, presented later in this section.

Table 3.4 Partition Boot Sector for NTFS volume

Byte Offset (in hex) | Field Length | Sample Value | Meaning
00 | 3 bytes | EB 5B 00 | Jump instruction
03 | 8 bytes | NTFS | OEM Identifier
0B | 25 bytes |  | BIOS Parameter Block
24 | 48 bytes |  | Extended BIOS Parameter Block
54 | 426 bytes |  | Bootstrap code
1FE | WORD | 0x55AA | End of sector marker

Note

The bootstrap code for an NTFS volume is longer than the 426 bytes shown here. When you format an NTFS volume, the format program allocates the first 16 sectors for the Partition Boot Sector and the bootstrap code.

The extra data fields after the BIOS Parameter Block form an extended BIOS Parameter Block for NTFS. The data in these fields enable the boot loader to find the Master File Table (MFT) during the startup process. In the NTFS file system, the MFT is not located in a predefined sector as is the case for the file allocation table on a FAT volume. Thus, the MFT can be moved if there is a bad sector in its normal location. However, if these data are corrupt, the MFT cannot be located and Windows NT assumes the volume has not been formatted.

Note

The MFT contains information about all of the files on an NTFS volume. See Chapter 17, "Disk and File System Basics," in the Windows NT Workstation Resource Guide for details about the MFT.

The following figure is a hex dump of the Partition Boot Sector for an NTFS volume (formatted when running Windows NT 4.0). The printout is formatted in three sections:

  • Bytes 0 - 0x0A are the jump instruction and the OEM name.
  • Bytes 0x0B - 0x53 are the BIOS Parameter Block and the Extended BIOS Parameter Block.
  • The rest of the printout is the bootstrap code and the end of sector marker.

    Physical Sector: Cyl 407, Side 0, Sector 1 00000000: EB 5B 90 4E 54 46 53 20 - 20 20 20 .[.NTFS 00 02 01 00 00 ..... 00000010: 00 00 00 00 00 F8 00 00 - 3F 00 10 00 90 42 06 00 ........?....B.. 00000020: 00 00 00 00 80 00 80 00 - A0 3E 06 00 00 00 00 00 .........>...... 00000030: 10 00 00 00 00 00 00 00 - 51 1F 03 00 00 00 00 00 ........Q...... 00000040: 02 00 00 00 04 00 00 00 - 5B 1F DD 2C 4F DD 2C A2 ........[.,O.,. 00000050: 00 00 00 00 .... 00 00 00 00 - 00 00 00 00 00 FA 33 C0 ..........3. 00000060: 8E D0 BC 00 7C FB B8 C0 - 07 8E D8 C7 06 54 00 00 ....|........T.. 00000070: 00 C7 06 56 00 00 00 C7 - 06 5B 00 10 00 B8 00 0D ...V.....[...... 00000080: 8E C0 2B DB E8 07 00 68 - 00 0D 68 56 02 CB 50 53 ..+....h..hV..PS 00000090: 51 52 06 66 A1 54 00 66 - 03 06 1C 00 66 33 D2 66 QR.f.T.f....f3.f 000000A0: 0F B7 0E 18 00 66 F7 F1 - FE C2 88 16 5A 00 66 8B .....f......Z.f. 000000B0: D0 66 C1 EA 10 F7 36 1A - 00 88 16 25 00 A3 58 00 .f....6....%..X. 000000C0: A1 18 00 2A 06 5A 00 40 - 3B 06 5B 00 76 03 A1 5B ...*.Z.@;.[.v..[ 000000D0: 00 50 B4 02 8B 16 58 00 - B1 06 D2 E6 0A 36 5A 00 .P....X......6Z. 000000E0: 8B CA 86 E9 8A 36 25 00 - B2 80 CD 13 58 72 2A 01 .....6%.....Xr*. 000000F0: 06 54 00 83 16 56 00 00 - 29 06 5B 00 76 0B C1 E0 .T...V..).[.v... 00000100: 05 8C C2 03 D0 8E C2 EB - 8A 07 5A 59 5B 58 C3 BE ..........ZY[X.. 00000110: 59 01 EB 08 BE E3 01 EB - 03 BE 39 01 E8 09 00 BE Y.........9..... 00000120: AD 01 E8 03 00 FB EB FE - AC 3C 00 74 09 B4 0E BB .........<.t.... 00000130: 07 00 CD 10 EB F2 C3 1D - 00 41 20 64 69 73 6B 20 .........A disk 00000140: 72 65 61 64 20 65 72 72 - 6F 72 20 6F 63 63 75 72 read error occur 00000150: 72 65 64 2E 0D 0A 00 29 - 00 41 20 6B 65 72 6E 65 red....).A kerne 00000160: 6C 20 66 69 6C 65 20 69 - 73 20 6D 69 73 73 69 6E l file is missin 00000170: 67 20 66 72 6F 6D 20 74 - 68 65 20 64 69 73 6B 2E g from the disk. 00000180: 0D 0A 00 25 00 41 20 6B - 65 72 6E 65 6C 20 66 69 ...%.A kernel fi 00000190: 6C 65 20 69 73 20 74 6F - 6F 20 64 69 73 63 6F 6E le is too discon 000001A0: 74 69 67 75 6F 75 73 2E - 0D 0A 00 33 00 49 6E 73 tiguous....3.Ins 000001B0: 65 72 74 20 61 20 73 79 - 73 74 65 6D 20 64 69 73 ert a system dis 000001C0: 6B 65 74 74 65 20 61 6E - 64 20 72 65 73 74 61 72 kette and restar 000001D0: 74 0D 0A 74 68 65 20 73 - 79 73 74 65 6D 2E 0D 0A t..the system... 000001E0: 00 17 00 5C 4E 54 4C 44 - 52 20 69 73 20 63 6F 6D ...\NTLDR is com 000001F0: 70 72 65 73 73 65 64 2E - 0D 0A 00 00 00 00 55 AA pressed.......U.

Figure 3.8. Partition Boot Sector for a NTFS volume on an x86-based computer

The next table describes the fields for the BIOS Parameter Block and the Extended BIOS Parameter Block. The fields starting at 0x0B, 0x0D, 0x15, 0x18, 0x1A, and 0x1C are the same as the corresponding fields for FAT volumes, as described in Table 3.3.

Table 3.5 BIOS Parameter Block and Extended BIOS Parameter Block Fields for NTFS volumes

Byte Offset | Field Length | Sample Value | Meaning
0x0B | WORD | 0x0002 | Bytes per Sector.
0x0D | BYTE | 0x01 | Sectors per Cluster.
0x0E | WORD | 0x0000 | Reserved sectors.
0x10 | BYTE | 0x00 | Always 0.
0x11 | WORD | 0x0000 | Always 0.
0x13 | WORD | 0x0000 | Not used by NTFS.
0x15 | BYTE | 0xF8 | Media Type.
0x16 | WORD | 0x0000 | Always 0.
0x18 | WORD | 0x3F00 | Sectors per Track.
0x1A | WORD | 0x1000 | Number of Heads.
0x1C | DWORD | 90 42 06 00 | Hidden Sectors.
0x20 | DWORD | 00 00 00 00 | Not used by NTFS.
0x24 | DWORD | 80 00 80 00 | Not used by NTFS.
0x28 | LONGLONG | A0 3E 06 00 00 00 00 00 | Total Sectors.
0x30 | LCN | 10 00 00 00 00 00 00 00 | Logical cluster number for $MFT.
0x38 | LCN | 51 1F 03 00 00 00 00 00 | Logical cluster number for $MFTMirr.
0x40 | DWORD | 02 00 00 00 | Clusters per file record segment.
0x44 | DWORD | 04 00 00 00 | Clusters per index block.
0x48 | LONGLONG | 5B 1F DD 2C 4F DD 2C A2 | Volume Serial Number.
0x50 | DWORD | 00 00 00 00 | Checksum.

For information about the Master File Table and the $MFT and $MFTMirr files, see Chapter 17, "Disk and File System Basics," in the Windows NT Workstation Resource Guide.


What Happens When You Start Your Computer

This section describes what happens when you start a computer that has a Windows NT installed as one of the operating systems. In general, this section describes what happens at each step in the process when the computer successfully starts. Chapter 6, "Troubleshooting Startup and Disk Problems," discusses what you can do to isolate startup problems and how to recover from them.

These are the steps involved in the successful startup of Windows NT:

  • Power On Self Test (POST) processing
  • Initial startup process
  • Boot loader process
  • Selecting the operating system
  • Detecting hardware
  • Selecting a configuration
  • Loading the Kernel
  • Initializing the Kernel
  • Logging on

The order and the processing is somewhat different, depending upon the hardware platform (x86-based computer or RISC-based computer).

The startup process begins when you:

  • Power on the computer.
  • Click Shutdown and Restart on the Shutdown Computer dialog box.
  • Select Restart the computer from the Shut Down Windows dialog box.

When you see the Begin Logon dialog box, with the text Press Ctrl+Alt+Delete to log on, your computer has completed the loading of Windows NT, and has completed much of the initialization. However, startup is complete only when a user can successfully log on at the Begin Logon dialog box.

Windows NT might not start up or operate correctly if any hardware components do not initialize correctly. Startup fails if any of the files required to start Windows NT are not present in the correct folder, or if one of the files has been corrupted. Table 3.6 describes the files that x86-based computers and RISC-based computers use to start Windows NT.

Table 3.6 Files required to start up Windows NT

x86-based file | Folder | RISC-based file | Folder
NTLDR | root of startup disk | Osloader.exe | \Os\Nt40
Boot.ini | root of startup disk | no equivalent |
Bootsect.dos | root of startup disk | no equivalent |
Ntdetect.com | root of startup disk | no equivalent |
Ntbootdd.sys (SCSI only) | root of startup disk |  |
Ntoskrnl.exe | %systemroot%\ System32 | Ntoskrnl.exe | %systemroot%\ System32
Hal.dll | %systemroot%\ System32 | Hal.dll | \Os\Nt40
no equivalent |  | *.pal files (Alpha-based computers) | \Os\Nt40
SYSTEM key | %systemroot%\ System32\Config | SYSTEM key | %systemroot%\ System32\Config
device drivers | %systemroot%\ System32\Drivers | device drivers | %systemroot%\ System32\Drivers


Power On Self Test Processing

When you power on or restart a computer, it goes through its Power On Self Test (POST) routine, which determines:

  • The amount of real memory.
  • Whether the needed hardware components (such as the keyboard) are present.

Once the computer has run its POST routine, each adapter card with a BIOS runs its own POST routine. The computer and adapter card manufacturers determine what appears on the screen during the POST processing.


Initial Startup Process

The first sector on the hard disk is critical to the startup process. This sector contains the Master Boot Record and the Partition Table.

If the startup disk is a floppy disk, the first sector on the disk is the Partition Boot Sector.

For more information about the Master Boot Record, the system partition, and the Partition Boot Sector, see "Disk Sectors Critical to the Startup Process," presented earlier in this chapter.

Starting an x86-based Computer

After the POST on x86-based computers, the system BIOS attempts to locate the startup disk. If there is a floppy disk in drive A, the system BIOS uses drive A as the startup disk. If there is no disk in drive A, it then checks the first hard disk that is powered up.

Note

Some system BIOS versions enable the user to reconfigure the order in which it checks the floppy disks and hard disks for the startup disk.

When the hard disk is the startup disk, the system BIOS reads the Master Boot Record, and loads it into memory. The system BIOS then transfers execution to the Master Boot Record. The code in the Master Boot Record scans the Partition Table for the system partition. When the Master Boot Record finds the system partition, it loads sector 0 of the partition into memory, and executes the code in the sector. Sector 0 on the system partition can be a program or diagnostic program, or a Partition Boot Sector that contains startup code for an operating system. The Partition Boot Sector code starts the operating system in a manner defined by the operating system.

If there is no system partition on the first hard disk, the Master Boot Record displays errors such as the following:

  • Invalid partition table
  • Error loading operating system
  • Missing operating system

If there is a floppy disk in drive A, the system BIOS loads the first sector on the disk into memory. If the floppy is bootable, the first sector on the disk is the Partition Boot Sector. If the floppy disk is not bootable, you see errors such as:

Non-System disk or disk error Replace and press any key when ready

Starting a RISC-based Computer

After a RISC-based computer completes the POST routine, the resident ROM firmware selects a startup disk by reading a boot precedence table from nonvolatile RAM (NVRAM). What the firmware does depends upon the platform (Alpha, PPC, or MIPS computer) and the information in the NVRAM. For example, to startup from the floppy disk, the NVRAM must define it as an alternate boot selection.

The NVRAM also defines the:

  • Location for OSLOADER.
  • Path to the boot partition.
  • Folder that contains the operating system to start.

The system partition can be on any hard disk on RISC-based computers. You can use the Boot selection menu to set up or change the system partition. See "Manage Boot Selection Menu," in Chapter 19, "What Happens When You Start Your Computer," of the Windows NT Workstation Resource Guide for more information about changing the NVRAM on RISC-based computers.

The system partition on a RISC-based computer must be formatted with the FAT file system.


Boot Loader Process

The boot loader enables you to select the operating system that you want to start and loads the operating system files from the boot partition. Boot loader processing is different on x86-based and RISC-based computers.

NTLDR Functions (x86-based Computers)

NTLDR controls the operating system selection process and hardware detection prior to the Windows NT Kernel initialization. NTLDR must be in the root folder.

When NTLDR starts executing, it clears the screen and displays the boot loader message, which is:

OS Loader V4.0

OSLOADER Functions (RISC-based Computers)

On RISC-based computers, Osloader.exe performs all of the functions that are performed by the x86-based components NTLDR, Ntdetect.com, and Bootsect.dos.

The NVRAM contains environment variables that provide the functional equivalent of the Boot.ini file on x86-based computers.


Selecting the Operating System to Start

The boot loader displays the screen from which you select the operating system to start. The information on the screen is different for x86-based computers and RISC-based computers.

Boot Loader Screen (x86-based Computer)

NTLDR displays a menu from which you select the operating system to start. This screen is based upon the information in the Boot.ini file. The screen looks like this:

OS Loader V4.0 Please select the operating system to start: Windows NT Server Version 4.0 Windows NT Server Version 4.0 (VGA mode) Use and ¯ to move the highlight to your choice. Press Enter to choose. Seconds until highlighted choice will be started automatically: 29

If you do not select an entry before the counter reaches zero, NTLDR loads the operating system specified by the default parameter in the Boot.ini file. Windows NT Setup sets the default entry to the most recent copy of Windows NT that you installed. You can edit the Boot.ini file to change the default entry if you want to default to an operating system other than the most recently installed version of Windows NT.

For information about changing the Boot.ini file, see "Contents and Purpose of Boot.ini," presented later in this chapter.

Boot Menu (RISC-based Computers)

The Boot menu contains the boot options. The first selection is always the default operating system, which is the most recently installed version of Windows NT unless you change the order of the boot selections.

To change the default operating system, or add or change alternate operating system choices, see the section titled "Manage Boot Selection Menu," in Chapter 19, "What Happens When You Start Your Computer," of the Windows NT Workstation Resource Guide.

This is a sample Boot menu from an Alpha-based computer:

ARC Multiboot Alpha AXP Version 3.5-11 Copyright (c) 1993 Microsoft Corporation Copyright (c) 1993 Digital Equipment Corporation Boot Menu: Boot Windows NT Server Version 4.0 Boot an alternate operating system Run a program Supplementary menu. . . Use the arrow keys to select, then press Enter. Seconds until auto-boot. Select another option to override: 9

The first line on the Boot menu is highlighted. Pressing ENTER begins startup of the default operating system.

If you have included alternate boot selections in your NVRAM, you can select Boot an alternate operating system, which results in a screen like the following.

ARC Multiboot Alpha AXP Version 3.5-11 Copyright (c) 1993 Microsoft Corporation Copyright (c) 1993 Digital Equipment Corporation Boot Menu: Boot Windows NT Server 4.0 (Default) Boot Windows NT Server 3.51 Use the arrow keys to select, then press Enter.


Detecting Hardware

On RISC-based computers, Osloader.exe obtains the hardware information from the NVRAM.

Ntdetect.com is the hardware recognizer for x86-based computers. It collects a list of currently installed components and returns this information to NTLDR. Ntdetect.com executes after you select a Windows NT operating system on the boot loader screen (or the timer times out). When Ntdetect.com begins to execute, you see the following line on the screen:

NTDETECT V1.0 Checking Hardware . . .

Ntdetect.com detects the following components:

  • Computer ID
  • Bus/Adapter Type
  • Video
  • Keyboard
  • Communication Ports
  • Parallel Ports
  • Floppy Disks
  • Mouse/Pointing Device


Selecting a Configuration

When you have selected the version of Windows NT to start, and the boot loader has collected hardware information, you see the following screen:

OS Loader V4.0 Press spacebar now to invoke Hardware Profile/Last Known Good menu.

The boot loader waits a few seconds for you to press the spacebar. If you do not press the spacebar and you have only one hardware profile, the boot loader loads Windows NT by using the Default configuration. Otherwise, you see this screen:

Hardware Profile/Configuration Recovery Menu This menu allows you to select a hardware profile to be used when Windows NT is started. If your system is not starting correctly, then you may switch to a previous system configuration, which may overcome startup problems. IMPORTANT: System configuration changes made since the last successful startup will be discarded. Original Configuration some other hardware profile Use the up and down arrow keys to move the highlight to the selection you want. Then press ENTER. To switch to the Last Known Good Configuration, press 'L'. To Exit this menu and restart your computer. press F3. Seconds until highlighted choice will be started automatically: 5

The first hardware profile is highlighted. If you have created other hardware profiles, use the down arrow to select the one that you want to use. For more information about hardware profiles, use the Find tab in Windows NT Help and enter profile.

You can also select between the Last Known Good Configuration and the Default Configuration. Windows NT automatically uses the Default Configuration if you do not select the Last Known Good Configuration. When you use the Default Configuration, the boot loader uses the Registry information that Windows NT saved at the last shutdown.

If you switch to the Last Known Good Configuration by pressing L and ENTER, the boot loader uses the Registry information that it saved at the completion of the last successful startup to configure this startup.

For more information about control sets, the Last Known Good Configuration, and the Default Configuration, see Chapter 8, "General Troubleshooting."


Loading the Kernel

When you press ENTER on the Hardware Profile/Configuration Recovery menu or the boot loader automatically makes the selection for you, the computer is in the Kernel load phase of Windows NT startup. You see several dots as the boot loader loads the Windows NT Kernel (Ntoskrnl.exe) and the hardware abstraction layer (Hal.dll) into memory.

At this point, the boot loader creates the control set it will use to initialize the computer. The control set is either the Default control set or the Last Known Good control set. The boot loader loads the low-level device drivers based on the ones identified in the control set.


Initializing the Kernel

You know that the Kernel is initializing when the screen turns blue, and you see text similar to the following:

Microsoft (R) Windows NT (TM) Version 4.0 (Build 1345) 1 System Processor (16 MB Memory)

This means that Ntoskrnl.exe has successfully initialized and that control has passed to it.

During the Kernel initialization phase, the Kernel:

  • Initializes the low-level device drivers that were loaded in the previous phase.
  • Loads and initializes the other device drivers.
  • Runs programs, such as Chkdsk, that need to be run before it loads any services.
  • Load and initializes services.
  • Creates the page file.
  • Starts subsystems that are needed to run Windows NT.


Logging on

When Kernel initialization finishes, you see the Begin Logon dialog box, which contains the text Press Ctrl + Alt + Delete to log on. At this time, Windows NT might still be initializing network drivers, but you can logon now.

Note

Windows NT startup is not considered good until a user successfully logs on to the system.


Contents and Purpose of Boot.ini (x86-based Computers)

When you install Windows NT on an x86-based computer, Windows NT Setup puts the Boot.ini file at the root of the system partition. NTLDR uses information in the Boot.ini file to display the screen from which you select the operating system to start.

Here is a sample Boot.ini file:

[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Ver 4.0" multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Ver 4.0 [VGA mode]" /basevideo /sos

The Boot.ini file has two sections, [boot loader] and [operating system], which are described in the next two sections.


[boot loader] Section

This section contains the following information:

Parameter

Description

timeout

The number of seconds the user has to select an operating system from the boot loader screen before NTLDR loads the default operating system.

If the value is 0, NTLDR immediately starts the default operating system without displaying the boot loader screen.

You can also set this value to -1, in which case NTLDR waits forever for you to make a selection. You must edit the Boot.ini file to set the value to -1 because it is an illegal value for the System option in Control Panel.

default

The path to the default operating system.


[operating systems] Section

This section contains the list of available operating systems. Each entry includes the path to the boot partition for the operating system, the string to display in the boot loader screen, and optional parameters. There is an example of the use of this section of the Boot.ini file in the section titled "Boot Loader Screen (x86-based Computers)," presented earlier in this chapter.

The Boot.ini file supports starting multiple versions of Windows NT operating systems, as well as starting one other operating system. The other operating systems that can be included in the Boot.ini file are Windows 95, MS-DOS, and OS/2. The section "Configuring the Computer for Dual-booting and Triple-booting," in Chapter 19, "What Happens When You Start Your Computer," of the Windows NT Workstation Resource Guide, contains more information about the other operating systems.


Boot.ini Switches

There are several switches that you can add to the end of the Windows NT entries in the [operating system] section of the Boot.ini file. They are not case sensitive. Chapter 6, "Troubleshooting Startup and Disk Problems," contains more information about many of these switches. For information about the debugger, see Chapter 39, "Windows NT Debugger," in the Windows NT Workstation Resource Guide.

Table 3.7 Boot.ini Switches

Switch | Description
/BASEVIDEO | The computer starts up using the standard VGA video driver. If you have installed a new video driver, but it is not working correctly, selecting the Windows NT entry with this switch enables you to start the computer so you can change to a different driver.
/BAUDRATE | Specifies the baud rate to be used for debugging. If you do not set the baud rate, the default baud rate is 9600 if a modem is attached, and 19200 for a null-modem cable. This switch has a secondary effect of forcing the /DEBUG switch as well, whether or not use you use /DEBUG.
/CRASHDEBUG | The debugger is loaded when you start Windows NT, but remains inactive unless a Kernel error occurs. This mode is useful if you are experiencing random, unpredictable Kernel errors.
/DEBUG | The debugger is loaded when you start Windows NT, and can be activated at any time by a host debugger connected to the computer. This is the mode to use when you are debugging problems that are regularly reproducible.
/DEBUGPORT= comx | Specifies the com port to use for debugging, where x is the communications port that you want to use. Like /BAUDRATE, this switch will also force the /DEBUG mode.
/MAXMEM:n | Specifies the maximum amount of RAM that Windows NT can use. This switch is useful if you suspect a memory chip is bad. See Chapter 6, "Troubleshooting Disk and Startup Problems," for more information.
/NODEBUG | No debugging information is being used.
/NOSERIALMICE=[COMx | COMx,y,z...] | Disables serial mouse detection of the specified COM port(s). Use this switch if you have a component other than a mouse attached to a serial port during the startup sequence. If you use /NOSERIALMICE without specifying a COM port, serial mouse detection is disabled on all COM ports. See Chapter 5, "Preparing for and Performing Recovery," for more information.
/SOS | Displays the driver names while they are being loaded. Use this switch if Windows NT won't start up and you think a driver is missing. See Chapter 6, "Troubleshooting Startup and Disk Problems," for more information.


Editing Boot.ini

When you install Windows NT, the Boot.ini file has the Read Only, System, and Hidden attributes set. You can edit the timeout and default parameters in the Boot.ini file by using the System option on Control Panel, regardless of the value of these attributes.

If you want to edit the Boot.ini file by using a text editor, you need to make the file visible before you can open it, and you need to turn off the Read Only attribute to be able to make changes to it. You can change the attributes by using My Computer, Windows NT Explorer, or the command prompt.

To change the attributes in My Computer or Windows NT Explorer

1. On the View menu, click Options.

2. On the Options tab, select Show all files. Click OK.

3. Click the filename.

4. On the File menu, click Properties.

5. In the Attributes box of the General tab, clear the Read Only, System, and Hidden check boxes, and then click OK.

To change the attributes by using command prompt, enter:

attrib -s -h -r boot.ini

If you change the path to the Windows NT boot partition, make sure to edit both the default path and operating system path entries. If you change one but not the other, a new choice is added to the boot loader screen, with the default designator next to it.


Using Hard Disks With More Than 1024 Cylinders (x86-based Computers)

Windows NT can take advantage of hard disks with more than 1024 cylinders if you enable extended translation. Windows NT does not have a limit to the number of cylinders it can address, but the system and boot partitions are limited to 1024 cylinders by the system BIOS, which must use INT 13 to access the disk during startup. The section "Starting and Ending Head, Sector, and Cylinder Fields," presented earlier in this chapter, contains more information about the system and boot partitions.

The following error messages might appear when extended translation is not enabled on disks larger than 1024 cylinders, and the Master Boot Record is unable to locate the Partition Boot Sector:

  • Error loading operating system.
  • Missing operating system.

If you create your system and boot partitions in Windows NT Setup, you do not have to concern yourself with these details, because Setup will not create a partition that cannot be used to start Windows NT.

When Windows NT has completed startup, it does not use the values in the Starting and Ending Head, Sector, and Cylinder fields of the Partition Table. Instead, it uses the Relative Sectors and Number Of Sectors fields. These fields provide a full 32 bits to represent sectors, which results in volumes of up to 232 sectors.

With a standard sector size of 512 bytes, the 32-bit fields used for the Relative Sectors and Number of Sectors result in a maximum possible volume size of:

512 bytes x 4,294,967,296 = 2,199,023,255,552 bytes, or 2 TB.

When creating primary partitions or logical drives on a disk, Windows NT writes the correct values to the Partition Table fields whenever possible. When the Ending Cylinder field for an entry in the Partition Table goes beyond cylinder 1023, Windows NT writes the maximum permitted values to these fields in the Partition Table. This prevents the system BIOS from calculating the Starting and Ending addresses based on erroneous data.

There are several Knowledge Base articles that discuss using large disks. Knowledge Base articles are included on the Windows NT Server Resource Kit.


SCSI Hard Disks

If your SCSI controller can be configured to perform translation, you can create a boot partition or system partition that is within the first 1 or 4 GB of the disk, depending upon the translation used by the controller. To create the largest possible system and boot partitions, you need to enable translation on the controller. If translation was not already enabled, you will need to low-level format the hard disk, recreate partitions, and format them. Check with your hardware manufacturer for specific advice and details.

Once Windows NT has been initialized, it uses its SCSI disk device drivers to directly interact with the disk without using the BIOS INT 13 interface. Therefore, the Starting and Ending Head, Sector, and Cylinder fields are not important after the computer has completed startup.

Note

If you are using, or going to use, a mirror set for your system partition, there are reasons that you should not enable translation on the controller. See Chapter 5, "Preparing for and Performing Recovery," for more information.


IDE and EIDI Hard Disks

The system and boot partitions on IDE hard disks are also limited to 1024 cylinders if the controller does not translate the disk address. Secondary disks that do not contain the system or boot partition might not be limited to 1024 cylinders, depending on the translation scheme used by the controller and disk.

IDE disks use a different data structure for representing the number of cylinders, number of heads, and number of sectors per track than the Partition Table and BIOS INT 13 interface. According to the IDE specifications, the maximum number of cylinders is 65536, the maximum number of heads is 16, and the maximum number of sectors per track is 255. The maximum size is 136.9 GB. Because the BIOS/IDE interface has been constrained to use the lowest common denominator, the result is a limit of about 504 MB for an IDE disk on an Intel-based ISA bus computer.

There are new controllers and disk device drivers that use an Enhanced Disk Parameter Table to translate between the logical sector layout internal to the IDE disk and the logical sector layout addressable by the BIOS INT 13 interface. These disk drivers and devices can support larger disks. These disks and controllers are referred to as enhanced IDE, or EIDE, devices.


ESDI Hard Disks

ESDI disks are an older type that came before the IDE disks.

ESDI disks use the CHS (cylinder, head, sector) addressing and have a 1024 cylinder limitation. Some controller cards get around this limitation by implementing a translation scheme in the onboard controller BIOS.

The translation is totally transparent to Windows NT, and the standard disk device driver works without any change.

ESDI disks are capable of being low-level formatted with various values of sector per track, such as 53 or 63. Here are two examples:

1024 cylinders x 15 heads x 53 sectors per track x 512 bytes per sector = 398 MB

1024 cylinders x 15 heads x 63 sectors per track x 512 bytes per sector = 472 MB

Thus, using 63 sectors per track yields 74 MB more space. Windows NT is compatible with either geometry, and, depending on the disk or controller, can access cylinders beyond 1023. You can use Windows NT to create and format the disk space beyond cylinder 1023, but it cannot be accessed by MS-DOS. However, some controllers can remap the remaining cylinders beyond 1023 so that either MS-DOS or Windows NT can use the entire capacity. For example:

1632 cylinders x 15 heads x 53 sectors per track x 512 bytes per sector = 634 MB

Microsoft has tested the ESDI controllers described in the following table.

Table 3.8 Using More Than 1024 Cylinders on ESDI Controllers

Controller

Achieving Maximum Capacity

Data Technology Corp. (DTC) Model 6282-24

The maximum MS-DOS geometry is 63 sectors per track and 1024 cylinders. Windows NT can access the cylinders beyond 1023. Do not perform a low-level format on the disk using Head Mapping mode.

Data Technology Corp. (DTC) Model 6290-24

The maximum MS-DOS geometry is 63 sectors per track and 1024 cylinders. Because this controller card does not have an on-board BIOS, Windows NT cannot access the cylinders beyond 1023.

Data Technology Corp. (DTC) Model 6290 SEZ (Dual SCSI/ESDI Controller)

The maximum MS-DOS geometry is 63 sectors per track and 1024 cylinders. Windows NT can access the cylinders beyond 1023.

Data Technology Corp. (DTC) Model 6295-24

The maximum MS-DOS geometry is 63 sectors per track and 1024 cylinders. This controller card does have an on-board BIOS, so Windows NT can access the cylinders beyond 1024. Do not perform a low-level format on the disk using Head Mapping mode.

Adaptec Model 2322D

Option 1. Disable disk translation and the on-board controller BIOS. In the CMOS, use a user-defined disk type with the actual disk parameters, such as Disk Type=48, Cylinders=1632, Heads=15, Sectors per Track=53. These parameters result in a 634 MB capacity. MS-DOS is limited to the first 1024 cylinders, which makes 398 MB available. Windows NT can access beyond cylinder 1023, yielding another 236 MB.

Option 2. Both MS-DOS and Windows NT can access the entire disk. Set jumpers on the controller for Disk Splitting. Disable disk translation and the on-board controller BIOS. Set up the first physical disk in CMOS as Cylinders=1024, Heads=15, Sectors per Track=53. This gives a disk capacity of 398 MB. Set up the second disk (it appears as a physical disk) in the CMOS as Cylinders=606, Heads=15, sectors per track=53. This yields another 236 MB. Windows NT sees the disk as two physical disks.

UltraStor with PROM versions < nnnn-009

The maximum MS-DOS geometry is 63 sectors per track and 1024 cylinders. Windows NT can access the cylinders beyond 1023.

UltraStor with PROM versions >= nnnn-009

The maximum MS-DOS geometry is 63 sectors per track and 1024 cylinders. Both MS-DOS and Windows NT have access to the entire disk capacity.


Using Removable Disks and Floppy Disks

Most types of removable media can work with Window NT. Even though removable media are assigned a floppy disk icon in My Computer and Windows NT Explorer, they are not handled by the same part of the operating system. Floppy disks are handled by Floppy.sys. All SCSI-based removable media are handled through the normal SCSI disk device drivers. Most magneto-optical, Bernoulli, Syquest, and similar removable-media disks are treated like hard disks under Windows NT, and do not require special disk device drivers.

You can use My Computer or Windows NT Explorer to remove media while Windows NT is running. When pointing at the device, click the right mouse button. If the media can be ejected, the Eject command is available. If there is no Eject command in the menu, or the command is grayed, you cannot eject the media.

Note

WORM and other types of "Write once" media are not supported in Windows NT.

There are several limitations that are unique to removable media in Windows NT.

  • Removable media can only have a single primary partition. Extended partitions are not supported.
  • Removable media devices cannot be used as part of a volume set, stripe set, mirror set, or stripe set with parity.
  • It is not possible to format a floppy disk with the NTFS file system. The Windows NT operating system formats all floppy disks with the FAT file system, because the additional files required for the NTFS file system use too much space on a floppy disk.
  • If you format a removable disk with the FAT file system, you can remove the disk while Windows NT is running.
  • When you format any removable disk with the NTFS file system, or if the page file is located on removable media, you can only remove the disk after you shutdown Windows NT.


Windows NT File Systems

This section contains information about the two file systems that Windows NT supports:

  • File Allocation Table (FAT). The computer can access files on a FAT volume when it is running Windows NT, Windows 95, MS-DOS, or OS/2.
  • Windows NT File System (NTFS). The computer must be running Windows NT to be able to access files on an NTFS volume.

The FAT file system is a simple file system originally designed for small disks and simple folder structures. The FAT file system is named for its method of organization, the file allocation table, which resides at the beginning of the volume. To protect the volume, two copies of the table are kept, in case one becomes damaged. In addition, the file allocation tables and the root folder must be stored in a fixed location so that the files needed to start the system can be correctly located.

The FAT file system works the same in Windows NT as it does in MS-DOS, Windows 3.1x, and Windows 95. In fact, you can install Windows NT on your existing FAT primary partition. When running Windows NT, you can move or copy files between FAT and NTFS volumes.

Note

You cannot use Windows NT with any compression or partitioning software that requires disk device drivers to be loaded by MS-DOS. Therefore, you cannot use MS-DOS 6.0 DoubleSpaceâ or MS-DOS 6.22 DiskSpace on a FAT primary partition or logical drive that you want to access when running Windows NT.

The Windows NT file system (NTFS) provides a combination of performance, reliability, and compatibility not found in the FAT file system. It is designed to quickly perform standard file operations such as read, write, and search — and even advanced operations such as file-system recovery — on very large hard disks.

The NTFS file system includes security features required for file servers and high-end personal computers in a corporate environment. The NTFS file system supports data access control and ownership privileges that are important for the integrity of critical data. While folders shared on a Windows NT computer are assigned particular permissions, NTFS files and folders can have permissions assigned whether they are shared or not. NTFS is the only file system on Windows NT that allows you to assign permissions to individual files. However, when you move or copy a file from an NTFS to a FAT volume, permissions and other attributes unique to the NTFS file system are lost.

You can use either or both of these file systems on a computer. Which one you choose for your computer, or for an individual volume on your computer, depends on such things as:

  • How you expect to use the computer.
  • The hardware platform.
  • The size and number of hard disks.
  • Security considerations.

For more information about file systems, especially NTFS, see Inside the Windows NT File System, by Helen Custer (Microsoft Press 1994, ISBN 1-55615-660-X), which documents the NTFS file system design.


Maximum Sizes

The maximum file size and volume size for the FAT file system is 232 bytes (4 GBs). FAT can support a maximum of 65,535 clusters per volume.

The NTFS architecture is designed to use numbers up to 264 bytes (16 exabytes, or 18,446,744,073,709,551,616 bytes). In theory, it is possible to have a volume 264 bytes in size. Even if there were hardware available to supply a logical volume of that capacity, there are other limitations to the maximum size of a volume.

Partition Tables are limited by industry standards to 232 sectors. (For more information about Partition Tables, see the earlier sections titled "Partition Table" and "Using Hard Disks With More Than 1024 Cylinders (x86-based Computers)."

The sector size is a function of hardware and industry standards, and is normally 512 bytes. While sector sizes might increase in the future, the current size puts a limit on a single volume of 2 terabytes (232 * 512 bytes, or 241 bytes ).

Windows NT provides the capability to combine discontiguous disk areas when creating volume sets, stripe sets, and stripe sets with parity, but these volumes have the same limitations. Even if there were physical disks with 2 terabyte (TB) capacity, they could not be combined to create larger volumes without increasing the physical sector size.

There is one case where you can combine disks that exceed the 2 TB limit. In Disk Administrator, there is an option to extend a volume set. You do this by selecting an existing primary partition, logical drive, or volume set that is already formatted as NTFS. You can then combine it with one or more areas of free space and select Extend Volume Set from the Partition menu. You end up with a larger NTFS volume set. However, if anything goes wrong with a volume set larger than 2 TB, you cannot just reformat it. You must again start with a smaller volume set (<=2 TB) and use the Extend Volume Set selection to extend the volume set to larger that 2 TB.

For the time being, 2 TB should be considered the practical limit for both physical and logical volumes using NTFS.

With the NTFS file system, you can have a maximum of 232 clusters per file. This is an implementation limitation, not a file size restriction.

There is no specific limit to the number of files on an NTFS volume. However, you will not be able to create any new files when your volume is so full that Windows NT cannot allocate another entry in the MFT.


Which File System to Use on Which Volumes

This is a general recommendation for determining which file systems to use for which volumes:

  • Use a small FAT primary partition (between 250 and 500 MB, depending on the total disk space and page file size) as the C drive. Use this partition for both your system and boot partition.
  • Format the rest of your disk space as NTFS, and use the NTFS volumes for application programs and data. You might want to create more than one NTFS volume.

This arrangement gives you the following benefits:

  • You have the recoverability of the NTFS file system for the most important information, your data. (You should always maintain your system and boot partitions by using backup tapes and creating an Emergency Repair Disk, as described in Chapter 5, "Preparing for and Performing Recovery.")
  • FAT is more efficient for smaller volumes and NTFS is more efficient for larger volumes.
  • NTFS provides file and folder security for your application programs and data.
  • If you have a startup failure on an x86-based computer, this means that you can start up the computer with an MS-DOS bootable floppy disk to troubleshoot and recover from the problem.

These additional guidelines might affect your decision as to which file system(s) to use on your computers:

  • For an x86-based computer, when Windows NT starts up, it looks for certain files in the root folder of the hard disk that contains the system partition. This partition can be formatted with either the NTFS or FAT file system. This partition should be large enough to accommodate all the files you need to access under that file system.
  • For a RISC-based computer, the system partition must be formatted with the FAT file system. You can use the NTFS file system on your boot partition, which needs to be large enough for all Windows NT system components. If you configure your partitions in this way, your system partition should be 5-10 MB, and your boot partition should be at least 160 MB, 250-500 MB to allow for growth.
  • Because you must format your system partition with the FAT file system on RISC-based computers, you can use Disk Administrator to secure the system partition. This prevents anyone who does not have administrative privileges from accessing the system partition in spite of the fact that it is formatted as FAT. See online Help for the Disk Administrator for more information.

Note

The system partition contains the Partition Boot Sector and other files needed to load the operating system, such as NTLDR (for x86-based computers) and OSLOADER (for RISC-based computers). The boot partition needs to include the folder with the operating system. The boot partition and the system partition can be a single partition with other folders in it.


Controlling Access to Files and Folders

On NTFS volumes, you can set permissions on files and folders that specify which groups and users have access to them, and what level of access is permitted. NTFS file and folder permissions apply both to users working at the computer where the file is stored and to users accessing the file over the network when the file is in a shared folder. With NTFS you can also set share permissions, which operate on shared folders in combination with file and folder permissions.

Note

To preserve permissions when you copy or move files between NTFS folders, use the Scopy program on the Windows NT Server Resource Kit CD.

With FAT volumes, you cannot set any permissions on the individual files and folders. The only security is share permissions that are set on the entire share, affect all files and folders on that share, and only function over the network. Once a folder is shared, you can protect the shared folder by specifying one set of share permissions that applies to users for all files and subfolders of the shared folder. Share permissions are set in very much the same way as file and folder permissions are set in NTFS. But because share permissions apply globally to all files and folders in the share, they are significantly less versatile than the file and folder permissions used for NTFS volumes.

Share permissions apply equally to NTFS and FAT volumes. They are enforced by Windows NT, not the individual file system.

Chapter 4, "Managing Shared Resources and Resource Security," in the Windows NT Server Concepts and Planning book, contains several sections that describe setting and using file and folder permissions on FAT and NTFS volumes.


NTFS Compression

Windows NT supports compression on an individual file basis for NTFS volumes. Files that are compressed on an NTFS volume can be read and written by any Windows-based application without first being decompressed by another program. Uncompression happens automatically during the read of the file. The file is compressed again when it is closed or explicitly saved.

Compressed files and folders have an attribute of C when viewed in My Computer or Windows NT Explorer. You can select an alternate color for compressed files and folders by:

  • On the View menu, click Options.
  • On the View tab, check Display compressed files and folders with alternate color.

Only the NTFS file system can read the compressed form of the data. When an application like Microsoft Word for Windows or an operating system command like Copy requests access to the file, the NTFS file system uncompresses the file before making it available. For example, if you copy a compressed file from a another Windows NT computer to a compressed folder on your hard disk, the file will be uncompressed, copied, and recompressed.

This compression algorithm is similar to that provided by the MS-DOS 6.0 DoubleSpaceâ and MS-DOS 6.22 DriveSpaceä compression, with one important difference — the MS-DOS functionality compresses the entire volume, while the NTFS file system enables the user to compress individual files and folders in the NTFS volume.

NTFS compression is not supported for cluster sizes larger than 4K, because

  • Compression causes a performance degradation.
  • The reason you use very large (>4K) clusters is to improve performance in some special cases.

Therefore, you should not use compression and large clusters at the same time. In other words, compression performs reasonably well on sizes up to 4K, but beyond that size, the savings in disk space is not worth the decrease in performance. When the cluster size is >4K on an NTFS volume, none of the NTFS compression functions are available.

Other compression utilities are available to compress files on computers running Windows NT. These utilities differ from NTFS compression in the following ways:

  • They usually can be run only from the command line.
  • Files cannot be opened when they are in a compressed state — the file must first be uncompressed by using the companion program to the one used to compress the file. When you close the file, it is saved in an uncompressed state, and you have to use a program to compress it.

The Windows NT Server Resource Kit includes a compress program and an expand program. These compress program can only be run from the command line. The expand program is a Windows-based application. There is also an expand program on the Windows NT Server product CD, which you need to run from the command line. For more information about these utilities, see "File System Utilities" in Chapter 10, "Disk, File System, and Backup Utilities."

As described earlier, the DoubleSpace and DriveSpace compression features in MS-DOS cannot be used when running Windows NT.


NTFS Recoverability

A lazy-write file system, such as the FAT file system when running Windows NT, uses an intelligent cache-management strategy and provides a way to recover data (such as the Chkdsk program) if there is an error when writing to the disk. All data are accessed via the file cache. While the user searches folders or reads files, data to be written to disk accumulates in the file cache. If the same data are modified several times, all those modifications are captured in the file cache. The result is that the file system needs to write to disk only once to update the data.

NTFS is recoverable file system. It combines the speed of a lazy-write file system with virtually instant recovery.

The NTFS file system guarantees the consistency of the volume by using standard transaction logging and recovery techniques, although it doesn't guarantee the protection of user data. It includes a lazy-write technique plus a volume-recovery technique that takes typically only a second or two to insure the integrity of all NTFS volumes each time the computer is restarted.

Effects of File and Disk Cache on Recoverability

The file cache is just an area of RAM that contains the data. When you write data to disk, Windows NT's lazy-write technique says that the data are written, when, in fact, they are still in RAM.

There can also be cache memory on the disk controller or on the disk itself. If you are running MS-DOS or Windows 3.1x, using the disk or controller cache can really help performance. Windows NT's use of the lazy-write technique improves performance to the point where you might not see much more improvement by using the cache on the disk or the controller.

This information should help you decide whether you want to enable the disk or controller cache:

  • If disk performance is an issue, and specifically if the disk is being heavily written, turning on write caching is an option for improving performance, especially if it can be measured to improve the performance of the system.
  • Controlling the write-back cache is a firmware function provided by the disk manufacturer. See the documentation supplied with the disk. You cannot configure the write cache from Windows NT.
  • Write caching does not impact the reliability of the file system's own structures (metadata). NTFS instructs the disk device driver to insure that metadata writes get written through regardless of whether write caching is enabled or not. Non-metadata is written to the disk normally, so caching can occur for such data.
  • Read caching in the disk has no impact on file system reliability.


Automatic Recovery from Disk Errors

This section discusses how Windows NT automatically recovers from some kinds of disk errors. You do not even know that an error occurred.

Windows NT provides two kinds of disk error recovery:

  • Dynamic data recovery by using sector sparing, which is only available on SCSI disks that are configured as part of a fault-tolerant volume. Sector sparing works on fault-tolerant volumes because a copy of the data on the sector with the error can be regenerated.
  • NTFS cluster remapping.

Windows NT Server provides additional recovery mechanisms for fault-tolerant volumes (mirror sets and stripe sets with parity). For more information about fault-tolerant volumes, see Chapter 5, "Preparing for and Performing Recovery."

The following table summarizes what happens if a sector goes bad on a computer running Windows NT Server. There is more information about sector sparing and cluster remapping following the table. For more details, see Chapter 5, "Volume Management and Fault Tolerance" in the book Inside the Windows NT File System.

Description | FtDisk installed with a SCSI disk that has spare sectors | FtDisk installed with a non-SCSI disk or disk with no spare sectors | FtDisk not installed with any kind of disk
Fault-tolerant volume (Windows NT Server only) | 1. FtDisk recovers the data. 2. FtDisk replaces the bad sector. 3. File system doesn't know about the error. | 1. FtDisk recovers the data. 2. FtDisk sends the data and bad-sector error to the file system. 3. NTFS performs cluster remapping. 4. FAT doesn't do anything about the error. | N/A
Non-fault-tolerant volume | 1. FtDisk can't recover the data. 2. FtDisk sends a bad-sector error to the file system. 3. NTFS performs cluster remapping. On a read operation, data are lost. 4. FAT loses the data on both read and write. | 1. FtDisk can't recover the data. 2. FtDisk sends a bad-sector error to the file system. 3. NTFS performs cluster remapping. On a read operation, data are lost. 4. FAT loses the data on both read and write. | 1. Disk driver returns a bad-sector error to the file system. 2. NTFS performs cluster remapping. On a read operation, data are lost. 3. FAT loses the data on both read and write.

Note

FtDisk is the device driver that handles I/O to volume sets, stripe sets, mirror sets, and stripe sets with parity. However, volume sets and stripe sets are not fault tolerant, so processing of an error on one of these volumes falls into the non-fault-tolerant volume category.

Sector Sparing

If a disk read error occurs on a file on a fault-tolerant volume on a hard disk connected to a SCSI controller, Windows NT Server uses a technique called sector sparing to recover the data. Windows NT Server obtains a spare sector from the disk device driver to replace the bad sector. It then recovers the data by reading the sector from the mirror disk or recalculating the data from a stripe set with parity, and writes the data to the new sector.

This processing is transparent to any applications performing disk I/O. Sector sparing eliminates error messages such as the "Abort, Retry, or Fail?" that occur when a file system encounters a bad sector.

Cluster Remapping

With transaction logging and recovery, NTFS guarantees that the volume structure will not be corrupted, so all files remain accessible after a system crash. However, user data can be lost because of a system crash or a bad sector.

The NTFS file system implements a recovery technique called cluster remapping. When Windows NT returns a bad sector error to the NTFS file system, NTFS dynamically replaces the cluster containing the bad sector and allocates a new cluster for the data. If the error occurred during a read on a non-fault-tolerant volume, NTFS returns a read error to the calling program, and the data are lost. When the error occurs during a write, NTFS writes the data to the new cluster, and no data are lost.

NTFS puts the address of the cluster containing the bad sector in its Bad Cluster File so the bad sector will not be reused.


Using MS-DOS-based Disk Utilities

Do not use any third-party MS-DOS-based disk program to repair or defragment a FAT volume used by Windows NT unless the disk program has been certified as being compatible with Windows NT version 3.5 or later. While instances of third-party utilities corrupting FAT volumes are relatively rare, some problems have occurred. Using non-Windows NT utilities are simply not worth the risk of losing an entire volume. Even the MS-DOS-based program Defrag might not work correctly if you have long filenames in the FAT volume.

You can use the Windows NT command prompt program Chkdsk to scan and repair FAT and NTFS volumes. This program incorporates all of the functionality of the MS-DOS-based Chkdsk and Scandisk utilities, including a surface scan. To do a surface scan, use chkdsk /r.

There is a Windows NT-based program available that can defragment both FAT and NTFS volumes. Microsoft has a directory that contains information about hardware and software programs that are available for Windows NT, including defragmentation utilities. This directory is called InfoSource. For information about InfoSource, see http://www.microsoft.com/infosource.

Disk media verification can be done with the SCSI utilities that ship with most SCSI controllers. Consult the documentation accompanying your hardware or contact your hardware vendor for information on verification of disk media. It is always a good idea to do a complete backup of the disk before starting a procedure of this type.


Generating and Viewing Short Filenames

Filenames on Windows NT platforms can be up to 256 characters, and can contain spaces, multiple periods, and special characters that are illegal in MS-DOS filenames. These long filenames use the 16-bit Unicode character set. Windows NT makes it possible to access files with long names from other operating systems by automatically generating an MS-DOS – readable (eight-plus-three) name for each file. This way, files are accessible over a network by computers using the MS-DOS, Windows 3.1x, and OS/2 operating systems, as well as by computers using Windows NT and Windows 95 operating systems. When an application saves a file on a computer running Windows NT, both the eight-plus-three filename and long filename are retained.

Note

Use caution with MS-DOS-based or Windows 3.x-based applications when running under Windows NT. With these applications, if you save a file to a temporary file, delete the original file, and rename the temporary file to the original filename, the long filename is lost. Any unique permissions set on that file are also lost.

If the long name of a file or folder contains spaces, be sure to surround the name with quotation marks. For example, if you have a program called DUMP DISK FILES that you want to run from the Start icon and you enter the name without quotation marks, you will get an error message that says "cannot find the program DUMP or one of its components."

You must also use quotation marks when a path typed at the command line includes spaces, as in the following example:

move "c:\This month's reports\*.*" "c:\Last month's reports"

Use wildcards such as * and ? carefully in conjunction with the del and copy command prompt commands. Windows NT searches both long and short filenames for matches to the wildcard combination you specify, which can cause extra files to be deleted or copied.

To copy or move files with case-sensitive long filenames, it is safest to select the files using a mouse in Windows NT Explorer and My Computer. That way, you can clearly identify which files you want to copy or move.

Because both the FAT file system and the NTFS file system use the Unicode character set for their names, there are several illegal characters that MS-DOS cannot read in any filename. To generate a short MS-DOS – readable filename for a file, Windows NT deletes all of these characters from the long filename and removes any spaces. Since an MS-DOS-readable filename can have only one period, Windows NT also removes all extra periods from the filename. Next, Windows NT truncates the filename, if necessary, to six characters and appends a tilde (~) and a number. For example, each nonduplicate filename is appended with ~1. Duplicate filenames end with ~2, ~3, and so on. Filename extensions are truncated to three or fewer characters. Finally, when displaying filenames at the command line, Windows NT translates all characters in the filename and extension to uppercase.

When there are five or more files that would result in duplicate short filenames, Windows NT uses a slightly different method for creating short filenames. For the fifth and subsequent files, Windows NT:

  • Uses only the first two letters of the long filename.
  • Generates the next four letters of the short filename by mathematically manipulating the remaining letters of the long filename.
  • Appends ~1 (or another number, if necessary, to avoid a duplicate filename) to the result.

This method provides substantially improved performance when Windows NT must create short filenames for a large number of files with similar long filenames. Windows NT uses this method to create short filenames for both FAT and NTFS volumes.

For example, these are the long and short filenames for six files that you create in the order test 1 through test 6.

Long filename | Short filename
This is test 1.txt | THISIS~1.TXT
This is test 2.txt | THISIS~2.TXT
This is test 3.txt | THISIS~3.TXT
This is test 4.txt | THISIS~4.TXT
This is test 5.txt | TH0FF9~1.TXT
This is test 6.txt | THFEF5~1.TXT

However, when you create the files in the order shown in this table, you get the following short filenames.

Long filename | Short filename
This is test 2.txt | THISIS~1.txt
This is test 3.txt | THISIS~2.txt
This is test 1.txt | THISIS~3.txt
This is test 4.txt | THISIS~4.txt
This is test 5.txt | TH0FF9~1.txt
This is test 6.txt | THFEF5~1.txt

Windows NT displays the long names for folders and files. You can use Windows NT Explorer and My Computer to see the short name by selecting the file or folder and selecting Properties on the File menu.

From the command line, to see both the long and short filenames for each file in the folder, type the following command:

dir /x

Tip

To display both long and short filenames automatically when using the dir command, use the System option in Control Panel to set the dircmd variable to the value /x.


Chapter 4 - Planning a Reliable Configuration

This chapter discusses planning what to do when failures occur from the viewpoint of:

  • Deciding what hardware and software to procure.
  • Developing your plan for doing backups.
  • Developing training plans, disaster plans, and contingency plans.

Chapter 5, "Preparing for and Performing Recovery," discusses what information about your computers and which data on your computers you should back up. It also describes using these backups to recover from failures.

When planning an installation that includes computers running Windows NT Server and Windows NT Workstation, consider questions such as the following:

  • How many computers running Windows NT Server and how many computers running Windows NT Workstation do you need for your enterprise?
  • Are there computers running operating systems other than Windows NT Server and Windows NT Workstation in your enterprise?
  • Where should the computers be located, and how should they be connected?
  • How many single points of failure can you tolerate in your enterprise?
  • What fault tolerance methods should you implement?
  • Which data on the computers needs to be backed up, and what is your backup strategy?
  • What records do you need to maintain to be able to troubleshoot problems or recover from failures?
  • Where are you going to store your backups and other records necessary to your operation?

For each individual computer that is going to be using Windows NT Server or Windows NT Workstation, consider questions such as the following:

  • What file system(s) should you use?
  • How many controllers and disks do you need, and how should they be configured?
  • Should some of your data be configured on fault-tolerant volumes?

If so, should you buy fault-tolerant hardware that can be used on a computer running Windows NT Workstation or Windows NT Server?

Or do you want to use the fault-tolerant software features available in Windows NT Server?

Another important topic to consider is disaster planning. Have you developed and tested solutions to occurrences such as fires, floods, and power outages before a disaster occurs?


Planning Considerations

This section discusses topics that you should consider in your planning and describes where you can find more information.


Planning Approaches

There are three ways that you can approach planning:

  • Top-down execution and responsibility.
  • Bottom-up execution and responsibility.
  • Top-down policy and bottom-up planning and execution.

In the top-down execution and responsibility, one department in the company is responsible for planning and coordination for all departments. With this method, you might have a centralized operations staff that is responsible for all or most of the computers running Windows NT Server, and for doing all of the backups. This method enables you to create a group with specialized, expert knowledge for developing procedures, procuring and installing hardware, doing testing, and training personnel. The disadvantage to this approach is that the specialized group might not understand how a particular department's data relates to the overall business. Each department is just one of many, and therefore might not get the appropriate attention.

In the bottom-up execution and responsibility, each department is responsible for developing its own plans and implementing them. Each department would probably be responsible for all of the computers that they use, and would develop their own backup procedures. The impact of the loss of a department's data is better understood by the department's management. However, this approach might cost more, because each department needs to have its own personnel and to do its own research.

In top-down policy and bottom-up planning and execution, one department or group develops the overall planning guidelines. Each department is responsible for developing its own plans and procedures. The individual departments are also responsible for implementing their procedures. With this method, there is a consistent approach, and each department knows what details are important to its successful operation.

Whichever approach you use, continuous improvement and updates are better than total rewrites as new information, policies, procedures, and the like become available.


Security

An important area to consider in your planning is minimizing the effects of human error or deliberate sabotage attempts. If anyone can walk up to your computer running Windows NT Server and restart it, no amount of security that you implement by using software can protect your computer. Not only can they damage information on the computer, but they can steal information from your computer.

You can implement procedures that restrict peoples' physical access to your facility, or to only those areas to which they should need access. Put your computers in a secure room. Lock them. Use a password on your screen saver. Run virus checks on floppy disks before you use them. Or disable the floppy disk, which you can sometimes do by using BIOS options. Otherwise, you can physically disconnect it. Run virus checks on your computer.

Windows NT enables you to manage what your users can and cannot do by creating profiles for each of your users and restricting their access to files and servers. But no amount of planning will cover all of the ways people can cause damage to data on your computers or the computers themselves. Consider security when you develop your backup and storage procedures.

Windows NT Server includes software to write information to the security event log and to audit the log for possible attempts to breach security. You can log things like:

  • Access to files.
  • Invalid logon attempts.
  • All logons.

The Audit policy controls what types of events are recorded in the security log.

Chapter 2, "Network Security and Domain Planning," in the Windows NT Server Networking Guide, contains information about security policies. Chapter 3, "Managing User Work Environments," and Chapter 4, "Managing Shared Resources and Resource Security," in the Windows NT Server Concepts and Planning book, contain more information about security features. Chapter 6, "Windows NT Workstation Security Model," in the Windows NT Workstation Resource Guide, contains more information about physical security as well as security features available when you are running Windows NT. There is also more information in Windows NT Help.


Hardware and Software Upgrades

Expect to do hardware and software upgrades. Planning when and how to do the upgrades can minimize the time they take and the risk that something will go wrong.

This sections lists things to consider in planning for upgrades. There is more information about many of these topics in other sections of this chapter. Chapter 5, "Preparing for and Performing Recovery," and Chapter 6, "Troubleshooting Startup and Disk Problems," also contain more information about many of these topics.

When doing hardware or software upgrades:

  • Never upgrade without backing up data files that you must have.
  • Be sure to back up the Registry, Master Boot Record, Partition Boot Sector, and other critical system data.
  • Have a current Emergency Repair Disk for each computer.
  • Have records of the configuration of the computer, such as jumper and DIP switch settings, IRQs, and the hard disk configuration.

The Windows NT Server Resource Guide and the Windows NT Workstation Resource Guide contain information about deploying Windows NT.


Maintenance and Record Keeping

Routine, planned maintenance can prevent problems or minimize their effects. For example, if there are file system problems, you might not know about them until you restart the computer, when the Chkdsk program tells you that there are errors. Backups can even be corrupt in some situations, because no backup program, including Windows NT Backup, can detect corrupt user data.

Administrators should check both the system and application event logs on a daily basis. Impending file system problems might show up as errors in the system log before the file system is corrupt. Be sure to investigate any messages in the event log from FtDisk or disk device drivers.

Disk fragmentation can cause performance problems. You should consider running a defragmentation program on a regular basis. There are third-party defragmentation utilities that run under Windows NT and can defragment both FAT and NTFS volumes. Be sure to only use utilities that are designed for Windows NT. Microsoft has a directory that contains information about hardware and software programs that are available for Windows NT, including defragmentation utilities. This directory is called InfoSource. For information about InfoSource, see http://www.microsoft.com/infosource.

Create a log book for every computer, which should contain information about the computer's configuration. To make recovery easier, there are several system files that you should back up every time you make certain changes to your Windows NT configuration. For information about these topics, see the section "Maintaining Configuration and Essential System Information" in Chapter 5, "Preparing for and Performing Recovery."


Maintaining Reference Information

Create a technical reference library for all hardware and software documentation. This library can also include other documentation related to your computers that you want to have in a central location. The types of information for this library are:

  • Vendor documentation, including manuals, receipts, warranties, proofs of purchase, and the like.
  • Insurance policy and any claims.
  • Information about any kits, tools, and add-ons that you have installed.
  • All internal documentation that you have generated, including policies, procedures, training guides, and the like.
  • Hardware configuration information for each of the computers, including, but not limited to, the following:
    • Their location, cabling, intermediary devices, and external connections.
    • Computer type, model number, serial number, motherboard, and CPU.
    • Computer BIOS manufacturer and revision level (x86-based computers) or firmware revision level (RISC-based computers).
    • CMOS information for x86-based computers.
    • Firmware information on RISC-based computers.
    • For each component, information such as IRQ, DMA addresses, and I/O port.
    • Amount of RAM, parity or non-parity.
    • Information about the video display and the video card.
    • Complete configuration of the disk subsystem, including the makes, models, and serial numbers of all disks and controllers, and their type (such as SCSI or EIDE).
    • Configuration information for other storage media, such as tape, optical disk, or removable disk.
    • Types and configuration of network cards.
    • Configuration information about any other adapters, such as multiport adapters.
  • Software configuration information and backups for each computer, including:
    • Disk map, describing location and size of each partition and logical drive.
    • Backups of each Master Boot Record and Partition Boot Sector.
    • Windows NT startup floppy disk.
    • Windows NT versions installed and the partitions on which they are installed.
    • User information, including which users are allocated disk space and what utilities and application programs they are using.
    • Backups of the system configuration files, including the Registry.
    • Which application programs are installed on which volumes.
    • Licensing information.
  • Phone List
    • Notification plan of who to contact for which kinds of problems or emergencies, and how to notify them.
    • Administrators.
    • Vendor and consultant support.
    • Management.
    • Critical Users.


Disaster Planning

Just as every business needs to plan and budget for future growth, you need to have a plan for dealing with total or partial loss of business data.

In order to determine what provisions to make for partial or complete loss of data, you need to determine the approximate dollar and manpower cost of rebuilding or replacing the data your company uses. You should consider the following questions:

  • Do you know the cost of reconstructing your company's financial, personnel, and other business data?
  • Do you know if your business insurance would cover any or all of the cost of replacing data?
  • Do you know how long it would take to reconstruct your business data? How would this translate into lost future business?
  • Do you know the cost per hour of server downtime?

To prevent a natural disaster or sabotage from becoming an even worse financial disaster for your business, test your plan for recovering and restoring your company's critical data. You should keep copies of your disaster recovery plan both on site and off site, and key personnel should consider keeping a copy at home.

Because there are many articles in magazines and entire books that discuss disaster planning and recovery, this section does not go into detail about any aspect of disaster planning. Instead, it describes topics that you should think about in your planning. Your insurance company should also be able to provide you with information to help you.

There are several areas that need to be addressed in developing a comprehensive disaster recovery plan. Some of the topics that you should consider in your disaster planning are also topics that you should follow in your day-to-day operations.

A comprehensive disaster plan should address all of the following issues:

  • What data do you need to back up and how often should you do backups?
  • Saving critical computer or other hardware configuration information that is not saved during normal tape backups.
  • What data needs to stored on site, and how should it be physically stored?
  • What data should be stored off site, and how should it be physically stored?
  • What training is required so server operators and administrators can respond quickly and effectively if an emergency occurs.

There is more information about each of the preceding topics in this chapter and in Chapter 5, "Preparing for and Performing Recovery."


Contingency Planning

This section identifies topics you should consider in your contingency planning.

Identifying Costs of a Failure

There are several ways to measure costs. Some costs are easy to understand and to calculate, such as the following:

  • Replacement costs for file servers, mail servers, or print servers.
  • Replacement costs for servers running applications such as Microsoft SQL Server or Systems Management Server (SMS).
  • Replacement costs for gateway servers running Microsoft RAS, SNA, Proxy, or NetWare.
  • Workstation replacement costs for personnel in different departments.
  • Replacement costs for individual computer components, such as a hard disk or a network card.

But measuring the cost of server downtime to a department or your company can be more difficult.

And how do you measure the cost of a server failure on:

  • Lost sales.
  • Lost customer goodwill.
  • Lost employee productivity and confidence.
  • Increased costs because of makeup time.
  • Missed contractual obligations or possible legal liabilities.
  • Perishable products going to waste.
  • Loss of competitiveness.

If you have kept records of failures, you might find them useful in your contingency planning. You can investigate ways to avoid each failure, or to minimize the downtime associated with the failure. If you have cost information for the failures, you can then compare the cost of each failure to the cost of preventing or minimizing the failure.

Here are two examples:

Failure | File server in sales department down, network card failure. | Router failure between development and testing department.
Effect | Lost sales | Lost productivity of employees.
Total downtime last year. | 3 hours. | 16 hours.
Costs of failure per hour. | $10,000 | Average hourly wage of 10 affected employees is $18/hr.
Total downtime costs last year. | $30,000 | $2,880
Possible resolution or workaround. | 3 spare network cards @ $500 each. | Put an alternate router in place or obtain a spare router.
Expected costs of resolution or workaround. | $1,500 | $500 - $2,000
Estimated savings during first year with resolution in place. | $28,500 | $880-$2,380

What Components in the Computer Might Fail

A server failure is typically the most costly with respect to a corporation's business, whether it is a file server, a print server, or an applications server. This section discusses the components within the computer to help you decide how to configure it. You should also regularly run diagnostics on the individual components.

Motherboard and CPU (Central Processing Unit)

Motherboards consist of electronics that can and do fail, yet the motherboard and the CPU are the more reliable computer components. There is not a lot you can do to avoid a motherboard failure or CPU fault, except to regularly run system checks that ensure they are functioning correctly. Some vendors provide systems having built-in diagnostics that operate with Windows NT.

RAM

There are three major types of RAM, in the sense of error detection and correction.

  • Parity RAM. Parity RAM has an extra bit that indicates if each byte in the RAM is good or faulty. When parity RAM detects a parity difference, it signals the CPU through a Non-Maskable Interrupt (NMI). Depending on where and when this happens, Windows NT determines if this is an I/O board parity error, memory bus error, or some other kind of parity error. Windows NT can also report I/O channel parity errors from cards in slots. You get an error message in these cases, and sometimes the computer stops.
  • Error Corrective Coding (ECC) RAM. High-end systems often use ECC RAM, which can detect a two-bit failure and correct a single-bit failure in the system memory. Windows NT continues to run in spite of a single-bit failure. Depending on the hardware vendor's design, there might or might not be a report of this corrective action.
  • Non-parity RAM. If you are using non-parity RAM, Windows NT has no way to detect memory problems, and your computer might crash randomly and inconsistently. Non-parity RAM is cheaper, and parity RAM is not available for all computers. If you do not have parity RAM in your computers, ask your vendors if parity RAM can be installed or supported by the computer.

There are a few vendors that supply products that you can use to check the RAM in a computer.

Video Cards

Video cards drive the screen as well as render images for display. Video cards rarely will cause a computer to crash, but rather, might cause the computer to behave erratically, which can be confusing to diagnose. More often, video cards cause screen redraw problems, application page faults, and the like. These problems are usually not critical enough to require you to shutdown the computer. To minimize video problems, be sure that your computer is running with the most recent release of a supported video driver from Microsoft, or the third-party vendor selling that card.

Disks and Disk Controllers

You should investigate IDE, EIDE, and SCSI technologies, because each offers different benefits with respect to fault tolerance and recovery. You have many choices for your disk configuration, including fault-tolerant configurations. The meantime between failures (MTBF) gives you a measure of expected reliability of disks and controllers.

Be sure to run disk and controller diagnostics during every preventive maintenance period. Diagnostics should be available from your hardware vendor. Windows NT automatically runs its Chkdsk program every time you start up, and you can run a surface scan of the disks by specifying chkdsk /r.

Backup Devices

Verifying your backups by doing test restores is the best way to make sure that your backup devices and media are working correctly.

Network Cards

FDDI, CDDI, and ATM network cards can have dual-channel connections. If one channel goes down, the other channel is automatically used.

Ethernet and token ring network cards do not have a dual-channel capability. If the manufacturer provides a diagnostic program, you should run diagnostics on the network cards during scheduled preventive maintenance or down-time periods.

You can evaluate network segments with network packet trace programs, called sniffers. The Windows NT Network Monitor can check for:

  • Bad cyclic redundancy checks (CRC).
  • Corrupted packets.
  • Bandwidth saturation caused by a broadcast intensive network card.

Power Considerations

You need to have consistent, reliable power to be able to run your computers. Power failures, power surges, and power sags can cause the computers to crash and can damage the electronics. There are different situations that affect the power supplied to your computer.

Power Supply

Be sure your computer has a high quality power supply that can simultaneously support all components attached to it. It is possible to overload a power supply by adding too many power consuming devices to a computer. It is also possible to overload a circuit by having too many computer components on it.

Power Outages

To protect against damage and loss of data from temporary power outages, consider the purchase of an uninterruptable power supply (UPS). Windows NT supports different kinds of UPSs and can send messages to users to save their data and to log off as soon as the UPS device signals an impending shutdown. For more information about the Windows NT UPS service, see the section titled "Avoiding Single Points of Failure," presented later in this chapter.

Power Surges

To prevent power surges that can destroy your data, obtain quality power surge surpressors.

What Components in the Network Might Fail

If users cannot connect to your computers running Windows NT Server, you do not have a fault-tolerant configuration. You need to consider what can fail in the connections between your computers as well as the individual computers themselves.

Network Cabling

If your company is growing, the connections between your computers could become saturated with network traffic. You should evaluate network traffic regularly to determine if you will need to upgrade with more equipment. You can also use newer technologies like FDDI, CDDI, ATM, Fast Ethernet 100 Base T, and the like.

Intermediary Devices

Devices that connect different segments of your network, such as routers, bridges, hubs, and switches, can also be bottlenecks and points of failure. You should have UPS protection for these devices.

For each of these devices, find out whether you can get the vendor support you need. What standards are supported by each of the devices, and does the vendor have a migration path for new standards? You should also find out if there are frequent software changes.

External Network Connections

If you lease an X.25, ISDN, or T1 line to connect to another building, branch, or subsidiary of your company, verify that your line vendor has recovery procedures in place that can guarantee minimum down times for the line.

Electric Wiring

Be sure the wiring in your building is capable of supplying your company with enough power as the demands in electricity increase. This is especially important if the building is older or if there are other companies in the building that are putting more demands on the supply of electricity.

What Else Might Fail

Climate Control

If the weather at the location of your company requires heating or cooling within the building to keep your computers and network devices within required operating temperatures, consider making the climate control system fault tolerant as well.

Software Failures

Does your software vendor provide the support you need in case of software failure? Does your company have a technical support group to assist users when there are software problems?

How Likely is a Failure

The meantime between failures (MTBF) information supplied by some manufacturers of equipment such as hard disks is unlikely to provide useful information without extensive analysis and modeling according to the variables that exist in your company's usage pattern. You can use the MTBF as a relative measure of reliability.

More useful is records of past failures and their causes, because you can use this information to help you in your planning. You can categorize failures by their type, such as:

  • Hardware failure of a server, client, or network component.
  • Software failure of the operating system on the server or client, or an applications failure.
  • Administrative error or oversight.
  • User error.
  • Deliberate damage, such as sabotage or viruses.

These are some questions to ask about failures:

  • Have you taken any actions to reduce the likelihood of each failure occurring in your business?
  • What was done or could be done to fix the problem?
  • How long would it or did it take?
  • What would it or did it cost?
  • What changes have you made that might result in more or fewer failures?
    • Number of servers.
    • Number of clients.
    • Number of users.
    • Number of administrators.
    • Number of intermediary devices.
    • Number of external connections.
    • Physical size of LAN(s) or WAN.

Fewer computers can be easier to manage than many computers. However, the relative downtime impact is higher when you have more users connected to a smaller number of servers.

Importance of Training and Technical Support

Having trained personnel can reduce the likelihood of failures and reduce their severity. However, you need to determine if the cost of the training will be worth the expected benefit.

There are several ways you can train your personnel and provide them with technical support:

  • Use self-study courses.
  • Subscribe to TechNet.
  • Use the Internet to access Microsoft and vendor information.
  • Take vendor-approved or third-party courses.
  • Have personnel become certified in the use, administration, and troubleshooting of system hardware and software.
  • Have a technical library available for personnel.
  • Install computers to be used specifically for training and testing.
  • Develop your own training courses.

You can also contract to Microsoft, your hardware vendors, and third-party consultants for support.

See the Windows NT Server Start Here book for a description of Microsoft's AnswerPoint Information Services. Microsoft's support offerings range from no-cost and low-cost online information services (available 24 hours a day, 7 days a week) to annual support plans.

Importance of Testing

Testing is an important component of your contingency planning. You can use testing to try to predict failure situations and to practice recovery procedures. Be sure to do stress testing and test all functionality.

The following list identifies some of the failures that you should test:

  • Individual computer components such as hard disks and controllers, processors, and RAM.
  • External components such as routers, bridges, switches, cabling, and connectors.

These are some of the stress tests that you should set up:

  • Heavy network loads.
  • Heavy disk I/O to the same disk.
  • Heavy use of file, print, and applications servers.
  • Large number of simultaneous logons.


Avoiding Single Points of Failure

Minimize the number of components whose failure will result in the failure of the computer. The "Contingency Planning" section, presented earlier in this chapter, discusses components and reducing the likelihood of failure.

Computers running Windows NT Server have fault-tolerance features built-in to the operating system. Fault tolerance is the ability of a system to continue functioning when a component on the computer fails. Normally, the expression fault tolerance is used to describe disk subsystems, but it can also apply to other parts of the system or the entire system. Fully fault-tolerant computers use redundant disk controllers and uninterruptable power supplies (UPS) as well as fault-tolerant disk subsystems.

Although the data are always available and current in a fault-tolerant disk configuration, you still need to make backups to protect the information on your disk subsystem from:

  • User errors.
  • Sabotage.
  • Software malfunctions.
  • Catastrophic disasters such as fire, earthquakes, tornadoes, and floods.

Disk fault tolerance is not an alternative to a backup strategy with offsite storage. For more information about disk fault tolerance, see "Planning a Fault-tolerant Disk Configuration," presented later in this chapter.

Consider having replacement disks and controllers available on site. For instance, SCSI controllers cost as little as a few hundred dollars, while the cost of 50 to 500 users who cannot work while waiting for a replacement could be many thousands of dollars.

Consider providing UPS protection for individual computers and the network itself, including hubs, bridges, and routers. Windows NT has UPS support on individual computers. These UPSs typically provide power for five to 20 minutes, long enough for Windows NT to do an orderly shutdown when power fails. If there is a history of frequent or prolonged power outages, you should investigate ways to provide power for your critical computers other than from your local power company. It is important to remember that individual UPS systems, even for every computer system on the network, will not necessarily prevent data loss or corruption due to power fluctuations. The network is itself an electrical system. Intermediary devices such as routers, bridges, and hubs, require the same UPS protection in order to prevent loss of network functionality.

There is more information about UPS in Chapter 7, "Protecting Data" in the Windows NT Server Concepts and Planning book, and in Chapter 5, "Preparing For and Performing Recovery," in this book.


Backup Strategy

Doing regular backups of data on servers and local hard disks prevents data loss and damage caused by disk failures, power outages, virus infection, and network problems. Backup operations based on careful planning and reliable equipment make file recovery easier and less time consuming.

Windows NT includes the backup program, Ntbackup.exe, that enables you to use a tape drive to back up and restore files on Windows NT file system (NTFS) or file allocation table (FAT) volumes. The Ntbackup program also simplifies archiving. You can easily save data for legal or historical purposes and remove older, unused files, knowing that you can recover them, if necessary.

Ntbackup can perform several different kinds of backups:

  • A normal backup, also called a full backup, copies all selected files and marks each as having been backed up. With normal backups, you can restore files quickly because files on the last tape are the most current.
  • A copy backup copies all selected files but does not mark each file as having been backed up. Copying is useful if you want to back up files between normal and incremental backups, because copying does not invalidate these other backup operations.
  • An incremental backup backs up only those files created or changed since the last normal or incremental backup. It marks files as having been backed up. If you use a combination of normal and incremental backups, restoring requires starting with your last normal backup and then working through all the incremental tapes.
  • A differential backup copies those files created or changed since the last normal (or incremental) backup. It does not mark files as having been backed up. If you are doing normal and differential backups, restoring requires only the last normal and last differential backup tape.
  • A daily backup copies all selected files that have been modified the day the daily backup is performed. The backed up files are not marked as having been backed up. (This can be useful if you want to take work home and need a quick way to select the files that you worked on that day.)

Chapter 6, "Backing Up and Restoring Network Files," in the Windows NT Server Concepts and Planning book, describes developing your backup plan and using Ntbackup.

When developing your backup plan:

  • Be sure to have spare hardware in case of a failure in your backup device.
  • Plan to test your backed up data regularly to verify that you can rely on your backup procedures and equipment.
  • Include stress testing of your backup hardware (tape drives, optical drives, and controllers) and software (backup program and device drivers).
  • Consider security regarding your backups. If you have implemented physical security to protect your computers, but unauthorized people can get access to your backup tapes, your data are not protected.

This section:

  • Provides an approach for backing up computers on a small LAN and discusses backing up very large servers and ones that must be available 24 hours a day.
  • Discusses the types of data that you should regularly back up.
  • Lists questions that you should consider when planning your backup procedures.

Backup Approaches

There are two extremes when it comes to backing up data on computers running Windows NT:

  • You have a small, simple network.
  • The computer that you want to back up needs to be available 24 hours a day, 7 days a week, or contains a large amount of data to back up.

This section discusses backup approaches for these two situations.

Small and Medium LANs

This section describes an approach for backing up computers running Windows NT Server and Windows NT Workstation on a small to medium LAN. There are no backup devices connected to computers running Windows NT Workstation. Therefore, data from those computers needs to be backed up on computers running Windows NT Server.

This network has the following characteristics:

  • 1 - 10 computers running Windows NT Server.
  • Total disk space 1 - 25 GB on each computer running Windows NT Server.
  • Typical daily data modifications in the range of 100-1000 MB.
  • Typically has scheduled downtime at night or on weekends.
  • There are a minimum of two backup devices on different computers running Windows NT Server. One should be on the primary domain controller (PDC). If you have backup domain controller (BDC), this computer should have the second backup device.
  • All computers running Windows NT Server are capable of hosting the backup devices.

These are suggested guidelines for backing up all of the computers that are running Windows NT, assuming that you are using Ntbackup or a similar program to back up your data to a cartridge tape:

  • If you are using tape drives that are SCSI controlled, insure that the drives will work in all of the computers. Are there spare SCSI IDs available on the chain?
  • Does each computer still function correctly after you install the tape drive?
  • Does Ntbackup work on each computer, and does a test restore work on each computer?
  • All backup devices should use the same media. Preferably, all backup devices are the same make and model.
  • Verify that the media works in all of the backup devices.
  • The backup device must be fast enough to complete a backup in the time allotted, which could be overnight, or a specified number of hours.
  • Perform a complete backup (called normal or full in NTBackup) on a regular basis, such as once a week.
  • Do an incremental backup of files on the days that you do not perform a full backup.
  • The backup media should be capable of writing a complete incremental backup on one cartridge. Preferably, a full backup fits on one cartridge.
  • Label all backup media with the date, the computer on which it was created, and the type of backup, such as full or incremental.
  • Rotate your backup media. Some suggestions are described in Chapter 6, "Backing Up and Restoring Network Files," in the Windows NT Server Concepts and Planning book.
  • Secure the backup media in a fireproof safe large enough for a full rotation's worth of cartridges.
  • Split nightly backups on all computers running Windows NT Server among the backup devices for load balancing and reliability.
  • Back up the Registry on your PDC and BDC every night.
  • Back up critical data located on computers running Windows NT Workstation every night. Users should copy important files from the client computers to an area on the computer(s) that do the backup.
Considerations for 24 Hour Operations or Very Large Backups

If the data set being backed up is very large, such as a SQL database or a number of large graphics files, it is difficult to back up the data within a reasonable amount of time, given the limitations of existing tape hardware. If Windows NT has locked the file for backup, and it is still locked when the clients start trying to access the file the next morning, the procedure described in the preceding section will not work. If the time available for backups is very small because the files are needed 24 hours a day, you will need a different approach than the one previously described.

You could configure the disks that require daily backup separately from the Windows NT Server system disks by using Redundant Array of Inexpensive Disks (RAID) arrays. For your critical computers, you could implement a software mirror of two separate hardware-controlled RAID arrays. With this configuration, if either a disk or an entire array fails, operations can continue. If a component such as a network interface card, video device, IDE adapter, or power supply fails, it can be easily replaced. If the computer running Windows NT Server itself fails, you should have a spare computer with Windows NT Server already installed to which you can move the data disks.

Note

RAID arrays provide disk fault-tolerance completely within hardware that you purchase from a vendor. In RAID arrays, the controller interface handles the creation and regeneration of redundant information that is automatically used if there is a failure in one of the disks in the array. See "Planning a Fault-Tolerant Disk Configuration," presented later in this chapter, for more information about RAID arrays.

One approach to backing up data on a critical computer running Windows NT Server involves logically removing the computer from the network by:

  • Disconnecting all users.
  • Pausing the Server service by using the Services option on Control Panel.
  • Ensuring that all files are closed, so that they can be accessed by the backup procedure.

The following methods are variations on this approach. The first two methods can be used to back up the data once you have removed the computer from the network. In these methods, we call the computer that contains the data to be backed up DATA. The computer that actually does the backup is called TARGET. The third method allows users to continue to access the data on DATA while it is being backed up.

Backup Method 1

Copy the data from DATA to TARGET. When the data are on NTFS volumes, you can use the Scopy program to copy the permissions as well as the data. If you don't need permissions, you can use the Xcopy program to just copy the data. To copy database files, use functions in the database application. If you expect the network to be busy when you will be doing the copy, it is best to dedicate a computer-to-computer link. Once the data are on TARGET, you can bring DATA online and back up the files from TARGET. Copying the data to TARGET minimizes the amount of time that DATA is not available to users.

Note

The Scopy program (on the Windows NT Server Resource Kit CD) does not support copying only the files that have been modified. The Xcopy program (on the Windows NT Server product CD) does support copying only modified files, but does not copy the file permissions. You need to decide whether Scopy or Xcopy works best for your situation, or whether you need to use a different program to copy the files.

Ideally, you should do a complete file comparison between the data on DATA and TARGET to verify the transferred data. However, comparing the data will take about twice as long as it takes to copy the data. Typical Ethernet or Token Ring transfer speeds are 1 MB per second, if the network is not busy. Use this transfer rate and the total amount of data to transfer to determine the expected transfer time. If you do not have enough time, you will need to use a faster network connection, or a different backup method.

Backup Method 2

Copy the data that you want to back up to another disk or disks on DATA. This process is usually faster than copying to another computer over the network because it occurs within the same computer. You can now bring DATA online. The copy of the data can then be backed up by using a backup device connected to DATA. If you do not want run the backup program on DATA, you can transfer the copy of the data to TARGET, from which you do the backup.

You need to decide whether to do the backup on DATA or TARGET. This decision depends on factors such as:

  • Availability of a computer to use as TARGET.
  • Your overall backup strategy, which might specify that all backups be performed on a few central computers.
  • Whether the processing overhead of doing the backup on DATA is more than the cost and processing overhead associated with transferring the files over the network to TARGET.
  • How long you expect the backup to take.
Backup Method 3

There are also third-party utilities that mirror the data onto another computer running Windows NT Server across the network while the files are still being used on DATA. This approach is best when you absolutely cannot take a chance of losing data because a disk or RAID array fails. While there might be some down-time associated with moving data from the mirror computer to the DATA computer after a failure on DATA is fixed, this approach is preferable to losing all data created or changed since the last backup of any kind. Again, performance is better if a network link is dedicated to this task. The other advantage of this approach is that the files being backed up are still available, and there is no downtime required to make copies.

What Data to Back Up

There are different kinds of data that you should back up. This section describes the types of data and why you should back them up.

Registry

The Registry is the most critical set of files on the computer as far as day-to-day operations are concerned. As a user, you would know fairly quickly if a system file is missing or corrupt — the computer would crash or fail to execute the command. The Registry is different. The computer might start, but then hang at the logon screen because all the security settings are missing or some required service did not started. On a computer running Windows NT Server, you need to have a current backup of the Registry. Otherwise, you have to rebuild information about all your users, groups and permissions, and you can never be certain that it is just the way it was before. There are several methods that you can use to back up all or part of the Registry, which are described in Chapter 5, "Preparing for and Performing Recovery." You should develop backup procedures specifically for the Registry to make sure people know who should be doing the backup.

Logon Scripts

Logon scripts are files that can be assigned to user accounts. Each time a user logs on, the assigned logon script is run. You can use logon scripts to configure user working environments by creating network connections and starting applications. Logon scripts are useful when you want to affect the user work environment without managing all aspects of it. A logon script runs automatically whenever a user logs on to a computer running either Windows NT Server or Windows NT Workstation. A logon script is always downloaded from the computer running Windows NT Server that validates a user's logon request.

For users with accounts on Windows NT Server domains that have one or more BDCs, any one of the domain controllers can authorize a user's logon attempt. To ensure that logon scripts always work for users, you should be sure that logon scripts for all user accounts in a domain exist on every PDC and BDC in the domain.

The best way to ensure that logon scripts are always available and consistent is to use the Replicator service. In replication, actual copies of the files are sent across the network to other computers. In the case of logon scripts, you would decide which domain controller should be the sending computer. The receiving computers would be all of the other domain controllers.

You can also replicate information other than Logon scripts, but replication should only be used for critical information that must be available, even if the computer running Windows NT Server it is normally on is unavailable. Replicating files unnecessarily can put a large load on the network and slow it considerably.

Note

You should use replication for such critical data as the DHCP and WINS databases. For more information, see Chapter 7, "Using Microsoft DHCP Servers," and Chapter 8, "Managing Microsoft WINS Servers," in the Windows NT Server Networking Guide.

See Chapter 3, "Managing User Work Environments," in the Windows NT Server Concepts and Planning book, for more information about logon scripts.

Application Programs

Application programs, such as Microsoft Word for Windows, are typically what network users are involved with on a daily basis. You can always reinstall the executable files themselves from the original distribution media, but the down time and lost productivity make this approach less than ideal. Additionally, you might have customized the application programs to suit the needs of your organization. The difficulty of reproducing those settings can be greater than reloading the programs themselves. Fortunately, since the files rarely change, backing up the files are part of your backup procedure insures that the latest version is quickly available, and it does not use a lot of offline storage space. For example, using Ntbackup with the Incremental option insures that any changes made are easily recoverable. Or, you could do a complete backup of the volumes that contain your application programs when you make changes.

User Data

The greatest amount of change on any server is in the users' folders. Users constantly add, modify, or delete files from the computer. You should do daily backups of changes to users' folders.

Some of your users will keep most of the files that they want backed up on file servers. Other users will do most of their work on their own workstation and want that data backed up. Your backup procedures need to cover both situations.

Questions to Consider in Developing Backup Procedures

The critical nature of backups requires complete verification of the entire backup and restore process. Because backup programs vary in their specifics and procedures, this section identifies some of the questions that you should ask, and answer, concerning the process.

Who

These are questions to consider when you are deciding who should be doing certain tasks:

  • Who determines what files and computers will be backed up, and how will the policy be published?
  • Who is responsible for doing the backup? Is this responsibility formally part of their job description?
  • To whom is the success or failure of the backup reported?
  • If the designated backup operator(s) are unavailable, who is the alternate?
  • How are users notified if the backup fails?
  • If the backup takes place unattended, but in a location that has off-shift personnel, are they trained to monitor the backup?
  • Should they intervene in case of failure?
  • Who do they notify of a problem?
  • What is the process they should follow?
  • Do they have some way to contact the responsible individual(s)?
  • Are these individuals required to be available by telephone or wear pagers?
  • If trained personnel are to monitor the backup, how are they scheduled for the next day?
  • Is there coverage for their other duties if there are problems with doing the backup, or they need to do a lengthy restore?
  • During vacations, sickness, or other absences, who will do the backup?
  • If a backup fails because of a hardware problem, who is the contact point with the vendor or manufacturer?
  • If the backup fails because of software problems, who do you contact?
When

You also need to consider when and how often the backups should take place:

  • If you want to back up as many files as possible, the backup will probably occur after-hours. Will this be true only for full backups or all backups?
  • How often do you do full backups and incremental backups?
  • At what time should the backup occur, immediately after hours or before business hours early the next day?
  • If the backup fails because of hardware problems, is there standby hardware, or can a loaner be obtained from the vendor?
  • Will the vendor guarantee availability of a loaner?
  • How long will it take to replace the failed hardware?
  • Is the vendor's technical support available at all times?
  • Is software technical support available at all times?
  • Do you have a configuration book that contains information about the computers running Windows NT Server that any technical support person might need?
  • If not, how long will it take to create this information when you have a problem?
  • What are the policies of the hardware or software vendor concerning fixes and how long they might take?
  • How long will it take to retrieve the backups or copies from a local or remote storage area?
  • Can the remote copies be obtained at any time or only during business hours?
  • How long will it take to do a full restore if the computer totally fails?
Where

Where you do the backups and where you store the backup media are also important questions:

  • Is the backup taking place in a secure area?
  • If so, how is it monitored?
  • Where are the backup tapes stored?
  • Is the storage location secure?
  • Is it fireproof, waterproof, and otherwise protected from disasters?
  • Are the tapes that are stored on site accessible at all times to the people who might need them?
  • Are there copies, and where are they stored?
  • Is the offsite location secure?
  • Is it fireproof, waterproof, and otherwise protected from disasters?
  • Is it bonded?
  • Will the backup be done to a local tape drive, remotely over the LAN, or remotely over the WAN?
  • How is the connection verified before the backup begins?
  • How are computers equipped for power outages if operators are not present and backups are taking place?
What

You need to decide what to back up:

  • What is the backup plan?
  • Are all modified files to be backed up, or will there be a policy regarding specific users, groups, departments, divisions, or company-critical files?
  • Will there be disks or volumes on the computer running Windows NT Server that are not backed up?
  • Will users be responsible for backup of their individual client systems?
  • Will there be a chargeback system for the amount of storage used?
How

You also need to determine how you will do the backups and how to determine if backups work correctly:

  • How is the backup process certified?
  • Has every option that you expect to use been tested?
  • Do the scripts work?
  • Do the logs get created and are they correct?
  • If the path is long, the filename odd, the file size very large, or the number of files is large, does the backup still work? Can you restore files that have these chacteristics?
  • How is the backup started: from the command line, an icon, or by batch?
  • Do these methods all work the same?
  • If you schedule your backups, do they occur as scheduled?
  • Is the tape actually verifying the data?
  • Does a test restore work?
  • Does the system have to be in a certain condition before the backup starts?
  • What is the typical or expected state of the system before, during, and after the backup?
  • What is the actual condition?
  • Are there any unforeseen behaviors?
  • When you make changes to the operating system (such as installing a service pack), or the backup program, do you recertify the backup/restore process?
  • If you make hardware changes on the computer, such as installing a new controller or tape drive, or changing the BIOS on the motherboard, do you recertify the backup/restore process?
  • How do you certify that you can use your old tapes when you have changed hardware of software involved in the backup?


Storing Data

Some kinds of information should be stored near your computers to be readily available. Some data should be stored off site to be available in the event of a disaster, or for long-term storage. This section discusses both onsite and offsite storage. It assumes that you are using Ntbackup or a similar program to back up your data to a cartridge tape.

Onsite Storage

Some data need to be stored on site and readily available in the event of a failure:

  • Daily backups, whether full or incremental. The tapes should always be stored in a fireproof safe or storage cabinet to provide a minimum level of security. Secure storage protects against natural disaster, and theft and sabotage of critical data.
  • Copies of the media that you used to install the operating system and application programs should also be stored in a secure storage cabinet. With more software being shipped on CD-ROM, it is not easy to just make a copy like you do with floppy disks. If more than one copy of the program is purchased, an extra copy can be stored off site. If only one copy is available, then it should be backed up to an individual tape, and labeled as a backup of the application. If you need to reinstall the software, you can restore from tape onto a computer running Windows NT Server. You can then run the application program setup over the network. (The software then needs to be deleted from the server.)

Offsite Storage

The most important data should always be stored off site. There are many companies that specialize in secure data storage. These companies lease space in underground vaults that remain impervious to just about everything. Smaller companies may find the cost and logistics of this degree of protection to be too great. Alternative solutions can be as simple a safe deposit box at a local bank or a fireproof safe at home or another location.

You should store the following types of information off site:

  • A full backup of the entire system should be done on a weekly basis and be stored off site.
  • The original of all installed programs should be stored off site. Copies should be kept on site.
  • Anything that an insurance company is going to need to facilitate a claim should be stored off site, such as copies of purchase orders or receipts for computer hardware and software. See your business insurance agent for the specific information they will need.
  • A copy of any information required to get network hardware reinstalled or reconfigured. This information is usually very hardware specific. Check with your phone company or other supplier of data transmission lines for information that will help them get your service back online as quickly as possible.


Planning a Fault-Tolerant Disk Configuration

A technology called Redundant Array of Independent Disks (RAID) minimizes loss of data caused by problems with accessing data on a hard disk. RAID is a fault-tolerant disk configuration in which part of the physical storage capacity contains redundant information about data stored on the disks. The redundant information enables regeneration of the data if one of the disks or the access path to it fails, or a sector on the disk cannot be read.

Some vendors sell disk subsystems that implement RAID technology completely within the hardware. Some of these hardware implementations support hot swapping of disks, which enables you to replace a failed disk while the computer is still running Windows NT Server. RAID arrays are not described in this book.

In this chapter, and other chapters in the "Reliability and Recoverability" part of this book, the term RAID array refers to a fault-tolerant disk subsystem where all of the fault tolerance is implemented in the hardware. For information about RAID arrays that are compatible with Windows NT, see the Windows NT Hardware Compatibility List (HCL). Chapter 8, "General Troubleshooting," contains more information about the Windows NT HCL.

Windows NT Server provides software support for two fault-tolerant disk configurations: mirror sets and stripe sets with parity. You use Disk Administrator to configure mirror sets and stripe sets with parity, and to reconstruct the volume when there has been a failure.

Windows NT Server and Windows NT Workstation have software support for stripe sets, which you configure by using Disk Administrator. Although stripe sets are not fault-tolerant, they are described in this section because:

  • Stripe sets are the basis for stripe sets with parity.
  • Stripe sets improve I/O performance.
  • Windows NT Workstation and Windows NT Server need the same kind of information, both on disk and in the Registry, to identify and access stripe sets, mirror sets, and stripe sets with parity.

All RAID disk configurations:

  • Regenerate data to satisfy a read request when a disk or a path to a disk has failed. Regeneration involves reading data from other disks in the volume. The regeneration occurs automatically.
  • Reconstruct the missing data onto the new disk when you have replaced the failed disk (or the path to it). When you have implemented a fault-tolerant volume by using Disk Administrator, you also have to use Disk Administrator to begin the reconstruction of the data. If you are using a RAID array, see the vendor's documentation for information about reconstructing data.

For complete information about RAID, RAID terminology, and disk arrays, see The RAIDbook, A Source Book for Disk Array Technology. The RAID Advisory Board in St. Peter, MN, publishes this book. The June 1995 edition is the basis for RAID information in this chapter.

Chapter 7, "Protecting Data," in Windows NT Server Concepts and Planning, contains more information about using stripe sets, mirror sets, and stripe sets with parity on Windows NT Server.

Chapter 5, "Preparing for and Performing Recovery," in this book, describes configuring, and recovering from failures of, mirror sets and stripe sets with parity.


Stripe Set

Stripe sets are composed of strips of equal size on each disk in the volume. You create a stripe set from equal sized, unallocated areas on two to 32 physical disks. For Windows NT Workstation and Windows NT Server, the size of the strips is 64K.

Conceptually, a stripe set is similar to a table in a document, where a disk is a column and a strip is one of the entries in the table. A stripe is all of the entries in one row. The next table shows how a stripe set is similar to a table. It also shows the order in which data are written to a stripe set.

Table 4.1 Stripe set

 | Disk 1 | Disk 2 | Disk 3 | Disk 4
Stripe 1 | 1 | 2 | 3 | 4
Stripe 2 | 5 | 6 | 7 | 8
Stripe 3 | 9 | 10 | 11 | 12
Stripe 4 | 13 | 14 | 15 | 16
Stripe 5 | 17 | 18 | 19 | 20

The next figure shows a stripe set using four disks. A strip is one of the blocks on one of the disks. Like the preceding table, stripe 1 consists of the four strips that are the first block on each of the four disks. Stripe 5 is made up of the strips that are the last block on each disk.

Figure 4.1. Stripe set

When you write data to a stripe set, the data are written across the strips in the volume. Thus, using the Table 4.1 and Figure 4.1 as the example, if you wrote a file that was 325K long, it would occupy the following areas:

  • 64K on strip 1 of disk 1.
  • 64K on strip 1 of disk 2.
  • 64K on strip 1 of disk 3.
  • 64K on strip 1 of disk 4
  • 64K on strip 2 of disk 1.
  • 5K on strip 2 of disk 2.

The physical disks in a stripe set do not need to be identical, but there must be unpartitioned areas available on each disk that you want to include in the volume. You cannot add disks to a stripe set if you need to increase the size of the volume later, because Windows NT would have to move the data around on the stripe set. If you want to change the size of a stripe set, you have to:

  • Back up the data.
  • Delete the stripe set by using Disk Administrator.
  • Create a new stripe set, also by using Disk Administrator.
  • Restore the data to the new stripe set.

Stripe sets do not contain any redundant information. Therefore, the cost per MB for a stripe set is identical to that for the same amount of storage configured from a contiguous area on a single disk. Although the data are spread across multiple disks, there is no fault tolerance. When any disk fails, the whole stripe set fails, and no data can be recovered. The reliability for the stripe set is worse than the least reliable disk in the set.

You create and use a stripe set for performance reasons. Access to the data on a stripe set is usually faster than access to the same data would be on a single disk, because the I/O is spread across more than one disk. Therefore, Windows NT can be doing seeks on more than one disk at the same time, and can even have simultaneous reads or writes occurring.

A stripe set works well in the following environments:

  • When users need rapid read access to large databases or other data structures.
  • Storing program images, DLLs or run-time libraries for rapid loading. Operating systems that use memory mapped images, such as Windows NT, can benefit from using stripe sets.
  • Collecting data from external sources at very high transfer rates. This is especially useful when the collection is done asynchronously.
  • Multiple independent applications require access to data stored on the stripe set. When the operating system supports asynchronous multithreading, this insures disk reads and writes can be load balanced.

Stripe sets are not well suited for the following situations:

  • When programs make requests for small amounts of sequentially located data. It would probably be more efficient to use one volume on a single disk for this type of data, because other users' data requests would not be impacted as much. For example, if a program requests 8K at a time, it takes eight separate I/O requests to read or write all of the data in a 64K strip, which is not a very good use of this storage mechanism.
  • When programs make synchronous random requests for small amounts of data. This causes I/O bottlenecks because each request requires a separate seek operation. 16-bit single-threaded programs are very prone to this problem.


Mirror Set

A mirror set provides an identical twin for the selected partition. All data written to the mirror set are written to both partitions, which results in disk space utilization of only 50 percent.

Creating a mirror set is similar to making a copy of a document by using a copy machine. The original partition is like the original of the document, and the shadow partition is the copy. Unlike a copy machine, however, Windows NT continually updates both the original and shadow partitions when any changes are made to the mirror set.

Note

In this chapter and other chapters in the "Reliability and Recoverability" part of this book, the terms original disk and original partition refers to the original partition, and shadow disk and shadow partition refers to the disk or partition that contains the copy.

Figure 4.2 shows a mirror set. To a user, only one read or write occurs to satisfy a request for data. FtDisk, the Windows NT fault-tolerant disk driver, creates separate I/O requests for each of the disks.

Figure 4.2. Mirror set

If there is a read failure on one of the disks, FtDisk reads the data from the other disk in the mirror set. If there is a write failure on one of the disks in the mirror set, FtDisk uses the remaining disk for all accesses.

Because dual-write operations can degrade system performance, many mirror set implementations use duplexing, where each disk in the mirror set has its own disk controller.

Any primary partition can be mirrored, including the system and boot partitions. The disk that you select for the shadow partition does not need to be identical to the original disk in size, or number of tracks and cylinders. This means that you do not have to replace a failed disk with an identical model. The unpartitioned area that you select for the shadow partition cannot be smaller than the original partition. If the area that you select for shadow partition is larger than the original, the extra space on the shadow disk can be configured as another partition (if there are fewer than four partitions on the disk).

Note

If you configure your system partition as a mirror set, you should use identical disks for the mirror set, and use the same disk geometry. See Chapter 5, "Preparing for and Performing Recovery," for details about configuring mirror sets for these partitions.

When compared to stripe sets with parity (described later in this chapter), a mirror set implementation:

  • Has a lower entry cost (because it requires only two disks, whereas a stripe set with parity requires three or more disks).
  • Requires less system memory.
  • Provides the best overall performance.
  • Does not show performance degradation during a failure.
  • Has a higher cost-per-megabyte.

You can mirror the boot partition, which significantly reduces the amount of time needed to get your Windows NT Server back up if there is a problem with the hard disk containing your operating system.

Note

The term system partition refers to the disk partition containing hardware-specific files needed to start Windows NT (such as the x86-based files NTLDR and Boot.ini, or the RISC-based files Osloader.exe and Hal.dll). The boot partition contains the operating system files and support files. The boot partition and the system partition can be the same partition.

A mirror set works well for the following applications:

  • When extremely high data reliability is required. A duplexed mirror set has the best data reliability because the entire I/O subsystem is duplicated.
  • When the best possible performance is required. Performance is excellent for read-intensive applications, with only a slight penalty for disk writes.
  • When simplicity is important. Mirror sets are simple to understand and easy to set up.

You might not want to use a mirror set if cost is a critical factor. Mirror sets are the most expensive solution on a cost per unit of data storage basis.

Advantages to Using Mirror Sets

Disk read operations are more efficient than on a single partition. FtDisk, the fault tolerance disk driver, has the capacity to load balance read operations across the physical disks. With current SCSI technology, two disk read operations can be done simultaneously. In some cases, a disk read can be done in half the time it would take on a single partition.

Recovery from a disk failure is very rapid. Mirror sets offer the fastest data recovery, with the least impact on system performance, because the shadow partition contains all of the data. There is no data rebuilding needed to restore the system. When you configure your boot partition on a mirror set, you do not have to reinstall the Windows NT Server to be able to restart the computer.

It is not necessary to use identical physical disks or to have the same partitions on each disk, although you should use identical disks if you put your system partition on a mirror set. All FtDisk requires is sufficient unused space on the second disk to create the shadow partition.

You can mirror the system or the boot partition. You cannot use a stripe set with parity for either of these partitions.

Disadvantages of Mirror Sets

Disk write operations are less efficient. Because data must be written to both disks, there is a slight performance penalty. However, since disk writes are done asynchronously, the penalty is not 100 percent. In most situations, a user-mode application would not be affected by the extra disk update.

Mirror sets are the least efficient in terms of space utilization. Because the data are duplicated, the space requirements for a mirror set are higher than for a stripe set with parity.

When you create a mirror set for the system or boot partition, you should create and test a Windows NT startup floppy disk in order to be able restart the computer. In the case of RISC-based computers, you need to create an alternate boot selection to be able to use the Windows NT startup floppy disk. Otherwise, the time to restart the computer after a failure increases because you have to create the boot selection.

Creating a mirror set of a boot or system partition does not do a sector by sector duplication of the disk. FtDisk does not copy either the Master Boot Record on track 0 or the Partition Boot Sector, which is the first sector of the partition. Some systems might save information in other parts of track 0, and this will not be duplicated either. Data corruption in these areas can make it much more difficult to recover from a failure of your original disk. If both disks are affected, it can be extremely difficult or impossible to recover the data.

For information on recovering from the failure of a mirror set, see Chapter 5, "Preparing for and Performing Recovery."


Stripe Set With Parity

A stripe set with parity adds parity information to a stripe set configuration. A stripe set with parity dedicates the equivalent of one disk's space in the stripe set with parity for storing the parity strips, but distributes the parity strips across all the disks in the group. The data and parity information are arranged on the volume so that they are always on different disks.

Table 4.2 shows the order in which data are written to a stripe set with parity that consists of five stripes on five disks.

Table 4.2 Stripe set with parity

 | Disk 1 | Disk 2 | Disk 3 | Disk 4 | Disk 5
Stripe 1 | parity 1 | 1 | 2 | 3 | 4
Stripe 2 | 5 | parity 2 | 6 | 7 | 8
Stripe 3 | 9 | 10 | parity 3 | 11 | 12
Stripe 4 | 13 | 14 | 15 | parity 4 | 16
Stripe 5 | 17 | 18 | 19 | 20 | parity 5

In Figure 4.3, the first block on disk 1 is the parity strip for the four data strips in stripe 1. In stripe 2, the parity strip is on disk 2, and so on. Figure 4.3 is another representation of the information shown in Table 4.2.

Figure 4.3. Stripe set with parity

The parity strip is the exclusive OR (XOR) of all the data values for the data strips in the stripe. If no disks in the stripe set with parity have failed, the new parity for a write can be calculated without having to read the corresponding strips from the other data disks. Thus, only two disks are involved in a write operation: the target data disk and the disk that contains the parity strip. The next figure shows the steps that are involved in writing data to a stripe set with parity.

When implementing a stripe set with parity, there must be at least three disks and no more than 32 disks in the set. The physical disks do not need to be identical. However, there must be equal size blocks of unpartitioned space available on each physical disk in the set. The disks can be on the same or different controllers. As with stripe sets, you cannot add disks to a stripe set with parity if you need to increase the size of the volume later.

If one of the disks in a stripe set with parity fails, none of the data are lost. When a read operation requires data from the failed disk, the system reads all of the remaining good data strips in the stripe and the parity strip. Each data strip is subtracted (with XOR) from the parity strip; the order isn't important. The result is the missing data strip.

When the system needs to write a data strip to a disk that has failed, it reads the other data strips and the parity strip and backs them out of the parity strip, leaving the missing data strip. The modifications needed to the parity strip can now be calculated and made. Because the data strip is bad, it is not written; only the parity strip is written.

There is no effect on a read operation when the disk that failed contains a parity strip. (The parity strip isn't needed for a read, unless there is a failure in a data strip.) When the failed disk contains a parity strip, the system does not compute or write the parity strip when there is a change in a data strip.

A stripe set with parity works well in the following situations

  • In large databases where reads occur much more often than writes. Performance degrades as the percentage of write operations increases. Database applications that do random reads work well with the built-in load balancing of a stripe set with parity.
  • Where a high degree of fault tolerance is required without the expense of a mirror set. A stripe set with parity is several times more efficient with storage than a mirror set when larger numbers of disks are used. The space required for storing the parity information is equivalent to 1/Number of disks, so a 10 disk array uses 1/10 of its capacity for parity information.

A stripe set with parity is not well suited for:

  • Applications that require high-speed data collection from a process. This type of application requires continuous high-speed disk writes, which do not work well with the asymmetrical I/O balance inherent in stripes set with parity and the extra I/Os required to write the parity strip.
  • Database applications in which records are continually updated. Financial applications where balances are frequently updated are a typical example.
  • Applications that require large sequential data transfers. These types of data transfer can prevent effective I/O load balancing.

Advantages of Stripe Sets With Parity

Disk read operations can occur simultaneously. All disks in the array can be in use at the same time.

Cost is lower than for a mirror set. The utilization increases as the number of disks in the array increases.

Disadvantages of Stripe Sets With Parity

Neither the system partition or boot partition can be on a stripe set with parity.

Write operations are substantially slower than for a single disk because the software has to read the old data strip, the old parity strip, and compute the new parity strip before writing it.

If a disk that is part of a stripe set with parity fails, read operations for data strips on that disk are substantially slower than for a single disk. The software has to read all of the other disks in the set to calculate the data.

A stripe set with parity requires more system memory than a mirror set.

Note

The minimum RAM on a RISC-based computer is 16 MB. On an x86-based computer, 12 MB suffices, but 16 MB is recommended. You might want to add memory when you configure disks as stripe set with parity.


Fault-tolerant Hardware Versus Software

On heavily-loaded computers running Windows NT Server, there might be advantages to using a hardware solution for mirror sets or stripes set with parity. Or you might want to select a different type of RAID array. There are many factors involved, which depend on the specific site, hardware being used, and the load on the computer running Windows NT Server.

Here are some points to consider when deciding whether to implement fault tolerance in hardware or software.

  • Fault-tolerant software is available only on Windows NT Server.
  • Hardware fault tolerance is faster.
  • Software fault tolerance is less expensive.
  • A hardware fault tolerance solution might lock you into a single vendor.
  • In a hardware fault tolerance implementation, some vendors support hot-swappable disks when there is a disk failure.

Regardless of whether you implement fault tolerance by using hardware or software, implementing fault tolerance does not reduce the need for backups.


Guidelines for Configuring Your Mass Storage

There is no optimal mass storage configuration for your Windows NT computer. The tradeoffs involved in deciding your configuration depend upon such variables as cost, performance, and how much time you can afford to take to completely rebuild a disk. This section discusses why you might want to use mirror sets, stripe sets with parity, or a combination of the two fault-tolerant software techniques on your Windows NT Server.

In general, you only need to use fault-tolerant configurations for information that you must have readily available in case of hardware failure or unrecoverable disk errors. You do not need to have your page file on a fault-tolerant volume, and you definitely should not have the page file on a stripe set with parity because of potential performance impacts.

Note

If you configure your computer running Windows NT Server to write a memory dump file each time it generates a Kernel STOP error, your page file must be located on the boot partition. If you configure your computer this way, and create a mirror set of your boot partition, the page file will be mirrored.

You might not need to configure application programs on a fault-tolerant volume. If you are considering having application programs and other common files on more than one computer running Windows NT Server, you can use replication to keep them all consistent and to provide the redundancy. If you have applications on a single computer running Windows NT Server, you only need to configure them on a fault-tolerant volume if you cannot tolerate them being unavailable for the amount of time it takes you to restore them from a backup. Be sure to back up the application program volume any time you install a new application or change default settings for an application.

You can put the application programs on a stripe set to get the fastest I/O performance for reading data.

If space is a consideration, you can format your application program volume with the NTFS file system (or convert a FAT volume to an NTFS volume), and use NTFS compression for folders and files on the volume. See Chapter 18, "Choosing a File System," in the Windows NT Workstation Resource Guide for details about NTFS compression.


Guidelines for Using Mirror Sets and Stripe Sets with Parity

There are software and hardware constraints to consider, as well as the cost and reliability of the system. Each potential vendor should have design guidelines for their system, whether you are looking for a RAID array or want to use the fault-tolerant features in Windows NT Server.

There are configurations and situations in which fault tolerance might not work as you would expect. The first thing you should check is whether all of the disk hardware is on the Windows NT Hardware Compatibility List (HCL). If any equipment is not included on the HCL, it might not work well. Chapter 8, "General Troubleshooting," contains more information about the HCL.

If you can, use identical disks. Although this is not a requirement, there are several advantages in using identical hardware for fault-tolerant configurations:

  • The performance of the disks is the same. Faster disks do not have to wait for slower disks.
  • If you want to configure the entire disk for a mirror set or stripe set with parity, the capacity is the same.
  • There are fewer potential problems with configuration and compatibility.

Have a backup disk available and ready for use. When purchasing the disks, it is a good idea to purchase an extra disk for use as a backup. An identical disk guarantees that in the event of a hardware failure, the backup disk is compatible, and will not degrade the system performance. All you need to do is install the new disk. (For SCSI disks, you have to configure the SCSI ID.)

Have a backup controller available, or configure your disks with duplexed controllers. The system can continue operating when a disk fails, but not when a controller fails. While there is no way to avoid system downtime when a controller fails, downtime can be minimized by having a pre-configured controller available. If the replacement controller is not the same as the original, you have to install a new driver, and your configuration becomes more complex.

Note

If you have configured your system partition on a mirror set, you should have the same make and model of controller for your backup, and be sure to use the same translation for both the original and shadow partition.

Configuring Mirror Sets

To a large extent, how your configure your mirror sets depend on the number of disks and controllers that you want to have on the computer running Windows NT Server. Having your boot partition on a disk (and controller) that does not contain data sets gives better performance. There are also other cost considerations that are related to overall reliability, such as your UPS strategy.

The decision to mirror the system or boot partition depends on how fast you want to be able to get your computer back up following a failure to the disk that contains these files. To some extent, it depends on whether you are using a x86-based computer or a RISC-based computer — x86-based computers experience most of the problems with sectors corrupted by viruses. These problems mean that you cannot start your computer from disk, although you can usually start it by using the Windows NT startup floppy disk. See Chapter 5, "Preparing for and Performing Recovery," for information about the Windows NT startup floppy disk.

When you use a mirror set for your system or boot partitions, these are some configurations that might cause problems:

  • Multichannel controllers do not always work for duplexing. It might not be possible to start from the second channel of a dual-channel controller by using the Windows NT startup floppy disk, which means you cannot restart your computer at all. In this situation, you would have to use the hardware configuration program to change the boot channel, or physically move the disks to the other channel.
  • Be sure to use the same disk translation for the disks in a mirror set of the system partition, and to format both disks using the same controller. Chapter 5, "Preparing for and Performing Recovery," contains more information about avoiding problems with incompatible geometry.

Configuring Stripe Sets With Parity

For a stripe set with parity, you should buy disks on the basis of cost per megabyte and performance. Since the space used for storing parity information is 1/n, storage efficiency increase with a larger number of disks. If you use high performance SCSI controllers, an array of six 2 GB disks provides more efficient storage than four 3 GB disks. If you have to replace a disk, you can rebuild a smaller disk faster, so the system returns to maximum performance is less time.

Keep the stripe set with parity on a different controller and disk than your system and boot partition. Using separate controllers improves performance, and can make it faster and easier to recover from a hardware failure. Remember that you cannot configure your system partition or your boot partition on a stripe set with parity.

If the computer itself or the disk containing the boot partition fails (and the boot partition is not mirrored), it might be faster to move the stripe set with parity to a different computer. Chapter 7, "Disk, File System, and Backup Utilities" contains information about moving disks in the section "Using FT Edit to Update the Registry."


Sample Configuration With Mirror Set and Stripe Set With Parity

If you want most of your data to be on fault-tolerant volumes, you might still want to use a small, non-fault-tolerant disk in your configuration. This disk could contain the system and boot partitions, and the page file. Ideally, the page file can be on its own partition to keep it from becoming fragmented. You should also have enough space on this disk for a temporary file large enough to use to install a service pack.

If you have configured your computer to write a memory dump when a Kernel STOP error occurs, Windows NT creates a page file the size of the RAM in your computer plus 1 MB. This page file must be on the boot partition. Therefore, you need to allow for a file this size if you are configured for memory dumps.

You can also create a mirror set of this small disk. You do not need to include your page file in the mirror set. You could have a separate partition for the page file on each of the disks in the mirror set. However, if you create a mirror set of your boot partition, and have configured the computer to write a memory dump file, there will be a page file on each partition in the mirror set. For more information about page files and memory dumps, see Windows NT Help.

Note

Small in this case must be large enough for the system partition (5-10 MB), the boot partition (150-175 MB), the page file (RAM size + 1 MB), and room for a temporary folder (10-15 MB). This small disk should be no smaller than 250 MB, and 300 MB is a better size.

You should not mix the boot partition, stripe sets, stripe sets with parity, and mirror sets on the same physical disks. Doing so can create problems when a disk failure occurs. For example, you could configure a system with three large physical disks, as follows:

  • The first disk has the system partition and boot partition using half the disk. A stripe set with parity occupies the remaining space on the disk.
  • Half of disks two and three contain the other partitions of the stripe set with parity.

If the disk with the system and boot partitions fails, the operating system cannot be started. The Registry, with the information about the stripe set with parity, cannot be accessed. You have to install a replacement disk, install Windows NT Server, and restore the Registry. Expect to take at least one hour before you can restart the computer.

A better solution would be to use five smaller disks, as follows:

  • Configure the first two disks as a mirror set containing the system and boot partitions. Be sure the page file is on the mirror set and not the stripe set with parity.
  • Create a stripe set with parity on the other three disks.

If the original disk of the mirror sets fails, you can restart the system from the shadow disk. Downtime should be less than five minutes. Chapter 5, "Preparing for and Performing Recovery," describes what you need to do to restart from the shadow disk.


Chapter 5 - Preparing for and Performing Recovery

This chapter describes what you can do to:

  • Reduce the possibility of problems.
  • Recover from problems when they occur.

There is no way to make a computer running Windows NT failure proof. You can only make the computer more failure resistant. A memory module, cabling, or controller failure can corrupt data on any disk. In this event, the only option is to restore from a tape or a backup server that contains a copy of the data.

These are some things that you can do to make it easier to recover from problems:

  • Develop plans and procedures for recovering from failures before you have one.
  • Create and test floppy disks that enable you to restart the computer when you are having trouble starting from the system partition.
  • Maintain software configuration information for your computers running Windows NT. At a minimum, keep track of the version of the operating system installed on each computer, including service packs and hotfixes.
  • Record the hardware configuration of each computer running Windows NT, especially the disk configurations.

The topics covered in this chapter are:

  • Maintaining configuration and other forms of information.
  • Understanding ARC pathnames.
  • Creating floppy disks to use to start the computer.
  • Training and testing.
  • Restoring disk information.
  • Configuring and using mirror sets and stripe sets with parity.
  • Using an uninterruptable power supply.

This chapter also describes using utilities on the Windows NT Server Resource Kit CD and the Windows NT Server CD to back up and restore critical data. Planning what utilities to use is as important as knowing how to use them. There is more information about these utilities in Chapter 7, "Disk, File System, and Backup Utilities."

Chapter 4, "Planning a Reliable Configuration," discusses planning what to do before failures occur, such as:

  • Deciding what hardware and software to procure.
  • Developing your plan for doing backups.
  • Developing training plans, disaster plans, and contingency plans.

These are some points to consider:

  • Investigate the various utilities for doing a task, and decide which one(s) to use for which situations.
  • When you have decided which utilities you want to use, prepare your floppy disks.
  • Know how to use the utilities that you decide to use.
  • Practice recovering from the common problems described in this chapter and in Chapter 6, "Troubleshooting Startup and Disk Problems."


Maintaining Configuration and Essential System Information

Hardware failures, power failures, and human errors can corrupt information that your computer needs to start Windows NT.

Recovery is easier if:

  • You know the configuration of each computer and its history.
  • You back up critical system files every time you make certain changes to your Windows NT configuration.

On computers running Windows NT Server, you can purchase disk subsystems that maintain redundant information on the disks. The redundant information is either parity information, or a complete, separate copy of the data. Having redundant information makes the disk subsystems fault tolerant, meaning that you can continue to access the data when one disk in a fault-tolerant configuration fails. This fault-tolerant technology is called RAID, for Redundant Array of Inexpensive Disks. A disk subsystem that implements fault tolerance using RAID technology is also called a RAID array.

Windows NT Server implements two of the fault-tolerant configurations in software: mirror sets, and stripe sets with parity. For a description of mirror sets and stripe sets with parity, see Chapter 4, "Planning a Reliable Configuration."

For complete information about RAID, RAID terminology, and RAID arrays, see The RAIDbook, A Source Book for Disk Array Technology. The RAID Advisory Board in St. Peter, MN, publishes this book. The June 1995 edition is the basis for RAID information in this chapter. The RAIDbook, A Source Book for Disk Array Technology also contains information about parity.


Keeping a Log Book

You should have a log book for every computer, which contains information about the computer's configuration. Having current information makes it easier to rebuild your computer in the event of a serious system crash. This information also helps product support personnel to troubleshoot problems. The Registry contains information about your disk configuration in the subkeys HKEY_LOCAL_MACHINE\HARDWARE\DeviceMap\AtDisk and Scsi.

The type of information to keep includes:

  • Computer type, model number, and serial number.
  • Computer BIOS manufacturer and revision level (x86-based computers) or firmware revision level (RISC-based computers).
  • CMOS information for x86-based computers.
  • NVRAM information on RISC-based computers.
  • Hardware configuration information, including IRQs, DMA addresses, I/O ports, and similar information. If the computer has an EISA bus, the EISA configuration and its associated CFG files should be backed up.
  • SCSI controller model number, and the BIOS firmware revision level.
  • Jumper settings for all peripheral devices.
  • Complete map of the SCSI subsystem, including:
    • SCSI configuration information from the SCSI setup program.
    • Which devices are terminated and how they are terminated.
    • The SCSI ID and physical location on the chain of every SCSI device.
  • Which versions of Windows NT are installed, and the partitions on which they are installed.
  • Details of any device drivers or other system level software that did not come in the Windows NT retail package. This software would include such things as a Network File System (NFS) provider, network protocol, or network management software.
  • Troubleshooting history for any system failures or Kernel STOP errors (blue screens). This information should include:
    • The time and date the problem occurred.
    • Any error messages, or events posted to the event log.
    • Any troubleshooting done and the outcome.
  • Partition information, such as the size of the partitions and the file system used for each one. You can use the DiskMap program, described in Chapter 7, "Disk, File System, and Backup Utilities," to print a map of each of your disks by redirecting the output to a file or a printer.


Backing up the Registry

All of the Windows NT internal configuration information is stored in the Registry. It is critical to have up-to-date, reliable backups of this information. There are several ways to back up the all or part of the Registry, and you should have redundancy in this area.

If you have a backup device installed on your computer, you can include the Registry in normal backups. You have to specifically select this option in the Windows NT tape backup program Ntbackup.exe. Third-party Windows NT-compatible backup software might also require that you take specific action to back up the Registry. Be sure to test your Registry backup and restore procedures.

Note

Windows NT Backup can only back up the Registry on the local system. You cannot use Windows NT Backup to back up a computer's Registry over the network.

After any change in the configuration of the operating system, including adding new software, you should use the Repair Disk program, Rdisk.exe, to update files in the %systemroot%\Repair folder, and create a new Emergency Repair Disk. For information about using the Repair Disk program, see "Creating an Emergency Repair Disk," presented later in this chapter. It is a good idea to make a copy of the Emergency Repair Disk and store it in a separate location, perhaps off site.

You can use the Windows NT Registry Editor, Regedt32.exe, to save and restore Registry keys.

The Windows NT Server Resource Kit CD contains utilities that enable you to back up and restore all or part of the Registry. For information about the Registry Backup (Regback.exe) and Registry Restore (Regrest.exe) utilities, see Rktools.hlp.

Saving the SYSTEM Key

The HKEY_LOCAL_MACHINE\SYSTEM key contains configuration information that Windows NT uses during startup. Even though this key is copied to the Emergency Repair Disk when you use Repair Disk program, there are times that you might want to restore this key from another disk. For more information, see "Restoring the SYSTEM Key," presented later in this chapter.

You can save the SYSTEM key by using either Disk Administrator or the Windows NT Registry Editor (Regedt32.exe). The primary difference between these two methods is that the Disk Administrator always saves the key to a floppy disk, whereas you can specify any disk by using the Registry Editor.

Note

The %systemroot%\System32\Config\System file is usually larger than the SYSTEM key saved by using Disk Administrator or Registry Editor. The smaller size results because the two programs compact the file before copying it to eliminate internal fragmentation and holes.

To use Disk Administrator to save the SYSTEM key

1. On the Partition menu, click Configuration.

2. On the Configuration menu, click Save. A message is displayed describing what will be saved and where you should save it.

3. Insert any floppy disk with enough unused space to hold the configuration information (about 512K). Using the Windows NT startup floppy disk is highly recommended.

4. Click OK to write the data to the floppy disk.

To use Registry Editor to save the SYSTEM key

1. Run Registry Editor (Regedt32.exe).

2. Click the HKEY_LOCAL_MACHINE\SYSTEM key. On the Registry menu, click Save key.

3. Enter the path to the file where you want to save the key.

Saving the DISK Subkey

The HKEY_LOCAL_MACHINE\SYSTEM\DISK subkey in the Registry contains configuration information about currently defined drive letters, volume sets, stripe sets, stripe sets with parity, and mirror sets, as well as CD-ROM mappings and drive mappings. Any time that you make changes to your disk configuration, Windows NT updates the DISK subkey. You should save this key whenever you make changes that affect it, such as:

  • Creating or deleting a disk partition.
  • Changing a drive letter.
  • Creating or deleting a volume set, stripe set, mirror set, or stripe set with parity.

Having a backup is useful in situations when you do not want to restore the entire Registry or the entire SYSTEM key, such as the following:

  • You want to move a volume set, stripe set, or stripe set with parity to another computer because of a hardware failure.
  • Configuration information about a volume has been corrupted.
  • You need to replace hardware.

For example, if you have changed a SCSI controller, restoring the entire SYSTEM key might make it difficult to start the computer. Restoring the DISK subkey enables you to have current disk configuration information without changing anything else in the Registry.

Note

The DISK subkey does not exist the first time that you start Windows NT. Disk Administrator creates the key the first time that you run it.

To use the Registry Editor to save the DISK subkey

1. Run Registry Editor (Regedt32.exe).

2. Click the HKEY_LOCAL_MACHINE\SYSTEM\DISK subkey. On the Registry menu, click Save key.

3. Enter the path to the file where you want to save the key.


Creating an Emergency Repair Disk

When you install Windows NT, Setup creates the Registry information in %systemroot%\System32\Config. For recovery purposes, Setup also creates a %systemroot%\Repair folder that contains the following files:

File Name | Contents
Autoexec.nt | Copy of %systemroot%\System32\Autoexec.nt, which is used to initialize the MS-DOS environment.
Config.nt | Copy of %systemroot%\System32\Config.nt, which is used to initialize the MS-DOS environment.
Default._ | Registry key HKEY_USERS\DEFAULT, compressed.
Ntuser.DA_ | Compressed version of %systemroot%\Profiles\Default User\Ntuser.dat. The repair process uses Ntuser.da_ if this one needs to be repaired.
Sam._ | Registry key HKEY_LOCAL_MACHINE\SAM, compressed.
Security._ | Registry key HKEY_LOCAL_MACHINE\SECURITY, compressed.
Setup.log | Log of which files were installed, and cyclic redundancy check (CRC) information for use during the repair process. This file is Read Only, System, and Hidden, so it will not be visible unless you have configured My Computer or Windows NT Explorer to show all files.
Software._ | Registry key HKEY_LOCAL_MACHINE\SOFTWARE, compressed.
System._ | Registry key HKEY_LOCAL_MACHINE\SYSTEM, compressed.

During installation, Windows NT Setup asks whether you want to create an Emergency Repair Disk. You should choose Yes. When you create an Emergency Repair Disk during installation, or later by using the Repair Disk program (Rdisk.exe), the files are copied from %systemroot%\Repair to the floppy disk. You can also use the Emergency Repair Disk to repair a corrupt Partition Boot Sector for the system partition.

When you run the Repair Disk program, you can update the %systemroot%\Repair\Software and %systemroot%\Repair\System files with the current information in %systemroot%\System32\Config by using the Update Repair Info button.

The Repair Disk program does not update the Default, Sam and Security files if you run the program from Windows NT Explorer or My Computer. To update all the files, you can run rdisk from the command prompt by entering:

rdisk /s

You can also update all of the files by clicking the Start button, clicking Run, and entering:

rdisk /s

Using the /s switch forces the Repair Disk program to update all of the Registry keys in the %systemroot%\Repair folder.

There are several points to consider about maintaining and using your Emergency Repair Disk:

  • If you did not use the /s switch before you create the Emergency Repair Disk, and you use the Repair process to replace the SYSTEM Registry keys, all passwords in the system return to the passwords in effect at the time you last updated the Sam and Security files in %systemroot%\Repair. If you have more recently backed up these keys by using Windows NT Backup, Regback.exe, or Regedt32.exe, you can restore more current information.
  • If you did not update the Emergency Repair Disk after using Disk Administrator to configure volume sets, stripe sets, mirror sets, or stripe sets with parity, it might be difficult or impossible to recover data on these volumes. When you create any of these volumes, Disk Administrator updates the DISK subkey in the Registry and sets the fault-tolerant bit on the System ID field of the Partition Table for each partition or logical drive in the volume.
  • You should make a copy of your current Emergency Repair Disk.
  • If you convert your boot partition from the FAT file system to the NTFS file system on an x86-based computer, be sure to update your Emergency Repair Disk. The NTFS Partition Boot Sector must be on the Emergency Repair Disk, not the FAT Partition Boot Sector.
  • The Emergency Repair Disk is not a replacement for backups.

For more information about creating an Emergency Repair Disk, see Help for the Repair Disk program. For more information about the %systemroot%\Repair and %systemroot%\System32\Config folders, and the Emergency Repair Disk, search the Knowledge Base. For information about the Knowledge Base, see Chapter 8, "General Troubleshooting."

Chapter 23, "Overview of the Windows NT Registry," in the Windows NT Workstation Resource Guide, contains more information about these keys and the %systemroot%\System32\Config folder.


Backing up the Master Boot Record and Partition Boot Sector

No operating system can protect itself from damage to these disk areas, which can be caused by viruses, faulty SCSI configurations, device driver problems, or power outages. You should back up the Master Boot Record on a disk every time you change partition information for primary partitions or an extended partition. You should back up a Partition Boot Sector when you format a volume, install Windows NT in the volume, or convert a volume from the FAT file system to the NTFS file system.

You can back up these disk sectors by using the Windows NT-based program, DiskProbe, or the MS-DOS-based program, DiskSave. Both of these utilities are on the Windows NT Server Resource Kit CD. The procedures for using DiskProbe and DiskSave are described in Chapter 7, "Disk, File System, and Backup Utilities."

If you have more than one hard disk, or more than one partition on a disk, you should back up every Master Boot Record and Partition Boot Sector. The Master Boot Record for the startup disk and the Partition Boot Sector for your system partition are the most critical. The ones for the other disks and volumes are not as critical to the startup process, but you might not be able to access files if the Master Boot Record for the disk or the Partition Boot Sector for the volume is not correct.

Chapter 6, "Troubleshooting Startup and Disk Problems," describes how to determine if you have a problem with one of these sectors.


Backing Up Data on Your Hard Disks

Regularly backing up data on hard disks minimizes data loss or damage caused by disk failures, power outages, virus infection, and many other possible computer problems. If your backup operation is based on careful planning and reliable equipment, file recovery should be relatively easy.

Windows NT includes a backup program, Ntbackup.exe, that you can use to save data to cartridge tape on computers running Windows NT Server and Windows NT Workstation. Whether you use this program or another type of tape backup system, you need to consider the following:

  • What data to back up.
  • What hardware to get.
  • Where to locate your tape drive.
  • What type of backup procedure to use.
  • What backup schedule to follow.
  • Where to store tapes.

Once you have designed a backup operation, document both your backup and restore procedures. After your backup system is in place, it is a good idea to periodically practice restoring an entire server, as well as individual files.

For more details about what you should cover in your backup plan, see the section titled "Backup Strategy," in Chapter 4, "Planning a Reliable Configuration." For more information about the Ntbackup program, and planning your backup procedure, see Chapter 6, "Backing Up and Restoring Network Files," in the Microsoft Windows NT Server Concepts and Planning book.


Understanding ARC Pathnames

Advanced RISC Computing (ARC) naming conventions are a standard for identifying the location of a file or a program on a device such as a hard disk or a floppy disk. You must understand the ARC pathname conventions to be able to create paths to use to start the computer from the Windows NT startup floppy disk.

On x86-based computers, you use ARC pathnames to describe the location of the boot partition for each instance of Windows NT installed on the computer. If you configure your boot partition as a mirror set, you need to include a path to the shadow boot partition in the Boot.ini file. Creating the path is described in "Creating Alternate Boot Selections for an x86-based Computer," presented later in this chapter.

On x86-based computers, the ARC path to the boot partition has one of the following forms:

  • multi(W)disk(X)rdisk(Y)partition(Z)\%systemroot%
  • scsi(W)disk(X)rdisk(Y)partition(Z)\%systemroot%

On RISC-based computers, you use ARC pathnames in the NVRAM to describe the location of:

  • The folder containing Osloader.exe and Hal.dll.
  • The full path to Osloader.exe.
  • The path to the boot partition.
  • Devices detected by the firmware, such as disks, keyboard, and video.

When you create a Windows NT startup floppy disk to use on a RISC-based computer, you need to modify the NVRAM to include the ARC path to the floppy disk. If you configure your boot partition as a mirror set, you also need to include an ARC path to the shadow boot partition in your NVRAM. Creating boot selections for both the Windows NT startup floppy disk and the shadow boot partition is described in the section titled "Creating Alternate Boot Selections for a RISC-based Computer," presented later in this chapter.

On a RISC-based computer, only the scsi() syntax is used for hard disks. The boot selection has the following parts:

  • LOADIDENTIFIER is the name that appears on the Boot menu for this boot selection.
  • SYSTEMPARTITION is the FAT partition that contains Osloader.exe and Hal.dll.
  • OSLOADER is the path to the OSLOADER file itself.
  • OSLOADPARTITION is the boot partition that contains the Windows NT system files.
  • OSLOADFILENAME is the name of the Windows NT folder in the boot partition, with no drive letter.
  • OSLOADOPTIONS indicates any debugging options that should be set up when loading Windows NT.

This is an example of a boot selection for a RISC-based computer:

  • LOADIDENTIFIER=Windows NT Server 4.0
  • SYSTEMPARTITION=scsi(0)disk(0)rdisk(0)partition(1)
  • OSLOADER=scsi(0)disk(0)rdisk(0)partition(1)\Os\Nt40\Osloader.exe
  • OSLOADPARTITION=scsi(0)disk(0)rdisk(0)partition(2)
  • OSLOADFILENAME=\Winnt
  • OSLOADOPTIONS=nodebug


multi(W)disk(X)rdisk(Y)partition(Z)

This form of the ARC pathname is only used on x86-based computers. On Windows NT version 3.1, it was only valid for IDE, EIDE, and ESDI disks. In Windows NT 3.5 and later, it is valid for SCSI disks as well.

The multi() syntax indicates to Windows NT that it should rely on the system BIOS to load system files. This means that NTLDR, the boot loader for x86-based computers, will be using interrupt (INT) 13 BIOS calls to find and load Ntoskrnl.exe and any other files it needs to get the system running.

Note

The term multi() syntax refers to the multi(W)disk(X)rdisk(Y)partition(Z) form of the ARC pathname.

The W, X, Y, and Z parameters have the following meaning:

  • W is the ordinal number of the controller, and should always be 0.
  • X is not used for multi(), and is always 0.
  • Y is the ordinal for the disk on the controller, and is always 0 or 1 for disks connected to the primary controller. The range is 0 through 3 for disks on a dual-channel EIDE controller.
  • Z is the partition number. All partitions receive a number except for type 5 (Extended) and type 0 (unused) partitions. These numbers start at 1, as opposed to all other entries, which start with 0.

Theoretically, the multi() syntax could be used to start Windows NT from any disk on the computer. However, this would require that all disks be correctly identified through the standard INT 13 interface. But support for this varies from controller to controller, and most system BIOS only identify a single controller through INT 13.

For a configuration with IDE or EIDE disks, the multi() syntax works for up to four disks on the primary and secondary channels of a dual-channel controller. In a SCSI-only configuration, the multi() syntax works for the first two disks on the first SCSI controller (the controller whose BIOS loads first). When your computer has both SCSI and IDE or EIDE disks, the multi() syntax works only for the IDE or EIDE disks on the first controller.


scsi(W)disk(X)rdisk(Y)partition(Z)

The scsi() syntax is used for both RISC-based and x86-based computers, and is used in all versions of Windows NT. Using the scsi() syntax indicates that Windows NT needs to load a SCSI device driver and use that driver to access the boot partition.

Note

The term scsi() syntax refers to the scsi(W)disk(X)rdisk(Y)partition(Z) form of the ARC pathname.

On an x86-based computer, the device driver is Ntbootdd.sys, which can be found in the root of the system disk (generally C:). It is a copy of the device driver for the disk controller in use. On a RISC-based computer, the driver is built into the firmware, as required by the RISC standards, so no file is required.

The W, X, Y and Z parameters have the following meaning when using the scsi() syntax:

  • W is the ordinal number of the controller as identified by the Ntbootdd.sys driver.
  • X is the SCSI ID of the target disk.
  • Y is the SCSI logical unit number (LUN) of the disk that contains the boot partition. Y will almost always be 0.
  • Z is the partition number. All partitions receive a number except for type 5 (Extended) and type 0 (unused) partitions. These numbers start at 1, as opposed to all other entries, which start with 0.

When using scsi() syntax, the value of W depends upon Ntbootdd.sys. Each SCSI device driver used in Windows NT has its own method of ordering controllers, although the controller order corresponds to the order that the BIOS on the controllers loads (if they are being loaded).

Additionally, if you have more than one SCSI controller, and they use different device drivers, you should only count the controllers that are controlled by Ntbootdd.sys when determining the value of the W parameter. For instance, if you have an Adaptec 2940 (which uses Aic78xx.sys) and an Adaptec 1542 (which uses Aha154x.sys), W will always be 0. What changes is the Ntbootdd.sys file:

  • If you are loading Windows NT from a disk on the Adaptec 2940, Ntbootdd.sys will be a copy of Aic78xx.sys.
  • If you are loading Windows NT from a disk on the Adaptec 1542, Ntbootdd.sys will be a copy of Aha154x.sys.


Example ARC Pathnames

This section contains examples that you can use as models. The first two examples are for ARC pathnames on x86-based computers. The last example is a boot selection on a DEC Alpha AXP 150 computer, and should be good for all RISC-based computers with similar disk configurations.

More Than One SCSI Controller on an x86-based Computer

This example for an x86-based computer has the following disks and controllers:

  • Two Adaptec 2940s, each with two 1 GB hard disks at ID 0 and ID 1.
  • One Adaptec 1542, with two 1 GB hard disks at ID 0 and ID 4.

Each hard disk has a single, 1 GB primary partition. Partitions 1 and 2 are on the first 2940, partitions 3 and 4 are on the second 2940, and partitions 5 and 6 are on the 1542. These are the ARC pathnames that you would have in the Boot.ini file if each partition had a copy of Windows NT installed in a folder named Winnt:

  • Partition 1: multi(0)disk(0)rdisk(0)partition(1)\Winnt
  • Partition 2: multi(0)disk(0)rdisk(1)partition(1)\Winnt
  • Partition 3: scsi(1)disk(0)rdisk(0)partition(1)\Winnt
  • Partition 4: scsi(1)disk(1)rdisk(0)partition(1)\Winnt
  • Partition 5: scsi(0)disk(0)rdisk(0)partition(1)\Winnt
  • Partition 6: scsi(0)disk(4)rdisk(0)partition(1)\Winnt

For partitions 3 and 4, Ntbootdd.sys is a copy of Aic78xx.sys. For partitions 5 and 6, Ntbootdd.sys is a copy of Aha154x.sys. For partitions 1 and 2, you could also use the following pathnames:

  • Partition 1: scsi(0)disk(0)rdisk(0)partition(1)\Winnt
  • Partition 2: scsi(0)disk(1)rdisk(0)partition(1)\Winnt

provided that you had an Ntbootdd.sys file that was a copy of Aic78xx.sys. However, Windows NT Setup always use the multi() syntax for the first two SCSI disks.

Both EIDE and SCSI Controllers on an x86-based Computer

This example is for an x86-based computer with the following disks and controllers:

  • A dual-channel EIDE controller with three 1 GB disks, two on the primary channel and one on the secondary channel.
  • An Adaptec 2940 controller with a single 4 GB hard disk at ID 3.

The three EIDE disks each have a single 1 GB partition. Partitions 1 and 2 are on the primary channel of the EIDE controller, and partition 3 is on the secondary channel.

The SCSI disk has four 1 GB partitions. Partitions 4, 5, 6 and 7 are on the SCSI disk. Each partition would have the following ARC pathnames in the Boot.ini file, assuming that each partition has Windows NT installed in the Winnt folder:

  • Partition 1: multi(0)disk(0)rdisk(0)partition(1)\Winnt
  • Partition 2: multi(0)disk(0)rdisk(1)partition(1)\Winnt
  • Partition 3: multi(0)disk(0)rdisk(2)partition(1)\Winnt
  • Partition 4: scsi(0)disk(3)rdisk(0)partition(1)\Winnt
  • Partition 5: scsi(0)disk(3)rdisk(0)partition(2)\Winnt
  • Partition 6: scsi(0)disk(3)rdisk(0)partition(3)\Winnt
  • Partition 7: scsi(0)disk(3)rdisk(0)partition(4)\Winnt

Loading Windows NT from partitions 4 through 7 requires that the Ntbootdd.sys file be a copy of Aic78xx.sys.

Boot Selection on a DEC Alpha AXP 150

On a RISC-based computer, all boot paths are defined in the NVRAM. When creating a new boot selection for a RISC-based computer, the firmware menus prompt you for the information to enter. There are examples for defining boot selections in the section titled "Creating Alternate Boot Selections for a RISC-based Computer," presented later in this chapter.

The following example is a boot selection on a DEC Alpha AXP 150. The computer has a single hard disk at ID 0, which has a 4 MB system partition and a 396 MB boot partition. Windows NT is installed on the boot partition in a folder named Winnt and the OSLOADER folder is also named Winnt, although it is on the system partition. The boot selection has the following values:

  • LOADIDENTIFIER=Windows NT Server 4.0
  • SYSTEMPARTITION=scsi(0)disk(0)rdisk(0)partition(1)
  • OSLOADER=scsi(0)disk(0)rdisk(0)partition(1)\Os\Winnt\Osloader.exe
  • OSLOADPARTITION=scsi(0)disk(0)rdisk(0)partition(2)
  • OSLOADFILENAME =\Winnt
  • OSLOADOPTIONS=nodebug


Creating Floppy Disks for Starting Your Computer

For x86-based computers and RISC-based computers, you should create a floppy disk to use to start Windows NT if you cannot start up from the hard disk. For x86-based computers, you can also create a bootable floppy disk that you can use to start MS-DOS if you cannot start Windows NT.

Creating each floppy disk requires two steps:

  • Format the disk.
  • Copy files to the disk.

After you create the Windows NT startup floppy disk or the MS-DOS bootable floppy disk, run a virus scan program to make sure the disk is not infected. Lock the floppy disk after you finish running the virus scan. (Most floppy disks have a tab on their back side that you slide down to lock the disk. You cannot write on a floppy disk when the tab is in the locked position.)

You should test each disk before you have to use it. You should also be familiar with using the programs that you copy to the floppy disks.

Depending on your disk configuration and whether you are using an x86-based computer or a RISC-based computer, you might also have to create alternate boot selections to your Windows NT startup floppy disk. For a description of the ARC pathname conventions that you need to use in boot selections, see "Understanding ARC Pathnames," presented earlier in this chapter.

Whenever possible, you should use an ARC pathname created by Windows NT Setup during an installation. When in doubt, install a copy of Windows NT onto the disk that you want to use for the boot partition, and then copy that ARC pathname, changing the partition number and folder name as necessary.


Windows NT Startup Floppy Disk

You must format your Windows NT startup floppy disk when you are running Windows NT. You can use My Computer to format the floppy disk, or enter format a: at the command prompt. Both of these utilities copy the Windows NT Partition Boot Sector, which is required to load the Windows NT boot loader, to the floppy disk. Windows NT Help describes the procedure for formatting a floppy disk by using My Computer.

You can use the Windows NT startup floppy disk to start Windows NT in the following circumstances:

  • The Master Boot Record or Partition Boot Sector on the system partition has a problem.
  • There are problems with the disk that contains the system partition and the boot partition is on another disk.
  • You are reconfiguring hard disks and you want to be able to start Windows NT from the Windows NT startup floppy disk if you are having problems.

You can configure your system or boot partition as a mirror set. A mirror set creates an identical twin for the selected partition. Creating a mirror set is similar to making a copy of a document by using a copy machine. The original partition is like the original of the document, and the shadow partition is the copy. Unlike a copy machine, however, Windows NT continually updates the shadow partition when any changes are made to the original.

If you create a mirror set for your system or boot partition, there are more situations in which you can use the Windows NT startup floppy disk.

  • The system and boot partitions are the same partition, and the partition on the original disk has failed.
  • The system and boot partitions are different, and the system partition on the original disk has failed. Even though the boot partition is still good, the computer cannot access the startup files on the original system partition.
  • Your computer running Windows NT Server is an x86-based computer, the system partition is different from the boot partition, and the original boot partition has failed. Even though you still have the system partition, the ARC pathname in the Boot.ini file on the system partition points to the failed disk.

Note

On x86-based computers, if the Partition Table in the Master Boot Record has been corrupted, especially if the information for the system partition or boot partition is all zeroes, you might not be able to start up by using the Windows NT startup floppy disk. If you have a current backup of the Master Boot Record, try starting MS-DOS from the MS-DOS bootable floppy disk, and use the DiskSave program to replace the Master Boot Record.

The files that you need to copy to the floppy disk normally have the Read Only, System, and Hidden attributes set. If the files have either the System or Hidden attribute set, they are not visible. You need to make the files visible before you can copy them.

To copy files to the Windows NT startup floppy disk

1. Using My Computer or Windows NT Explorer, on the View menu, click Options.

2. On the View tab, select Show all files. Click OK.

3. Click the filename of the file to be copied.

4. On the File menu, click Properties.

5. In the Attributes box of the General tab, clear the Read Only, System, and Hidden check boxes, and click OK.

Do steps 3, 4, and 5 for each file that you want to copy.

Select the files, and then copy them to the floppy disk.

Files to Copy for an x86-based Computer

Copy the following files from the root folder of your system partition to the floppy disk you just formatted:

  • NTLDR — Windows NT boot loader program.
  • Boot.ini — describes the location of the boot partitions, specified by using Advanced RISC Computing (ARC) naming conventions.
  • Ntdetect.com — used for hardware detection.
  • Bootsect.dos — if you want to be able to dual-boot another operating system when using the Windows NT startup floppy disk.
  • Ntbootdd.sys — required only if you are using the scsi() syntax in the Boot.ini file. This file is not present in the root folder if you are using the multi() syntax.

The Ntbootdd.sys file is a renamed copy of the SCSI device driver used on your Windows NT computer. For example, if you are using the Adaptec 1542B SCSI controller, copy Aha154x.sys to the floppy disk, and then rename it to Ntbootdd.sys. If Windows NT Setup created an Ntbootdd.sys in your root folder, just copy that file.

You can find the device driver name by

  • Looking in the HKEY_LOCAL_MACHINE\HARDWARE\DeviceMap\Scsi Registry key.
  • Double-clicking the SCSI Adapters option on Control Panel. In the Devices tab, click Properties. Click the Driver tab to see the driver filename.

Creating Alternate Boot Selections for an x86-based Computer

To start Windows NT Server after the failure of the original system or boot partition on a mirror set, you need to have a path to the shadow boot partition in your Boot.ini file. Be sure to edit the Boot.ini file to create startup options for every contingency for your configuration.

Note

If you have created a mirror set of your system partition, you need to set the Boot Indicator flag in the System ID field of the shadow partition. Disk Administrator does not set the Boot Indicator flag when it creates the shadow partition. Use the DiskProbe program to set this flag. For information about DiskProbe, see Chapter 10, "Disk, File System, and Backup Utilities." For more information about the Boot Indicator flag, see Chapter 3, "Disk Management Basics."

If the configuration of the partitions on your original disk and shadow disk are not the same, be sure to use the correct partition number when you create the path to the boot partition on the shadow disk. For example, you might have an EISA configuration partition as the first partition on your original disk, but not on the shadow disk. If you create a mirror set for each of the other partitions on the original disk, the partition numbers will be different on each disk.

The scsi() syntax is often required to start from the Windows NT startup floppy disk, even though the multi() syntax works to start from the hard disk. If your system fails to start from the Windows NT startup floppy disk, try using the scsi() syntax instead of the multi() syntax for the pathname.

Note

The system BIOS controls whether your system starts up from a floppy or hard disk. The Boot.ini file controls from which hard disk and partition the computer loads the Windows NT system files.

The Boot.ini file has the Read Only attribute set by default. Remove this attribute before editing the file. Restoring the attribute is optional. Windows NT Setup sets the attribute to prevent accidental deletion.

The rest of this section has information for creating the pathnames for three different configurations of SCSI disks and controllers. In each example, the boot partition is configured as a mirror set. There is more information presented later in this chapter about configuring the system partition as a mirror set, in the section titled "Configuring the System Partition on a Mirror Set."

For more information about ARC pathnames, scsi() and multi() syntax, and examples with IDE and EIDE disks, see "Understanding ARC Pathnames," presented earlier in this chapter.

Single SCSI Controller

To be able to start from the shadow boot partition by using the multi() syntax on computers with a single SCSI controller:

  • The shadow boot partition must be on one of the first two disks on the computer.
  • If the boot partition is on the second disk, the first two disks must be on the same controller.
  • The BIOS must be enabled on the controller.
  • You must have used the same apparent geometry when you low-level formatted each disk.
  • The disk with the shadow boot partition must be the next available SCSI ID on the bus.
  • The disk with the original boot partition must be powered down or removed from the bus.

The following example uses the multi() syntax.

[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\FT_TEST [operating systems] multi(0)disk(0)rdisk(0)partition(1)\FT_TEST="Windows NT Server" multi(0)disk(0)rdisk(0)partition(1)\FT_TEST="Windows NT Server [VGA]" /basevideo

If the original disk cannot be powered down, you need to have an entry in the Boot.ini file to force NTLDR to load from the shadow boot partition. This Boot.ini file loads the system from the shadow disk of a mirror set while the original disk is still functional. Rdisk(1) refers to the ordinal number and not the SCSI ID of the disk. This example has an entry for the shadow partition.

[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\FT_TEST [operating systems] multi(0)disk(0)rdisk(0)partition(1)\FT_TEST="Original Disk" multi(0)disk(0)rdisk(1)partition(1)\FT_TEST="Shadow Disk"
More Than One SCSI Controller

If you have more than one SCSI controller on the computer, startup after a failure to a mirror set is much easier if you use the following guidelines:

  • Use identical SCSI controllers. This minimizes problems with device driver, performance, and feature set differences.
  • Disable translation on the SCSI controllers.
  • When using duplexed mirror sets, load balance the controllers. Include the same number of disks on each controller, if possible. This step helps with performance.
  • Use the scsi() syntax in the Boot.ini file.

Here is a typical Boot.ini file for starting a computer with a mirrored boot partition, and each disk of the mirror set is on a different SCSI controller. Both the original and shadow disks are assigned SCSI ID 0 on their respective controllers.

[boot loader] timeout=30 default=scsi(0)disk(0)rdisk(0)partition(1)\FT_TEST [operating systems] scsi(0)disk(0)rdisk(0)partition(1)\FT_TEST="Original Disk" scsi(1)disk(0)rdisk(0)partition(1)\FT_TEST="Shadow Disk"

If the shadow disk was assigned SCSI ID 3, then the second entry is:

scsi(1)disk(3)rdisk(0)partition(1)\FT_TEST="Shadow Disk"
Dual-Channel SCSI Controllers

Many SCSI controllers have more than one channel on the adapter card. Even though there is a single card, it appears to the computer as if there are two separate controllers. There is quite a bit of variation in the way different manufacturers handle multiple channels. Be sure to test starting up from each of the channels and disks.

If a valid ARC path cannot be found to start the computer from the shadow boot partition, you need to make changes in the system configuration. It might be necessary to consult with the controller vendor to determine the correct configuration to be able to start Windows NT Server from the shadow partition if the original disk or SCSI channel fails. Many dual-channel controllers have an option in their Setup program, or the EISA configuration program, that enables you to specify the channel to use for the startup disk.

Files to Copy for a RISC-based Computer

When you install Windows NT on a RISC-based computer, it creates a folder, such as \Os\Winnt40, that contains the Osloader.exe and Hal.dll files. On Alpha AXP-based computers, this folder also contains several files with the .pal extension. Some or all of these files might have the system, hidden, or read-only attributes set.

A Windows NT startup floppy disk for a RISC-based computer should have a folder tree identical to the RISC-based system partition. Therefore, you should create the \Os\Winnt40 folder on the floppy disk.

Copy the following files from the \Os\Winnt40 folder on your hard disk to the same folder on the floppy disk:

  • Osloader.exe
  • Hal.dll
  • *.pal (AXP-based computers only)

Creating Alternate Boot Selections for a RISC-based Computer

RISC-based computers start from the system firmware. You should define a boot selection in the NVRAM that points to a Windows NT startup floppy disk. You only need to use the Windows NT startup floppy disk if your original disk fails and it contains the system partition (the partition with OSLOADER). If you create a mirror set for your boot partition, you should also create a path to the shadow boot partition.

If the configuration of the partitions on your original disk and shadow disk are not the same, be sure to use the correct partition number when you create the path to the boot partition on the shadow disk. For example, if you have an EISA configuration partition as the first partition on your original disk, but not on the shadow disk, the partition numbers on your shadow disk will be different than the partition numbers on your original disk.

There are three types of RISC-based computers: Alpha, MIPS, and Power PC. The examples in the remainder of this section are for an Alpha AXP computer. The firmware menus that you use to create and change boot selections can be different for MIPS and Power PC computers. For more information about RISC-based menus, see Chapter 19, "What Happens When You Start Your Computer," in the Windows NT Workstation Resource Guide.

Creating a Path to the Shadow Boot Partition

To create a path to the shadow boot partition, create an alternate boot selection by using the Add a boot selection menu. These are the steps to get to that menu:

1. Start the computer. You see the Boot menu.

2. On the Boot menu, click Supplementary menu.

3. On the Supplementary menu, click Setup the system.

4. On the Setup menu, click Manage boot selection menu.

5. On the Boot selections menu, click Add a boot selection.

The following example shows the screens you would see and the selections you would make to create a path to the shadow boot partition. In this example, the system partition and the boot partition are separate partitions on the same physical disk. Both partitions are mirrored. If they were the same partition, you would have fewer entries to make to create the boot selection. If the boot partition and system partition are the same partition, that partition is considered to be the system partition.

Note

The right justified arrows (<----) in these examples indicate which selection was made, or the information that was entered.

Thursday, 03-07-96 11:18:43 AM Select a system partition for this boot selection: SCSI Bus 0 Hard Disk 0 Partition 1 New system partition <----------------------------------------- Enter location of system partition for this boot selection: Select Media: SCSI Hard Disk <--------------------------------------------------- Floppy Disk CD-ROM Enter SCSI bus number: 0 <------------------------------------- Enter SCSI ID: 2 <------------------------------------- Enter Partition: 1 <------------------------------------- Enter the osloader directory and name: \os\winnt40\osloader.exe <------- Is the operating system in the same partition as the osloader: Yes No <------------------------------------------------------------ Enter the location of os partition: Select Media: SCSI Hard Disk <--------------------------------------------------- Floppy Disk CD-ROM Enter SCSI bus number: 0 <------------------------------------- Enter SCSI ID: 2 <------------------------------------- Enter Partition: 2 <------------------------------------- Enter the operating system root directory: \winnt40 <--------------- Enter a name for this boot selection: Boot Shadow Disk <--------------- Do you want to initialize the debugger at boot time: Yes No <-----------------------------------------------------------

After entering the data, you will be back at the Boot selections menu. Select Setup menu. On the Setup menu, select Supplementary menu, and save changes.

Creating a Path to the Windows NT Startup Floppy Disk

Once you have created the Windows NT startup floppy disk, you need to create the path to it. If you do not create a path to the floppy disk ahead of time, and your original disk fails, you will have to create a path to the Windows NT startup floppy disk to be able to start the computer.

Listed below is a sample of the configuration options used to build an alternate boot selection when the Windows NT startup files are located on the Windows NT startup floppy disk. As in the earlier examples, the arrows indicate which selections were made or which data were entered.

Thursday, 03-07-96 11:25:13 AM Select a system partition for this boot selection: SCSI Bus 0 Hard Disk 0 Partition 1 New system partition <----------------------------------------- Enter location of system partition for this boot selection: Select Media: SCSI Hard Disk Floppy Disk <------------------------------------------------------ CD-ROM Enter floppy drive number: 0 <--------------------------------- Enter the osloader directory and name: \os\winnt40\osloader.exe <------- Is the operating system in the same partition as the osloader: Yes No <------------------------------------------------------------ Enter the location of os partition: Select Media: SCSI Hard Disk <--------------------------------------------------- Floppy Disk CD-ROM Enter SCSI bus number: 0 <------------------------------------- Enter SCSI ID: 2 <------------------------------------- Enter Partition: 2 <------------------------------------- Enter the operating system root directory: \winnt40 <--------- Enter a name for this boot selection: start from floppy disk <--------- Do you want to initialize the debugger at boot time: Yes No <-----------------------------------------------------------

After entering the data, you will be back at the Boot selections menu. Select Setup menu. On the Setup menu, select Supplementary menu, and save changes.

Using Alternate Boot Selections

When you have created alternate boot selections, you start an alternate one by selecting Boot an alternate operating system from the Boot menu. This example shows selecting the alternate operating system option.

ARC Multiboot Alpha AXP Version 3.5-11 Copyright (c) 1993 Microsoft Corporation Copyright (c) 1993 Digital Equipment Corporation Boot Menu: Boot Windows NT Server Version 4.0 Boot an alternate operating system <------------------------------- Run a program Supplementary menu. . . Use the arrow keys to select, then press Enter. Seconds until auto-boot. Select another option to override: 9

If you have added boot selections for the shadow boot partition and the Windows NT startup floppy disk, as described earlier in this section, and select Boot an alternate operating system, you would see a screen like the following.

ARC Multiboot Alpha AXP Version 3.5-11 Copyright (c) 1993 Microsoft Corporation Copyright (c) 1993 Digital Equipment Corporation Boot Menu: start from floppy disk Boot Shadow Disk Boot Windows NT Server 4.0 (Default) Use the arrow keys to select, then press Enter.

Each time you create a new boot selection, it becomes the default selection. The preceding example shows the menu you would see if you:

  • Installed Windows NT Server 4.0.
  • Added the selection for the shadow boot partition.
  • Added the selection for the Windows NT startup floppy disk.

You should use the Rearrange boot selections menu to change the default boot selection back to the hard disk. See the section titled "Using a RISC-based Computer's Boot Menu," in Chapter 19 of the Windows NT Workstation Resource Guide, "What Happens When You Start Your Computer," for information about managing boot selections.


MS-DOS Bootable Floppy Disk (x86-based Computers)

An MS-DOS bootable floppy disk is most useful if you have FAT partitions on your startup disk (the disk that contains the system partition that you use to start Windows NT).

Your MS-DOS bootable floppy disk contains the files that you need to start MS-DOS from the floppy disk. It also should contain utilities for examining the contents of disks, copying files, and creating and formatting partitions.

Note

You must start the MS-DOS operating system to format the floppy disk that you will be using for your MS-DOS bootable floppy disk. Running format from the command prompt does not copy the correct Partition Boot Sector to the floppy disk.

To create an MS-DOS bootable floppy disk

1. Start MS-DOS. Put a blank floppy disk in drive A. Type format a: /s and press enter. You must specify the /s switch to make the floppy disk bootable. This switch causes the format program to copy the file Command.com to the floppy disk.

2. Copy other MS-DOS-based utilities that you might want to use to the floppy disk. At a minimum, you should copy these files:

Attrib

Copy

Format

Fdisk

Mem

Sys.com

a text editor

DiskSave


Training and Testing

The skill and experience of the server administrators and operators is a big factor in getting a failed computer back on line with minimal cost and disruption to your company's business. You must have support personnel who are trained in troubleshooting problems and determining what recovery procedures to use when they have found the cause of a problem.

A high level of skill can only be maintained through practice.

In preparing a training plan for server operators, you should start by imagining some typical scenarios. For example, does each operator know the steps to take to restart the computer when the original disk of a mirror set fails and the disk contains the operating system? Your plan should cover the following items:

  • Does the server operator have a Windows NT startup floppy disk? On a RISC-based computer, is there an alternate boot selection available for it?
  • When was the last time the Windows NT startup floppy disk was tested?
  • If the problem is a controller failure, how long will it take to replace the controller? Is the hardware configuration information immediately available?

Effective training must start with the basics. Server administrators and operators should have a good understanding of Windows NT Server. The Microsoft Certified Professional Program is a good starting point.

Understanding operating system fundamentals is only the beginning. Fast, efficient recovery from crashes of a computer running Windows NT Server can only be achieved through practice, which can be done by scheduling drills that simulate a crashed computer or a disk failure. These drills should be done several times a year.

Computers that have recently been taken out of service, or are being prepared for production service, can be used for training. You can also buy and configure computers to use specifically for testing and training. Training sessions and drills are a good time to update recovery procedures, which you should document.

You should also test your disaster plan. See Chapter 4, "Planning a Reliable Configuration," for information about disaster planning.


Documenting Recovery Procedures

You should develop step-by-step procedures for getting a computer back online after various failures. You can use these procedures for:

  • Testing a new computer before putting the computer into a production environment.
  • Training new server administrators and operators.
  • Creating a Server Operations Handbook, which should include procedures for setting up new user accounts, doing backups, maintaining the Emergency Repair Disk, and other common administrative tasks.

You should review your documentation when you make configuration changes to your computers or network. Updating the documentation is especially important when you install new versions of the operating system or change the utilities that you use to maintain your system.


Testing

Now that you have created floppy disks to use to start the computer, created an Emergency Repair Disk, and backed up the Master Boot Record and Partition Boot Sector, you should use the utilities and floppy disks to practice recovering from problems. Going through the recovery process will force you to be diligent about making backups (Emergency Repair Disk, Master Boot Record, Partition Boot Sector, and data). You will also have an idea as to how long doing each procedure should take.

You should have a computer that you can use to do the following:

  • Look at the Master Boot Records, Partition Tables, and Partition Boot Sectors.
  • Find the backup Partition Boot Sector on an NTFS partition.
  • Deliberately destroy and recover Master Boot Records and Partition Boot Sectors.
  • Delete Windows NT system files and restore them by using the Emergency Repair Disk.

If you have multiple disks in your configuration or have more than one installation of Windows NT, you should thoroughly test using your Windows NT startup floppy disk to start the computer from each boot partition. This is especially critical on x86-based computers when you have a configuration that has both SCSI and IDE or EIDI disks. Sometimes, when the multi() syntax works to start from a SCSI hard disk, you must modify the Boot.ini file on the Windows NT startup floppy disk to use the scsi() syntax.

Be sure to test recovery procedures before bringing a new computer or server into production. Every server operator should have both primary and refresher training in recovering from the most common causes of unexpected server downtime. Testing should include:

  • Making sure that your Windows NT startup floppy disks do their job.
  • Rebuilding mirror sets and stripe sets with parity.
  • Testing UPS on the computer running Windows NT Server and on hubs, routers, and other network components.
  • Testing the disaster plan.
  • Restoring from your backups.

If you configure your boot partition as a mirror set, be sure to test that the path to the shadow partition on your Windows NT startup floppy disk is correct.

The following test is sufficient to determine if the ARC path is correct. The Stop error indicates that the Kernel successfully loaded from the ARC path specified. If the ARC path is wrong, the computer cannot load the Kernel and you would get a message that says so.

Testing the Windows NT startup floppy disk

1. Shutdown Windows NT. Power down disks and controllers, if necessary, to test the path to the shadow boot partition.

2. Use the Windows NT startup floppy disk to start the computer.

3. If your boot selection correctly specifies the alternate ARC path to the shadow boot partition, your computer should get part way through the startup sequence, and then fail with the following Kernel STOP error:

*** STOP: 0x0000001E (0xc0000006,0x801Abe58,0x00000000,0x00000000) KMODE_EXCEPTION_NOT_HANDLED

If the computer has software fault-tolerant volumes (a mirror set or a stripe set with parity), you should test the failure and replacement of one of the disks. Even though fault-tolerant volumes continue to work when one disk has failed, there is no fault tolerance until you install a replacement disk. A second disk failure during this interval will result in loss of data, because you lost the redundancy when the first failure occurred. If a backup disk is not available on site, you should know the business cost of the resulting downtime.

If you have hardware RAID arrays, your vendor's documentation should describe how to recover from disk or controller failures. Be sure to test that their procedures work for your installation.

If a network card or other network component fails on the primary domain controller (PDC), the server operator should be familiar with the procedure for promoting a backup domain controller (BDC), and demoting the failed server. Someone who is familiar with the procedure for reinstalling and reconfiguring the network card should also be available.

If a data volume fails, the server operator must be able to restore the data from the backup tape quickly and efficiently. The restore procedure should be tested frequently, both to insure the skill of the operator, and to test the quality of the backup tapes. The only way to test the quality of backup tapes is to do a full restore, which guarantees that the data are up-to-date and of consistent quality.

If your backup procedures involve the use of other computers running Windows NT Server, you must also verify that those backup and restore procedures work as expected. For information about what and how to backup, see "Backup Strategy" in Chapter 4, "Planning a Reliable Configuration."


Restoring Disk Information

If you have backed up the Registry, Master Boot Records, and Partition Boot Sectors, as recommended earlier in this chapter, you can recover from many disk and startup problems without having to reinstall Windows NT. This section describes using your floppy disks and tools to restart your computer and restore information.

One important thing that you can learn from testing is the best recovery procedure to use in a particular situation. For example, there are several methods that you can use to replace a Partition Boot Sector. You also want to learn when to use the Windows NT startup floppy disk to restart your computer, and when you have to use the repair process and the Emergency Repair Disk to replace files in order to start.


Starting Up by Using the Windows NT Startup Floppy Disk

Using the Windows NT startup floppy disk enables you to start up Windows NT so that you can troubleshoot the problem, recover from the problem, or just get the computer running again. Being able to restart the computer also enables you to finish the work that you need to get done now, and troubleshoot the problem later.

In a way, the Windows NT startup floppy disk is a troubleshooting tool. If you cannot start the computer by using the hard disk, and you can start by using the Windows NT startup floppy disk, the problem is probably one of the following:

  • There are problems with the disk that contains the system partition, and the boot partition is on another disk.
  • Something is wrong with the system partition itself, the Partition Boot Sector for the system partition, or the files on the system partition that are needed to start Windows NT.
  • On an x86-based computer, you are reconfiguring your disks, and your first hard disk does not have a system partition yet.


Using the Emergency Repair Disk

If your system files, Registry information, or Partition Boot Sector are corrupt, and you are unable to start Windows NT by using the Last Known Good control set, you can use the Repair process in Windows NT Setup to restore your system so you can start up.

To repair a Windows NT installation, Setup needs either the configuration information that is saved on the %systemroot%\Repair folder or the Emergency Repair Disk created when you installed the operating system (or you created later by using the Repair Disk program).

You cannot repair all disk problems by using the Emergency Repair Disk. Your Emergency Repair Disk needs to match the version of Windows NT that you have installed on your computer. It also needs to have current configuration information. If you have more than one installation of Windows NT on your computer, you should have an Emergency Repair Disk for each installation. You should never use an Emergency Repair Disk from another computer.

To use the Emergency Repair Disk

1. Start the computer from the Windows NT Setup disk 1. Insert disk 2 when it is requested. When prompted, select the option to Repair by pressing the R key. Setup displays the following options:

[X] Inspect Registry files [X] Inspect startup environment [X] Verify Windows NT system files [X] Inspect boot sector Continue (perform selected tasks)

A description of each of the options follows this procedure.

2. Clear all selections that you do not want to use. Click Continue (perform selected tasks).

3. After disk 3, you will be prompted for the Emergency Repair Disk. Follow the instructions.

Setup displays the following messages after it has finished the repair process:

Setup has completed repairs. If there is a floppy disk inserted in drive A:, remove it. Press ENTER to restart your computer.

Inspect Registry Files

The Repair process in Windows NT Setup is one of several ways that you can repair Registry keys. When you select Inspect Registry files, Setup provides you with a list of the Registry files that it can restore. It also warns you that restoring a Registry file can result in information being lost. These are the options:

[ ] SYSTEM (System Configuration) [ ] SOFTWARE (Software Information) [ ] DEFAULT (Default User Profile) [ ] NTUSER.DAT (New User Profile) [ ] SECURITY (Security Policy) and SAM (User Accounts Database) Continue (perform selected tasks)

Select the key(s) that you want to restore by entering an X between the brackets, such as:

[X] SYSTEM (System Information)

See "Creating an Emergency Repair Disk," presented earlier in this chapter, for information about how often to create the disk, and how to save the current keys.

Inspect Startup Environment

This option verifies that the Windows NT files in the system partition are the correct ones. If any of the files that are needed to start Windows NT are missing or corrupt, Repair replaces them from the Windows NT Server CD.

On x86-based computers, if Windows NT is not listed in the Boot.ini file, Repair adds a Windows NT option to the file. If there is no Boot.ini file, Repair creates one.

On a RISC-based computer, Repair inspects and repairs the startup information in the NVRAM.

Verify Windows NT System Files

This option uses a checksum to verify that each file in the installation is good and matches the file that was installed from the Windows NT Server CD. Repair uses the Setup.log file on the Emergency Repair Disk to determine what files were installed and their checksums. The repair process also verifies that files needed to start, such as NTLDR and Ntoskrnl.exe, are present and valid. To find out if one or more service packs need to be reinstalled, check Files.lst on each service pack. The Windows NT Server CD is required for this option.

When Repair determines that the file on the disk does not match what was installed, it displays a message that identifies the file and asks whether you want to replace it.

Inspect Boot Sector (x86-based Computers)

This option verifies that the Partition Boot Sector on the system partition still references NTLDR, and replaces it from the Emergency Repair Disk if it does not. The Repair process can only replace the Partition Boot Sector for the system partition on the first hard disk. The Repair process can also repair the Partition Boot Sector for the system partition on the startup disk.

If you have saved the Partition Boot Sector, you can also use the procedures described in "Replacing the Master Boot Record and the Partition Boot Sector," presented later in this chapter, to replace it.


Restoring Registry Information

There are several methods that you can use to restore Registry information.

  • You can use the Repair process in Windows NT Setup, which requires the Emergency Repair Disk.
  • If you have used the Ntbackup program or the Windows NT Server Resource Kit program Regback.exe to backup the Registry, you can restore the keys from the backup media.
  • You can restore just the SYSTEM key or the DISK subkey by using the procedures described in this section.

Note

Windows NT Setup and the Repair Disk program store Registry information on the Emergency Repair Disk in compressed format. If you decide to restore the SYSTEM key from the Emergency Repair Disk by using either Disk Administrator or the Windows NT Registry Editor (Regedt32.exe), you can uncompress the System._ file by using one of the expand utilities. See Chapter 7, "Disk, File System, and Backup Utilities."

Restoring the SYSTEM Key

You can use the procedures in this section to restore the SYSTEM key. Because the Emergency Repair Disk also contains this key, you would generally use these procedures only if:

  • You do not have an Emergency Repair Disk.
  • You cannot read the Emergency Repair Disk, or the information isn't current.
  • You had to reinstall Windows NT and want to have the most recent configuration information.

To use this procedure, you need to have saved the information, following the procedures in the section titled "Saving the SYSTEM Key," presented earlier in this chapter.

To use Disk Administrator to restore the SYSTEM key

1. On the Partition menu, click Configuration.

2. On the Configuration menu, click Restore.

A message warns you that this operation will overwrite your current disk configuration information with what was previously saved on the floppy disk. Also, any changes made during this session will be lost.

3. Insert the floppy disk containing the saved configuration information.

4. Click OK.

Disk Administrator initiates a restart of your computer.

If you do not have a floppy disk that contains the current SYSTEM key, you can search for other Windows NT installations and restore the key from %systemroot%\System32\Config\System. In this case, the information might not match the configuration that you had been using.

To use Disk Administrator to search for and restore the SYSTEM key

1. On the Partition menu, click Configuration.

2. On the Configuration menu, click Search.

A message warns you that this operation will overwrite your current disk configuration information with the information from a different installation of Windows NT. Also, any changes made during this session will be lost.

3. Click OK.

Disk Administrator scans your disk for other Windows NT installations, and displays a list of the installations.

4. Select an installation.

5. Click OK.

Disk Administrator initiates a restart of your computer.

See Chapter 8, "General Troubleshooting," for details about troubleshooting problems by using the SYSTEM key.

Restoring the DISK Subkey

Both the Repair Disk program and Disk Administrator save the DISK subkey with the other information that they save. You would use this procedure only if you do not have current information on either of these media or you cannot read them. You might also want to use this procedure in special situations to restore just the DISK subkey, such as having to move a stripe set from one computer to another when the first computer has failed.

If you have previously saved the DISK subkey by using the Regedt32.exe (see the section titled "Backing Up the Registy," earlier in this chapter), then you can restore it.

To restore the DISK subkey by using Regedt32.exe

1. Run Regedt32.exe.

2. Select the Registry key HKEY_LOCAL_MACHINE\SYSTEM\DISK.

3. On the Registry menu, click Restore.

4. Enter the filename or click the path to the file.

If you are restoring the key to a remote computer's Registry, the C drive designation that appears in the scroll list refers to the C drive on the remote computer.

5. Click OK.


Replacing the Master Boot Record and the Partition Boot Sector

For information about determining if you have a problem with either of these disk sectors, and procedures for displaying them, see Chapter 6, "Troubleshooting Startup and Disk Problems." For information about the utilities that you can use to save, replace, and edit these disk sectors, see Chapter 7, "Disk, File System, and Backup Utilities."

Caution

Be careful when you use the low-level disk editors described in this section. If you replace the wrong sector, or change individual bytes to the wrong data, you can make your problems far worse. You could destroy information that is needed by Windows NT, and your only option would be to reformat the partition or the entire disk.

Replacing the Master Boot Record

There are two problems that can occur in the sector containing the Master Boot Record:

  • The Master Boot Record might be corrupt.
  • The Partition Tables can be damaged.

On many x86-based computers, the fastest and simplest way to replace the Master Boot Record on an x86-based computer is to use an MS-DOS bootable floppy disk with the MS-DOS-based program Fdisk on it.

Caution Do not use Fdisk to replace the Master Boot Record if you are using a:

  • Third-party translation program.
  • Dual-boot program that writes information in the area between the code and the Partition Table.
  • Third-party partitioning program that writes information in the area between the code and the Partition Table.

If you do not know whether you are using a program like this, you should not use this method.

To replace the Master Boot Record

1. Start the computer by using the MS-DOS bootable floppy disk. (You did run virus check and lock the floppy disk after you made it, didn't you?)

2. At the A:\ prompt, type fdisk /mbr.

This command replaces the Master Boot Record without altering the Partition Table at the end of the sector. There is no message or response.

If there is a Windows NT disk signature in the Master Boot Record, it is overwritten by the new Master Boot Record. Overwriting the disk signature is a problem only if the disk contains partitions or logical drives that are members of mirror sets, stripe sets with parity, volume sets, or stripe sets. You can safely overwrite the disk signature when the disk has none of these volumes, because Disk Administrator writes a new disk signature the next time you run it.

Note

The fdisk /mbr command requires MS-DOS 5.0 or later, and only works on the first hard disk on the computer.

If you have saved the Master Boot Record by using either DiskSave (x86-based computers only) or DiskProbe, you can use one of these utilities to replace the Master Boot Record. These utilities rewrite the entire sector, including the Partition Table. If you cannot start Windows NT from the hard disk, you can usually start the computer by using the Windows NT startup floppy disk if you want to use DiskProbe to replace the Master Boot Record.

If none of these methods are available to you, you can use a low-level disk editor to copy a good Master Boot Record from another disk to the startup disk (usually disk 0 on x86-based computers). Since the smallest disk write is a sector, when you copy the Master Boot Record from another disk, you are also copying the other disk's Partition Table, which is not valid for the current disk. Therefore, you must first write down the partition information in the Master Boot Record that you are going to replace, starting from 0x1BE. You have to manually reenter the Partition Table information in hex format into the newly copied sector.

If you can start Windows NT by using the Windows NT startup floppy disk, you can use DiskMap to print a map of the disk. When you have copied a Master Boot Record from another computer of the same type (for example, another computer made by the same manufacturer with the same models of disk controllers), use DiskProbe to enter the information for the Partition Table. For information about DiskMap and DiskProbe, see Chapter 7, "Disk, File System, and Backup Utilities."

After you have replaced the Master Boot Record, you should check that it is now correct. If the Master Boot Record is not correct after replacing it, there is either a hardware problem, such as incorrect SCSI termination, or (on x86-based computers) there is a virus in memory that is trapping interrupt (INT) 13 calls. You have to isolate and correct the problem that is corrupting the Master Boot Record.

Repairing the Partition Table

If you have not changed the Partition Table since you saved the Master Boot Record, replacing the Master Boot Record also replaces the Partition Table.

If you have made only minor changes to the Partition Table since you saved the Master Boot Record, you might be able to use the information on the backup to help you repair the Partition Table. For instance, if the only change you have made is to convert a partition from FAT to NTFS, just change the System ID byte from 06 to 07.

If your disk has more than one partition, and you did not save the Master Boot Record or write down the information, you might be able to reconstruct it. You can use DiskProbe to edit the Partition Table.

Note

If you will have to completely rebuild your Partition Table, either because of corruption or you had to copy the Master Boot Record from another computer, it might be safer to completely rebuild your disk. In this case, you should back up all of your files to tape (or another computer), recreate and reformat the partitions on the hard disk, and restore the data. If the disk with the invalid Partition Table contains your system or your boot partition, you will probably have to use the Windows NT startup floppy disk to start your computer.

Replacing the Partition Boot Sector

There are several methods that you can use to replace the Partition Boot Sector.

If you have saved the Partition Boot Sector by using either the DiskProbe or the DiskSave program, you can replace the sector from the backup. This is the fastest way to replace the Partition Boot Sector.

For NTFS volumes, there is one other alternative. When you create or reformat an existing volume as an NTFS volume, the NTFS file system writes a duplicate of the Partition Boot Sector at the end of the volume (Windows NT version 4.0) or at the logical center of the volume (Windows NT 3.51 and earlier). You can use the Windows NT-based program DiskProbe to locate and copy this sector to the beginning of the volume. There are also third-party MS-DOS-based disk utilities that you can use to locate and copy this sector.

You might want to display the Partition Boot Sector to make sure it is now correct. Once you have copied the Partition Boot Sector to the first sector of the partition, you should be able to start Windows NT.


Restoring Windows NT Files on the System Partition

If any of the files that Windows NT installs on the system partition are missing or corrupt, you cannot start your computer. These are the files:

x86-based file | Folder | RISC-based file | Folder
NTLDR | root | Osloader.exe | \Os\Winnt40
Boot.ini | root | no equivalent |
Bootsect.DOS | root | no equivalent |
Ntdetect.com | root | no equivalent |
Ntbootdd.sys (SCSI only) | root | no equivalent |
Hal.dll is in the boot partition |  | Hal.dll | \Os\Winnt40
no equivalent |  | *.pal files (Alpha-based computers) | \Os\Winnt40

You can restore any of these files by using the Repair process and the Emergency Repair Disk. However, because you copied these files to your Windows NT startup floppy disk when you created it, you can use that disk to restore them.

To use the Windows NT startup floppy disk to restore system files

1. Start your computer by using the Windows NT startup floppy disk.

2. Replace individual files, or replace all of the files, by copying them from the Windows NT startup floppy disk to the corresponding location on your system partition.


Configuring and Using Mirror Sets and Stripe Sets With Parity

This section discusses using features that are available in Windows NT Server software to implement mirror sets and stripe sets with parity. It does not discuss configuring or using hardware RAID arrays.

There are four topics in this section:

  • A general overview of mirror sets ands stripe sets, and the information that you see in Disk Administrator.
  • Configuring the system partition on a mirror set, which describes the best way to implement a mirror of the system partition. It also describes starting up by using the shadow system partition, and rebuilding the mirror set after you have repaired or replaced the failed component.
  • Procedures for creating mirror sets and stripe sets with parity.
  • Guidelines and procedures for reconstructing mirror sets and stripe sets with parity after you have repaired or replaced the failed component.


Overview

A mirror set creates an identical twin for the selected partition. Creating a mirror set is similar to making a copy of a document by using a copy machine. The original partition is like the original of the document, and the shadow partition is the copy. Unlike a copy machine, however, Windows NT continually updates the shadow partition when any changes are made to the original.

Note

In this chapter and other chapters in the "Reliability and Recoverability" part of this book, the terms original disk and original partition refers to the original partition, and shadow disk and shadow partition refers to the disk or partition that contains the copy.

A stripe set with parity is composed of strips of equal size on each disk in the volume. One of the strips in each stripe is used for parity information.

For a more complete description of mirror sets and stripe sets with parity, including the parity information, see the section titled "Planning a Fault-Tolerant Disk Configuration," in Chapter 4, "Planning a Reliable Configuration."

Because a mirror set or stripe set with parity requires more than one disk, you might have to buy and install additional disks. To increase the redundancy, you might want to buy more disk controllers. It is a good idea to have a spare disk and controller of the same type available. If you are using RAID hardware, follow the manufacturer's installation instructions. When using software fault tolerance, using SCSI controllers is more efficient and provides an additional recovery mechanism of sector sparing. For more information, see "Processing of Disk Errors" in Chapter 3, "Disk Management Basics."

You use Disk Administrator to create and recover mirror sets and stripe sets with parity. When you select one of the partitions of a mirror set or stripe set with parity, Disk Administrator displays information about the volume in the lower left corner of the window. The information looks like:

<Volume> #N [status]

where

  • <Volume> is stripe set, mirror set, or stripe set with parity.
  • N is the number of the volume.

The following table shows the possible status values.

Table 5.1 Disk Administrator status information for stripe sets, mirror sets, and stripe sets with parity

Mirror set | Stripe set with parity | Stripe set | Meaning
HEALTHY | HEALTHY | HEALTHY | The volume has been initialized, and there are no errors.
NEW | NEW | NEW | Appears immediately after the volume has been created, but before shutting down the system to begin generation of the volume.
REGENERATING | INITIALIZING | INITIALIZING | Generation of the volume has been started, but is not yet completed.
RECOVERABLE | RECOVERABLE | Not applicable | Appears when one of the partitions in the volume has been lost, but the other partition(s) is (are) undamaged. This message also appears when one partition loses synchronization with the other(s).


Configuring the System Partition on a Mirror Set

If you want to upgrade an existing Windows NT installation on a mirror set, you have to break the mirror set before starting Windows NT Setup. This means that you have to recreate the mirror set of the boot partition to have the Windows NT installation copied to the shadow partition.

The term duplexed mirror set means that each disk in the mirror set has its own disk controller. The controllers in a duplexed mirror set should be the same manufacturer and model

On x86-based computers, if your system partition is on a SCSI disk, you must have the BIOS enabled on its SCSI controller. Otherwise, the system BIOS will not be able to find Master Boot Record.

If you have created a mirror set of your system partition by using two SCSI controllers, you must make sure that you are using the same translation on the two controllers. If you are using different translations on your original disk and shadow disk, you will have to use the Windows NT startup floppy disk to start from the system partition on the shadow disk if the original disk fails. In addition, if you reconstruct the system partition on the original disk from the one on the shadow disk, you will not be able to start from either hard disk, and will always have to use the Windows NT startup floppy disk to start Windows NT.

You use the translation feature on SCSI controllers to set the translation mode. Because you have to disable the BIOS on the second controller, Windows NT always translates the geometry of the shadow partition to 32 sector per track and 64 heads per cylinder. Therefore, it is important to make sure the SCSI controller for the original disk is using the same translation. When their BIOS is enabled, most SCSI controllers default to a large disk translation scheme if the disk is larger than 1 GB. The geometry for this translation is 255 heads and 63 sectors. Most SCSI controllers have some method to manually configure the controller to use the 32 sectors, 64 heads translation. Using 32 sectors and 64 heads on the controller for the original disk insures that both disks are as close to a true sector by sector mirror image as possible. Recovery from failures of the original disk or its controller is much easier if the geometry of both disks is the same. The only disadvantage is that the system partition must be within the first 1 GB, or 1024 cylinders, of the disk.

Disabling the controller BIOS is different than turning off translation. Problems occur on x86-based computers because you need to have the BIOS enabled on the first controller in order to start the computer from the hard disk. If you do not turn off translation on both controllers, and the first controller fails, you need to enable the BIOS on the second controller. The translation on the second disk is now different than when you low-level formatted it, and you cannot use the disk. If your controller does not have the option to turn off translation, you can always leave the BIOS disabled, and use the Windows NT startup floppy disk to startup from the second controller.

Note

If you disable the BIOS on both controllers, it does not matter if translation is enabled or disabled. However, you will not be able to start up from the hard disk if the BIOS is disabled.

If you get a message "drive is too small" when you try to reconstruct the mirror set after the failure of the original disk, the translation is not consistent.

Having two different SCSI controllers makes a trouble-free system restart in the event of a hardware failure far more difficult. If you use two different SCSI controllers in your mirror set, you need to have a different SCSI device driver for each controller. When you create your Windows NT startup floppy disk, you need to copy both device drivers to the disk. Then, when you use the Windows NT startup floppy disk, you need to rename the one for the controller that you will be using to Ntbootdd.sys. Alternatively, you can create two separate Windows NT startup floppy disks, copy the appropriate driver to each one, and rename it to Ntbootdd.sys.

You can use EIDE controllers for a mirror set of the system partition, and using them is less complex than using SCSI controllers on x86-based computers. EIDE disks usually require motherboard BIOS support for logical block addressing (LBA), and each motherboard usually does the LBA in the same way for all EIDE disks.

If you are going to mirror an IDE or EIDI disk with a SCSI disk, you should not mirror your system partition. You will probably have problems with incompatible geometry, and will always have to use the Windows NT startup floppy disk to restart after a failure of your original system partition. However, you can safely mirror your boot partition.

Recovering from the failure of the original system partition can be difficult if you do not plan your configuration and recovery procedure carefully. Following the procedures in this section give you the easiest and most reliable recovery process.

To create a mirror set of the system partition

1. Enable the BIOS on the controller for the disk with the system partition, but make sure that translation is turned off if the disk is larger than 1 GB. Use the SCSI setup program to turn off translation and set the geometry to use.

2. Disable the BIOS on all other SCSI controllers.

3. Make sure that the two disks you are mirroring are identical models.

4. Low-level format both disks by using the controller that has the BIOS enabled.

5. Make sure the partition layout on the two disks is the same, and that the cluster size is the same on both partitions.

6. Install Windows NT on the original disk.

7. Create the mirror set.

8. When the mirror set has finished initializing, set the Boot Indicator flag for the shadow disk. Disk Administrator does not set this flag. You can use the DiskProbe program, described in Chapter 7, "Disk, File System, and Backup Utilities," to set this flag.

When the shadow disk or controller fails, recovery is basically the same as recovering from the failure of any mirror set. You should follow the same guidelines for having identical disks and controllers as described earlier in this chapter. You can use the procedures in "Recovering a Mirror Set," presented later in this chapter, to rebuild the mirror set when you have the replacement hardware.

When the original disk or controller fails, Windows NT automatically starts using the shadow disk for all accesses. However, sometimes a problem is not detected until you try to start the computer. In this case, you can use the Windows NT startup floppy disk to start from your shadow partition. This method minimizes the amount of time that you are down, and allows you to schedule the reconstruction of the mirror set for a less busy time. You might need to power down the failed disk or remove it from the SCSI bus before attempting to start from the shadow partition.

When you can schedule down time on the computer, use one of the following two methods to reconstruct the mirror set.

Simplest method to reconstruct the mirror set

1. While running Windows NT Server:

  • Break the mirror set, if you did not break it earlier. You can break the mirror set at any time after the failure, but you need to break it before you can start from your shadow disk without using the Windows NT startup floppy disk. The procedure to break the mirror set is described in the section titled "Recovering a Mirror Set," presented later in this chapter.
  • If you did not set the Boot Indicator flag in the System ID field of the system partition on the shadow disk, you can set it now by using Disk Administrator, because you have broken the mirror set. See Chapter 3, "Disk Management Basics," for information about this flag.
  • Shutdown the computer.

Note

If you do not break the mirror set, you might get a Stop error 0xC000021A. This error occurs when there is an inconsistency in the Registry key HKEY_LOCAL_MACHINE\SYSTEM. When you get this error after a failure of the mirrored system partition, it is usually because the FT bit is set in the Master Boot Record, but the HKEY_LOCAL_MACHINE\SYSTEM\DISK Registry subkey does not have information about the mirror set. Your only recovery in this situation is to use a third-party low-level disk editor to clear the high order two bits of the Boot Indicator field for this partition. You will still have to break the mirror set after you startup Windows NT.

2. Remove the old original disk.

3. Replace the original disk with the shadow disk, changing SCSI IDs, if necessary.

4. Restart the computer. You might get a STOP 0x7b, a missing operating system error message, or similar errors that indicate there is something wrong with the Master Boot Record or the system partition on the shadow disk. You can do the following things to try to start from the shadow disk:

  • On x86-based computers, start the computer from your MS-DOS bootable floppy disk and replace the Master Boot Record by entering fdisk /mbr at the MS-DOS prompt. See the caution about using this switch in the section titled "Replacing the Master Boot Record," presented earlier in this chapter.
  • To replace the Windows NT files on the system partition, use Windows NT Setup, and select repair. Select the options to Inspect boot sector and Inspect startup environment, but do not select Inspect Registry files or Verify Windows NT system files.

5. If you cannot start from the shadow disk, move the shadow disk back to its old position. Use the next procedure described in this section to reconstruct the mirror set.

6. If you can start from the shadow disk:

  • Shut down the computer.
  • Install a new disk in the shadow disk's previous location.
  • Low-level format the new shadow disk, if necessary. If you have a duplexed mirror set, and the disk is larger than 1 GB, be sure to use the same translation (32 sectors, 64 heads) on the two disks.
  • Start up the computer.
  • Use Disk Administrator to recreate the mirror set. Make sure to set the Boot Indicator flag on your newly created shadow disk by using DiskProbe.

There are times when the preceding procedure will not work, such as when you are using a Compaq computer with the EISA configuration partition as the first partition on the system disk.

The next procedure always works to recover from a failure of the original system partition if you set up your configuration as described earlier in this section, and if the shadow disk was not also damaged by the failure. You will need to schedule some down time for the computer when you are ready to replace the original disk.

The next procedure takes longer than simply swapping the original disk for the shadow disk and making the shadow disk the new original, but it guarantees that you have a stable system. After you have had one disk failure on the computer, you might not want to rely on the remaining disk as the original disk, because it might have been affected in some way. This procedure is much safer from a hardware as well as a software standpoint.

Most reliable method to reconstruct the mirror set

1. While running Windows NT Server:

  • Break the mirror set, if you did not break it earlier. You can break the mirror set at any time after the failure, but you need to break it before you can start from your shadow disk without using the Windows NT startup floppy disk. The procedure to break the mirror set is described in the section titled "Recovering a Mirror Set," presented later in this chapter.
  • If you did not set the Boot Indicator flag in the System ID field of the system partition on the shadow disk, you can set it now by using Disk Administrator, because you have broken the mirror set. See Chapter 3, "Disk Management Basics," for information about this flag.
  • Back up the entire shadow disk, including the Registry.
  • Shutdown the computer.

2. Replace the original disk with a new disk of the same make and model. (If you had to move the shadow disk or change its SCSI ID because of the failure, change it back to the original configuration.)

3. Low-level format the replacement disk, if necessary. If you have a duplexed mirror set, and the disk is larger than 1 GB, be sure to use the same translation for the two disks (32 sectors, 64 heads).

4. Install Windows NT on the new disk, creating and logically formatting partitions, as necessary. Make sure you install Windows NT into the same folder as your previous installation was in.

5. Start the new installation of Windows NT. Restore the backup, including the Registry.

6. Restart the computer from the original disk, and verify that the restore recovered all of the information on the disk.

7. Use Disk Administrator to delete the partitions on the shadow disk, and re-create the mirror. You might need to create other partitions on the shadow disk so you have the same layout on the two disks. Make sure to set the Boot Indicator flag on your newly created shadow system partition by using the DiskProbe program, as described in Chapter 7, "Disk, File System, and Backup Utilities."


Creating a Mirror Set or Stripe Set With Parity

If you are using all SCSI disks, it is a good idea to use the same translation on all SCSI controllers whose disks are members of a mirror set or stripe set with parity. On x86-based computers, you should disable translation any time that you do not need to do the following:

  • Dual-boot with MS-DOS.
  • Have a system partition or boot partition larger than 1 GB.

The following Disk Administrator screen shot shows three things:

  • The unpartitioned space that you can use to create a mirror set of primary partitions F and G is the 350 MB are on the right side of disk 0.
  • You cannot use the free space to the right of logical drive E for a mirror set, because it is free space at the end of an extended partition.
  • You cannot create a stripe set with parity, because you have only two disks. If you had a third disk, with unpartitioned space, you still could not create a stripe set with parity. You need at least three disks with unpartitioned space, and disk 1 is completely partitioned.

Note

The key below the status bar in Disk Administrator identifies what kinds of volumes are configured on the computer. For example, if you created a mirror set, you would see Mirror set in addition to Primary partition and Logical drive.

When you create a mirror set or stripe set with parity, Disk Administrator creates a primary partition for the areas of unpartitioned space that you select on each disk. You cannot use free space on a disk for either of these volumes if:

  • There are already three primary partitions, or two primary partitions and one extended partition defined on the disk.
  • The free space is part of an extended partition.

Disk Administrator Help contains details about procedures for creating mirror sets and stripe sets with parity.

Creating a Mirror Set

If you need to dual-boot with MS-DOS, you cannot mirror your system partition. If you need a boot partition larger than 1 GB, you need to enable translation. However, you should not mirror your system partition if it goes beyond 1 GB.

When you want to create a mirror set, the original partition that you want to mirror must already exist. You must have an area of unpartitioned disk space at least as large as the original partition on another disk connected to the computer.

If the unpartitioned space you select for the partition on the shadow disk is larger than the existing primary partition, the space left over remains unpartitioned space, and can be used to create other partitions (if there are fewer than four partitions on the disk). For example, if you create a mirror set using the configuration shown in the preceding Disk Administrator screen shot, there will be unpartitioned space following the shadow partition. However, you cannot use that unpartitioned space, because you will have three primary partitions and one extended partition on disk 0.

To use Disk Administrator to establish a mirror set

1. Select the partition that you want to duplicate. Press CTRL, and click an area of unpartitioned space on another disk that is the same size or larger than the partition you selected.

2. On the Fault Tolerance menu, click Establish Mirror.

Disk Administrator creates an equal-sized partition in the unpartitioned space for the mirror set, and assigns the drive letter to the mirror set.

Note In some cases, where a mirror set is being established, a slightly larger amount of space is required for the shadow partition than for the partition on the original disk. This happens when geometry differences exist between the disks.

If you are mirroring the system partition, Disk Administrator displays a message box reminding you to create a Windows NT startup floppy disk.

3. On the Partition menu, click Commit Changes Now. Select Yes in the Commit Changes dialog box.

A Confirm change/restart dialog box is displayed; again select Yes. A message box prompts you to update your Emergency Repair Disk, which you should do by using the Repair Disk program (Rdisk.exe). Finally, you are prompted to shutdown, and restart the system. The only option is OK. The system shuts down and restarts.

4. After the system restarts, open Disk Administrator. The status bar displays a message Mirror Set #N [INITIALIZING].

The drive letter, volume label, and size of the mirror set appear in red text. This visual cue indicates that the system is generating the partition in the background. While the text is highlighted in red, fault tolerance is not functional.

Note

In the Disk Administrator display, information about the partition is not updated automatically. If you click on the partition, the information for that volume updates. You can also check the event log to know when the generation of the shadow partition is finished.

Creating a Stripe Set With Parity

When you want to create a stripe set with parity, you must have at least three unpartitioned areas on different disks connected to the computer. Even though a partition is not completely full, you cannot use the space that is part of an existing partition. If you do not have enough unpartitioned space available, but have enough unused areas in existing partition(s), you can create unpartitioned disk areas by:

  • Backing up the data in the existing partition(s).
  • Deleting the partition(s).
  • Creating a new, smaller partition, leaving part of the disk unpartitioned.
  • Restoring the data to your new partition.

As with a mirror set, if the areas of unpartitioned space that you select for a stripe set with parity are not all the same size, the space left over can also be used for other partitions.

When using a stripe set with parity, performance should be better if you put the operating system and page file on a controller other than the one used for the strip set with parity. You can use different types of controllers for the operating system and the stripe set with parity when you have them on different controllers. For more suggestions, see "Stripe Set With Parity" in Chapter 4, "Planning a Reliable Configuration."

To use Disk Administrator to create a stripe set with parity

1. Select areas of unpartitioned space on three to 32 hard disks by selecting an area of unpartitioned space on the first disk, pressing CTRL, and then choosing additional areas of unpartitioned space on other hard disks.

If the areas selected vary in size, then the smallest area is used as the base partition size. For example, if the unpartitioned space consists of a 700 MB on disk 1, and 900 MB each on disks 2 and 3, only 700 MB on each disk is used as part of the stripe set with parity.

2. On the Fault Tolerance menu, click Create Stripe Set With Parity.

Disk Administrator displays the minimum and maximum sizes for the stripe set with parity. The default size is the maximum allowed for the disk areas selected.

The size you choose is the total disk space that is used, not the size available for data on the stripe set with parity. For example, if four 200 MB partitions are selected:

  • Disk Administrator displays 800 MB for the maximum size.
  • You have 600 MB available for data, if you select the maximum size. The other 200 MB are used to store the parity information.
  • If you want to use less than the maximum size, the formula is

    data size = (total size) - ((total size) / (number of disks))

3. On the Create Stripe Set With Parity dialog box, type the size of the set that you want to create, and then click OK.

Disk Administrator divides the total size that you enter by the number of disks in the set to create equal-sized, unformatted primary partitions on each of the selected disks. It then assigns a single drive letter to the collection of partitions that make up the stripe set with parity. Disk Administrator displays the stripe set with parity as New Unformatted space.

4. On the Partition menu, select Commit Changes Now.

You are prompted to save your disk configuration changes. Select Yes.

5. You are notified that you need to restart the computer for the changes to the configuration to take effect. Click Yes in the dialog box.

6. You are notified that the disks were updated successfully.

This means that the new configuration information has been saved in the Registry. This dialog box also prompts you to update the Emergency Repair Disk.

7. You are prompted to restart your computer so that the changes can take effect. The only option is OK. The system automatically closes all open applications and restarts the system.

8. When restart is completed, open Disk Administrator again. On the Tools menu, click Format. You can format a stripe set with parity with either the FAT file system or the NTFS file system. When you have entered all of the information in the Format dialog box, click Start. The stripe set with parity begins initializing immediately. Disk Administrator displays a message Stripe Set with Parity #N [INITIALIZING] on the status bar. The drive letter, volume label, and size of the stripe set with parity appear in red text during initialization.


Recovering a Mirror Set or Stripe Set With Parity

The process of error detection and recovery for software fault-tolerant volumes is very similar for both mirror sets and stripe sets with parity. The Windows NT response to the problem depends on when the problem occurred. For recovery of a hardware fault-tolerant volume, see the documentation for the controller that you are using.

When a disk that is part of a mirror set or a stripe set with parity fails during normal operation, it becomes an orphan. When FtDisk (the fault-tolerant driver) determines that a disk has been orphaned, it directs all reads and writes to the other disk(s) in the set.

It is important to note that the process of orphaning a partition does not occur during a read, only during a write. The read cannot possibly affect the data on the disks, so performing orphan processing is not necessary.

The following error message is displayed:

The operating system should continue to work normally. Users accessing resources over the network should not be affected.

You should back up important data immediately, since the volume is no longer fault tolerant. Use a new tape for backup, not an existing tape. You should replace the failed disk and begin the recovery of the mirror set or stripe set with parity as soon as possible.

During system initialization, if the system cannot locate a partition in a mirror set or a stripe set with parity, it logs a severe error in the event log, marks the partition as an orphan, and uses the remaining partition(s) of the mirror set or stripe set with parity. The system continues to function by using the fault-tolerant capabilities inherent in such volumes.

In Disk Administrator, if you select a mirror set or stripe set with parity that has had a failure, you see a message in the status bar that says <Volume> #N [RECOVERABLE] where <Volume> is either mirror set or stripe set with parity.

Recovering a Mirror Set

There are different methods to use for recovering mirror sets, depending on which partition failed, and whether it contains the system or boot partition. When the disk or controller for the original system or boot partition fails, you will probably have to use the Windows NT startup floppy disk to start from the shadow partition, or reconfigure the shadow disk as the original disk. For information about when you need to use the Windows NT startup floppy disk, see "Creating a Windows NT startup floppy disk," presented earlier in this chapter.

If the failure does not cause any disruption in service, you can continue running in a non-fault-tolerant configuration and schedule a time to regconstruct the mirror set. This activity could occur during a normally scheduled maintenance period or during a less busy time.

You must first break the mirror-set relationship to expose the remaining secondary partition as a separate volume. This step prevents problems when restarting the system.

To break the mirror set

1. Open Disk Administrator and select the mirror set you want to break.

2. On the Fault Tolerance menu, click Break Mirror.

3. In the Confirm message, select Yes.

The remaining, working member of the mirror set receives the drive letter that was previously assigned to the complete mirror set. The orphaned partition receives the next available drive letter, or whatever letter you want to assign.

You can now shut down the system and replace the failed disk. The failed disk can be replaced with any disk that is the same size or larger. It is a good idea to use a disk as similar to the remaining disk as possible. If the failed disk contained the system partition, see the section titled "Configuring the System Partition on a Mirror Set," presented earlier in this chapter.

Note

When you move or replace a disk that was at the end of a SCSI bus, be sure that you terminate only the disk that is now at the end of the bus.

To recontruct the mirror set

1. Perform a low-level format of the new disk on the same controller that will be used with the new disk.

This step eliminates any possibility of translation problems.

If the failed disk was the shadow disk, use the same SCSI ID as the failed disk.

If the failed disk was the original disk, you might want to swap SCSI IDs, so that the remaining disk becomes SCSI ID 0.

2. Restart the system.

3. Once you have restarted the computer, follow the procedure in the earlier section titled "Creating a Mirror Set or Stripe Set With Parity" to reconstruct the mirror.

This step requires a second restart of the system to reconstruct the mirror.

4. After the mirror initialization is complete, update your system information, if necessary, as described in the section "Maintaining Configuration and Essential System Information," earlier in this chapter.

Recovering a Stripe Set With Parity

When a member of a stripe set with parity is orphaned, you can reconstruct the data for the orphaned member from the remaining members. Use the following procedure to initiate the recovery of the stripe set with parity. When you restart the computer, the FtDisk program reads the information from the strips on the other member disks, reconstructs the data of the missing member, and writes it to the new member.

If your computer running Windows NT Server has failed and you need to have the data available sooner than the expected repair time, you can move the disks containing the stripe set with parity to another computer and build the Registry key HKEY_LOCAL_MACHINE\SYSTEM\DISK by using the FtEdit program. The procedure is described in Chapter 7, "Disk, File System, and Backup Utilities."

To reconstruct a stripe set with parity
  1. Open Disk Administrator, and select the recoverable stripe set with parity.
  2. Select an area of unpartitioned space of the same size or larger on the replacement disk.

If the failure is due to a power failure or cabling failure on a single device, you can regenerate within the orphaned member of the original stripe set with parity once the hardware state is restored.

  1. On the Fault Tolerance menu, choose the Regenerate command.
  2. Quit Disk Administrator, and restart your computer.

The reconstruction process occurs in the background. If you open Disk Administrator, the message in the status bar is Stripe set with parity #n [INITIALIZING].

You might receive the following error message when attempting to reconstruct a stripe set with parity:

The drive cannot be locked for exclusive use...

This error occurs if Disk Administrator does not have exclusive access to the stripe set with parity, which happens if the page file, or some other system service, like Microsoft SQL Server or Microsoft Systems Management Server, is accessing the disk. You must temporarily shutdown these services and relocate the page file to regenerate the stripe set with parity.

Note

You should not put your page file on a stripe set with parity, because it degrades performance. If you want to have your page file on a fault-tolerant volume, use a mirror set instead.


Using an Uninterruptable Power Supply

An Uninterruptable Power Supply (UPS) supplies power to a computer system in the event of a power fluctuation or complete power loss. The UPS has electronics built in that constantly monitor line voltages. If the line voltage fluctuates above or below predefined limits, or fails entirely, the UPS supplies power to the computer system from built-in batteries. The UPS converts the Direct Current (DC) battery voltage into the Alternating Current (AC) voltage required by the computer system. The changeover to batteries must take place very rapidly or the computer can lose data.

Most UPS devices are one of the following types:

  • Online UPS. You connect an online UPS between the main power and the computer to constantly supply your computer system with power. Connecting it to the main power keeps its battery charged. This method provides power conditioning, which means that it removes spikes, surges, sags, and noise.
  • Standby UPS. This device is configured to provide either the main power or its own power source and to switch from one to the other as necessary. When the main power is available, the UPS device connects the main power directly to the computer and monitors the main power voltage level. When the main power fails or the voltage falls below an acceptable level, the UPS device switches the power fed to the computer from the main power to its own power.

UPS systems provide a hardware interface that can be connected to the computer. Using appropriate software, this interface enables an orderly handling of the power failure, including performing a system shutdown before the UPS batteries are depleted. Without such software, an orderly shutdown of the system is not possible without human intervention.

The most important consideration in selecting a UPS product is to use only hardware that is listed on the Windows NT 4.0 Hardware Compatibility List (HCL). Other items to consider are:

  • Whether to use a UPS per computer or have larger capacity, centralized UPSs that protect multiple computers.
  • What type of UPS you want (standby and online are the most common).
  • The sizing for the UPS (how big the UPS needs to be to protect the load).
  • How long it needs to keep running before automatic shutdown.
  • Which features you want to have in your UPS, such as:
    • Continuous conditioning of the incoming power to provide clean, steady power.
    • A Simple Network Management Protocol (SNMP) card that you can plug into the UPS and use network management software to remotely monitor the UPS.
    • Software that logs UPS information to the event log, or produces statistics.
    • Software for testing the integrity and reliability of the UPS battery.

Windows NT has built-in UPS functionality that takes advantage of the special features that many UPS systems provide. These features ensure the integrity of data on the system and provide for an orderly shutdown of both the computer system and the UPS should a power failure last long enough that the UPS batteries become depleted. In addition, users connected to a computer running Windows NT Server can be notified that a shutdown will occur and new users are prevented from connecting to the computer. Finally, damage to the hardware from a sudden, uncontrolled shutdown can be prevented.

Some vendors also provide a user interface for configuring the UPS, which you can use instead of the one provided in Windows NT.

This section contains a general overview of the Windows NT UPS service and discusses configuring and using the UPS on a computer running Windows NT. To fully protect your network, you should also install UPSs on network devices such as routers, hubs, and bridges. For the best protection, install UPSs on the cables that connect your computer and modem, telephone, printer, and network equipment.

For more information about UPS, see Chapter 7, "Protecting Data," in the Windows NT Server Concepts and Planning book.


Configuring the UPS Service

Use the UPS option on Control Panel to configure the Windows NT UPS service. The following dialog box is displayed:

You need to specify the serial port that the UPS is installed on. The information that you enter in the other fields depends upon your specific UPS and how you want to use it.

When selecting the signals to use in the UPS Configuration group box, the interface voltages you specify are those that indicate an active state for the signal. In other words, if you select a negative interface voltage for the power failure signal, this means that the signal is normally positive and changes to negative when a power failure occurs.

If you want the UPS service to run a command file when a power failure occurs, select the Execute Command File check box and enter the name of the file. Windows NT terminates the command file if it does not complete its execution within 30 seconds. The command file should not contain a dialog box, since waiting for user input could exceed the 30 second requirement.

The command file must reside in your %systemroot%\System32 folder and have one of the following extensions:

  • .exe
  • .com
  • .bat
  • .cmd

If your UPS does not have a low battery signal, you need to set the fields in the UPS Characteristics group box. The documentation from your UPS vendor should specify the battery recharge rate.

At startup, the UPS service assumes that the battery has no charge. If the battery recharge rate is 100 minutes per minute of run time, the computer has to run for 100 minutes before Windows NT expects the battery to have one minute of life.


Signals Used by the UPS Service

Windows NT uses a serial (COM) port to connect to the UPS. Table 5.2 shows the signals that the UPS service uses to communicate with the UPS, the associated pin numbers, and the function each signal provides to the UPS service. You need to know which of these signals your UPS supports so that you can configure the UPS service.

If you use a UPS service provided by your UPS vendor, the signals and their usage will probably be different than the signals that the Windows NT UPS service uses.

Table 5.2 UPS serial port connections

RS-232 Signal | 9 Pin Connector Pin # | 25 Pin Connector Pin # | UPS Usage
CTS | 8 | 5 | Power failure
DCD | 1 | 8 | Low battery
DTR | 4 | 20 | UPS shutdown

In the UPS Configuration group box, check the boxes that correspond to the signals that your UPS supports. For each of these signals, the UPS Interface Voltages (negative or positive) indicates the voltage present when that event occurs.

Low Battery Signal

When the UPS battery begins to run low, the UPS uses this signal to notify the UPS service.

When fully charged, UPSs typically deliver from five to 20 minutes of DC power after AC power has failed. If your UPS can detect when the battery is running down, you should check the low battery signal box in the UPS Configuration group box.

If you do not check the low battery signal box, the UPS service uses the information in the UPS Characteristics group box to estimate how much time remains on the battery after a power failure.

Remote UPS Shutdown

You want to conserve the life of the UPS battery for as long as possible. The Windows NT UPS service uses the UPS Shutdown signal to notify the UPS that Windows NT has completed its orderly shutdown and that the UPS can shut off power to the computer.

Power Failure Signal

The power failure signal is generated by the UPS to signal the Windows NT UPS service that a power failure has occurred. The Windows NT processing that occurs when it receives this signal depends upon whether the UPS can send a low battery signal.

If the UPS can send a low battery signal:

  • The Windows NT UPS service waits the amount of time specified in the Time between power failure and initial warning message field of the UPS Service group box. It then sends a message to all users connected to the computer running Windows NT telling them that a power failure has occurred. No more users can connect to the computer after the message is sent.
  • If a signal is received from the UPS indicating that power has been restored before the low battery signal occurs, normal operations are resumed. Users are again allowed to connect to the computer.
  • When the UPS signals a low battery condition, the file specified in the Execute Command File group box is executed. After execution of this file, Windows NT initiates shutdown.
  • Once the shutdown is complete, the UPS service signals the UPS that battery power can be turned off if you have checked Remote UPS Shutdown.

If the UPS cannot send a low battery signal:

  • The UPS service computes the expected battery life left by dividing the Battery recharge time per minute of run time (in the UPS Characteristics group box) into the amount of time that Windows NT has been running. If the result is less than two minutes, then the file specified in the Execute Command File group box is executed and allowed 30 seconds to complete. Windows NT then initiates a shutdown.
  • If the expected battery life is greater than two minutes, the UPS service waits the amount of time specified in the Time between power failure and initial warning message field of the UPS Service group box. It then sends a message to all users connected to the computer running Windows NT telling them that a power failure has occurred. No more users can connect to the computer after the message is sent.
  • If a signal is received from the UPS indicating that power has been restored while the expected battery life is still greater than two minutes, normal operation resumes. Users are again allowed to connect to the computer.
  • When the calculated battery life reaches two minutes, the file specified in the Execute Command File group box is executed. After execution of this file, Windows NT initiates shutdown. If the program takes longer than 30 seconds to complete, Windows NT terminates it, and final shutdown take places.
  • Once the shutdown is complete, the UPS service signals the UPS that battery power can be turned off if you have checked Remote UPS Shutdown.


Using the UPS Service

You should use the following Windows NT services in combination with the Windows NT UPS service:

  • Alerter
  • Messenger
  • EventLog

The Alerter service sends alerts to selected users. The Messenger service sends messages to your local computer and to other users on the network who are running Windows NT. All detected power fluctuations and power failures are recorded in the event log, along with UPS service start failures and shutdown initiations.

If you want the UPS service to start each time you start your computer, you need to modify the startup information.

To start the UPS service automatically

1. On Control Panel, double-click Services.

2. On the Services dialog box, click UPS, then click Startup.

3. On the UPS Service dialog box, select Automatic, and then click OK.

You might need to use the preceding procedure to set the other services to start automatically.


Testing the UPS

When the UPS service is started, it verifies the settings in the UPS dialog box by ensuring that the signal polarity on the CTS and DCD pins is opposite to that specified as the failure condition in the UPS dialog box. For example, if the UPS dialog box specifies that the UPS device supports a Power Failure Signal (CTS pin) with a positive signal, the UPS service checks to make sure that this pin is not already asserted positive (which would not happen unless you had started the system during a power failure).

This has some important implications. With an online UPS, the UPS device might shut itself off immediately if the configuration is incorrect. With a standby UPS, an incorrect configuration typically shuts the UPS device off as soon as a power failure is detected, effectively circumventing the purpose of the UPS. This is why it is important to configure and test your UPS device to ensure that it operates correctly.

On x86-based computers, there is one other reason that it is important to test your UPS. During startup, Windows NT sends a detection signal to each port in order to recognize hardware attached to that port. Some UPS units using serial monitoring implementations respond to the detection signal by turning off. If this happens, use the /NoSerialMice switch in the Boot.ini file to prevent the system from sending this signal to the COM port to which your UPS unit is connected.

You can use multiple /NoSerialMice switches. The format is /NoSerialMice=[COMx | COMx,COMy,COMz,...]

  • If /NoSerialMice is specified without parameters, serial mouse detection is disabled on all the serial ports.
  • If /NoSerialMice=COMx is specified, serial mouse detection is only disabled on COMx.
  • If /NoSerialMice=COMx,COMy,COMz ... is specified, serial mouse detection is disabled on each of the specified ports.

To ensure that the computer is protected from power failures, you can test it by simulating a power failure (that is, by disconnecting the main power supply to the UPS device). Your computer and peripherals connected to the UPS device should remain operational, and messages should be displayed and events logged. Wait until the UPS battery reaches a low level to verify that a graceful shutdown occurs. Restore the main power to the UPS device, and check the event log to ensure that all actions were logged and that there were no errors.

Note

Before you begin any UPS tests, make sure that your UPS has sufficient charge built up to run all of the devices connected to it for at least the duration of the test.


Simulating UPS Operation

The next figure shows a simple simulator that you can build to emulate the power failure and low battery signals from a UPS.

Figure 5.1. UPS simulator

Note

The pins numbers in the diagram are for a 9-pin serial port. For a 25-pin connector, use the pin numbers in parenthesis.

You can use two Single Pole Double Throw (SPDT) switches to construct the UPS simulator. To simulate normal operation, set both switches 1 and 2 to make contact with pin 7 (pin 4 on a 25-pin connector). Set both the Power failure signal and Low battery signal at least 2 minutes before shutdown to Negative in the UPS dialog box.

To simulate a power failure, move switch 1 to make contact with pin 3 (pin 2 on a 25-pin connector). Moving switch 2 to make contact with pin 3 simulates a low battery condition.

Simulating Power Failure and Low Battery Signals

To simulate the operation of a UPS with both a Power Failure and Low Battery signal, have both switches making contact with pin 7. Configure your UPS as shown in this dialog box:

Flip switch 1 to simulate a Power Failure signal. After five seconds, the initial warning message should be displayed. Every 120 seconds, the warning message should be displayed again.

When you know that the Power Failure signal processing is working correctly, flip switch 2. If you have checked the Execute Command File check box and specified a filename, the file should begin execution immediately. If the file does not finish executing within 30 seconds, Windows NT should terminate it. Windows NT should perform an orderly shutdown after the file terminates or immediately after the Power Failure signal if no file is specified.

Simulating UPS With Power Failure Signal Only

To simulate the operation of a UPS with only a Power Failure signal, have both switches making contact with pin 7. For purposes of this test, you can set the values in the UPS Characteristics group box to make it seem that your computer does not have to run very long before the battery is fully charged. When you set the values this way, you have to make sure that your battery does have enough charge to be able to complete the tests. For instance, if you set the values as shown in this dialog box, and let your computer run for 20 minutes, the UPS service assumes that the battery is fully charged.

You can test two scenarios with this configuration:

  • If you connect switch 1 to pin 3 within four minutes of starting the UPS service, the expected battery life is less than two minutes, and Windows NT should begin shutdown immediately.
  • If you allow the computer to run for 20 minutes before you flip switch 1, the battery is assumed to be fully charged. When you flip switch 1, the warning message should be displayed after five seconds. Every 120 seconds, another warning message should be displayed. Shutdown should not begin until the expected battery life decreases to two minutes.


Chapter 6 - Troubleshooting Startup and Disk Problems

This chapter discusses what you can do to find the cause of problems when your computer fails to complete startup. Failure to complete startup means that the computer stops or displays an error message before you can log on to Windows NT. This chapter also discusses causes of and recovery from disk problems.

There are several utilities that you can use to troubleshoot these kinds of problems. The Windows NT Server Resource Kit CD contains a Windows NT-based utility, DiskProbe, that you can use to examine and change information on individual disk sectors. Chapter 7, "Disk, File System, and Backup Utilities," contains more information about DiskProbe and the MS-DOS-based utilities that you can use to read, write, and change information on disk sectors.


Other Sources of Information

There are several other sources of information for troubleshooting startup and disk problems:

  • Chapter 8, "General Troubleshooting," contains details about Microsoft's sources for troubleshooting information and contains more details about troubleshooting hardware, software, and startup problems.
  • The Windows NT Workstation Resource Guide contains several chapters that have troubleshooting information. These chapters are not included in the Windows NT Server Resource Guide:
    • Chapter 23, "Overview of the Windows NT Registry," describes how to use information in the Registry for troubleshooting and configuration maintenance.
    • Chapter 25, "Configuration Management and the Registry," provides problem solving techniques using the Registry.
    • Chapter 39, "Windows NT Debugger," describes the different kinds of Kernel STOP errors that you might see during startup. It also contains information about using the Windows NT Debugger.
  • Appendix A, "Windows NT Setup Troubleshooting" in the Windows NT Server Concepts and Planning book, contains troubleshooting information, including answers to commonly asked questions.
  • Windows NT online help contains a troubleshooting topic.
  • The Microsoft Knowledge Base contains support information developed by Microsoft Product Support Specialists. The Windows NT Knowledge Base is included on the Windows NT Server Resource Kit CD. It is also included on the:
    • Microsoft Developer Network (MSDN) CD
    • TechNet CD
    • Microsoft Internet FTP host, ftp.microsoft.com
    • Technical Support and Services category on the Web page at http://www.microsoft.com/server


Troubleshooting Startup Problems on x86-based Computers

There are several things that can prevent a computer from successfully completing startup. The first step in figuring out what may be causing a problem is to determine whether the problem is occurring before the operating system takes control. If you do not see the boot loader screen on an x86-based computer, the problem may be due to a hardware failure, the Master Boot Record, Partition Tables, or Partition Boot Sector, which might be damaged.

There are several ways such damage can happen, including viruses. On x86-based computers, viruses use BIOS INT (interrupt) 13 calls to install themselves, so they are operating-system independent. Windows NT traps BIOS INT 13 calls while it is running, but cannot protect itself when the computer is started from an MS-DOS floppy disk or is dual-booted by using MS-DOS.

The Knowledge Base contains several articles about protecting your computer from viruses and recovering from problems with viruses. The sections "Protecting Against Viruses and Trojan Horses," in Chapter 4, and "Managing Shared Resources and Resource Security" in the Windows NT Server Concepts and Planning book contains information about reducing the chances that viruses will infect your computer.

If a problem occurs after selecting Windows NT from the boot loader screen, files that are needed by the operating system might be missing or corrupt.

If you have installed new hardware or new drivers, they could be causing the problem.


Problem Occurs Before the Boot Loader Starts

This section describes the problems that might occur between the time you turn your computer on until you see the boot loader screen.

Symptoms of problems in this group are:

  • The computer hangs immediately after the Power On Self Test (POST).
  • You do not see the boot loader screen.
  • You receive messages such as:
    • Missing operating system.
    • A disk read error occurred.
    • Insert a system diskette and restart the system.
    • Invalid partition table.
    • Hard Disk Error.
    • Hard Disk Absent/Failed.

It is possible that you will not be able to start your computer to troubleshoot the problem. If all of your primary partitions are NTFS, using MS-DOS-based utilities will not do much good. If you have created a Windows NT startup floppy disk, as described in Chapter 5, "Preparing for and Performing Recovery," you can try using that disk. If you cannot start the computer by using your Windows NT startup floppy disk, and repairing your system by using the Emergency Repair Disk does not fix the problem, you can try removing it from the computer and installing it as a second disk on another Windows NT computer. You can then use Windows NT-based utilities for troubleshooting.

Caution Moving disks between computers is not supported because of problems that can arise when the disk controllers on the two systems are incompatible or are configured differently. However, if your two computers are configured the same, you might be able to identify and correct the problem.

The problem could be one of the following:

  • There is no system partition on the first hard disk.
  • The Master Boot Record is corrupt.
  • The Partition Boot Sector is corrupt.
  • The Boot.ini file is missing.
  • The Windows NT boot loader, NTLDR, is missing or corrupt.
  • The Complementary Metal Oxide Semiconductor (CMOS) is corrupt, or the CMOS battery is run down.
  • Hardware has malfunctioned.

Troubleshooting System Partition Problems

When you startup from the hard disk on x86-based computers, the system BIOS code identifies the boot disk (usually disk 0), and reads the Master Boot Record. The code in the Master Boot Record searches for a system partition on the hard disk. If it cannot find such a system partition, or cannot start Windows NT from it, the startup process stops. If you get an error message such as "Error loading operating system," then the Master Boot Record code found a system partition, but could not start the operating system.

It is possible that there is no system partition on the hard disk from which you want to startup the computer. You might also have the wrong partition identified as the system partition. You can use the MS-DOS-based utility Fdisk to look at the partition information. For information about other utilities that have similar functionality, see Chapter 7, "Disk, File System, and Backup Utilities."

Note

The system partition is the primary partition on the boot disk (usually disk 0) that has the Boot Indicator field set to 0x80. It contains the files that are needed to load Windows NT, such as Boot.ini and NTLDR.

Fdisk refers to the system partition as the active partition.

Using Fdisk to check for and set the system partition

1. Start MS-DOS, or start from an MS-DOS startup floppy disk that contains the Fdisk utility and type fdisk.

Fdisk displays the following message if there is no system partition on your first hard disk:

WARNING! No partitions are set active - disk 1 is not startable unless a partition is set active.

2. The FDISK Options screen has several choices. The cursor will be on Enter choice. Type 2 (Set Active partition). Fdisk displays information about the partitions on the hard disk. One partition should have an A in the Status column, which indicates it is the (active) system partition.

3. If there is no system partition, or the wrong partition is set as the system partition, enter the number of the partition that contains the files to use when loading the operating system. Fdisk displays the message Partition X made active, where X is the partition number you entered.

4. Press Esc to return to the FDISK Options menu, and press Esc again to exit Fdisk. You can now restart the computer. Be sure to remove the floppy disk.

Not all computers should be set to start from the first primary partition. For example, you can configure multiple partitions and install different operating systems on each partition. Some computers have EISA configuration partitions, and normally start from the second physical partition. For example, many Compaq computers are configured this way. However, the system partition should always be on your first physical hard disk.

Troubleshooting Master Boot Record Problems

This section describes troubleshooting Master Boot Record problems. The section titled "Master Boot Record," within Chapter 3, "Disk Management Basics," contains details about the Master Boot Record.

The functions of the Master Boot Record code are to:

  • Read the Partition Table entries in the same sector.
  • Determine the location of the Partition Boot Sector.
  • Load and execute the code in the Partition Boot Sector.

If the executable code in the Master Boot Record does not do these functions, it displays one of these error messages:

  • Missing operating system.
  • Invalid partition table.

Note

There is a Master Boot Record on each hard disk. However, only the Master Boot Record on the first hard disk is used in starting Windows NT.

Use DiskProbe or an MS-DOS-based utility to display the Master Boot Record. The example here shows what you should see at Cylinder 0, Side 0, Sector 1, which is the location for the Master Boot Record. This example shows the executable code in a Master Boot Record. This example might not match the code in the Master Boot Record on your computer, because some third-party boot and disk partitioning utilities modify the code in the Master Boot Record.

Physical Sector: Cyl 0, Side 0, Sector 1 00000000: 00 33 C0 8E D0 BC 00 7C - 8B F4 50 07 50 1F FB FC .3.....|..P.P.. 00000010: BF 00 06 B9 00 01 F2 A5 - EA 1D 06 00 00 BE BE 07 ................ 00000020: B3 04 80 3C 80 74 0E 80 - 3C 00 75 1C 83 C6 10 FE ...<.t..<.u..... 00000030: CB 75 EF CD 18 8B 14 8B - 4C 02 8B EE 83 C6 10 FE .u......L....... 00000040: CB 74 1A 80 3C 00 74 F4 - BE 8B 06 AC 3C 00 74 0B .t..<.t.....<.t. 00000050: 56 BB 07 00 B4 0E CD 10 - 5E EB F0 EB FE BF 05 00 V.......^....... 00000060: BB 00 7C B8 01 02 57 CD - 13 5F 73 0C 33 C0 CD 13 ..|...W.._s.3... 00000070: 4F 75 ED BE A3 06 EB D3 - BE C2 06 BF FE 7D 81 3D Ou...........}.= 00000080: 55 AA 75 C7 8B F5 EA 00 - 7C 00 00 49 6E 76 61 6C U.u.....|..Inval 00000090: 69 64 20 70 61 72 74 69 - 74 69 6F 6E 20 74 61 62 id partition tab 000000A0: 6C 65 00 45 72 72 6F 72 - 20 6C 6F 61 64 69 6E 67 le.Error loading 000000B0: 20 6F 70 65 72 61 74 69 - 6E 67 20 73 79 73 74 65 operating syste 000000C0: 6D 00 4D 69 73 73 69 6E - 67 20 6F 70 65 72 61 74 m.Missing operat 000000D0: 69 6E 67 20 73 79 73 74 - 65 6D 00 00 80 45 14 15 ing system...E.. 000000E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 000000F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000100: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000110: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000120: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000130: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000140: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000150: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000160: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000170: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000180: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 00000190: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 000001A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 000001B0: 00 00 00 00 00 00 00 00 - FD 4E F2 14 00 00 80 01 .........N...... 000001C0: 01 00 06 0F 7F 96 3F 00 - 00 00 51 42 06 00 00 00 .....?...QB.... 000001D0: 41 97 07 0F FF 2C 90 42 - 06 00 A0 3E 06 00 00 00 A....,.B...>.... 000001E0: C1 2D 05 0F FF 92 30 81 - 0C 00 A0 91 01 00 00 00 .-....0......... 000001F0: C1 93 01 0F FF A6 D0 12 - 0E 00 C0 4E 00 00 55 AA ...........N..U.

There are two things that you can check in the Master Boot Record:

  • The error message text should be as shown in the example.
  • There should be only zeroes between the text Missing operating system and location hex 1B8.

A disk signature might or might not be present starting at location 1B8. Having no disk signature does not necessarily indicate a problem.

Using DiskProbe to display the Master Boot Record

1. Click the DiskProbe icon in the Resource Kit folder.

2. On the Drives menu, click Physical Drive. The Available Physical Drives are listed as PhysicalDrivex, where x=0 for the first hard disk. Double click the disk that contains the Master Boot Record used to start the computer. In the case of an x86-based computer, this disk is usually PhysicalDrive0.

3. In the Handle 0 group box, click Set Active. Click OK.

4. On the Sectors menu, click Read. Set Starting Sector to 0 and Number of Sectors to 1. Click Read.

Troubleshooting Partition Boot Sector Problems

Several known viruses can cause problems with the Partition Boot Sector, even if the volume is formatted with the NTFS file system. Infection can occur by running an MS-DOS-based program from either a floppy disk or by starting up MS-DOS on a dual-boot computer. Most viruses use BIOS INT 13 calls to transfer themselves to an absolute sector on the disk. Windows NT cannot protect itself from this type of infection when it is not running.

In some cases, the damage to the Partition Boot Sector can cause the computer to stop after displaying a blue screen with the message STOP 0x0000007B INACCESSIBLE_BOOT_DEVICE. Another symptom of a Partition Boot Sector problem is that the computer stops before displaying any messages, and the screen remains black.

Using DiskProbe to display the Partition Boot Sector

1. Use the DiskProbe procedure in "Troubleshooting Master Boot Record Problems," presented earlier in this chapter, to read the Master Boot Record, which contains the Partition Table.

2. On the View menu, click Partition table. In the Partition table index list box, double click the partition number whose Partition Boot Sector you want to read.

3. Click the Go button next to Relative Sector.

4. On the View menu, click Bytes to see a display of the Partition Boot Sector in hex. Otherwise, click NTFS BootSector or FAT BootSector to see a formatted display of the information.

Because the Partition Boot Sector contains several fields that are computer-specific, every byte in your Partition Boot Sector will not be identical to the information shown in the examples here. The following information should be the same:

  • The first three bytes should be the jump instruction.
  • The next 11 bytes should be the OEM header string.
  • There should be error message text toward the end of the sector.

These examples show portions of the Partition Boot Sector that should be the same or contain similar text on all computers. The first example is for a FAT volume, the second one is for an NTFS volume formatted when running Windows NT 3.51, and the third one is for an NTFS volume formatted when running Windows NT 4.0.

00000000: EB 3C 90 4D 53 44 4F 53 - 35 2E 30 00 02 08 01 00 .<.MSDOS5.0..... 00000180: 90 A2 07 02 F8 CB 42 4F - 4F 54 3A 20 43 6F 75 6C ......BOOT: Coul 00000190: 64 6E 27 74 20 66 69 6E - 64 20 4E 54 4C 44 52 0D dn't find NTLDR. 000001A0: 0A 00 42 4F 4F 54 3A 20 - 49 2F 4F 20 65 72 72 6F ..BOOT: I/O erro 000001B0: 72 20 72 65 61 64 69 6E - 67 20 64 69 73 6B 0D 0A r reading disk.. 000001C0: 00 50 6C 65 61 73 65 20 - 69 6E 73 65 72 74 20 61 .Please insert a 000001D0: 6E 6F 74 68 65 72 20 64 - 69 73 6B 00 4E 54 4C 44 nother disk.NTLD 000001E0: 52 20 20 20 20 20 20 00 - 00 00 00 00 00 00 00 00 R ......... 000001F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 55 AA ..............U. 00000000: EB 5B 00 4E 54 46 53 20 - 20 20 20 00 02 01 00 00 .[.NTFS ..... 00000130: F2 C3 1D 00 41 20 64 69 - 73 6B 20 72 65 61 64 20 ....A disk read 00000140: 65 72 72 6F 72 20 6F 63 - 63 75 72 72 65 64 2E 0D error occurred.. 00000150: 0A 00 29 00 41 20 6B 65 - 72 6E 65 6C 20 66 69 6C ..).A kernel fil 00000160: 65 20 69 73 20 6D 69 73 - 73 69 6E 67 20 66 72 6F e is missing fro 00000170: 6D 20 74 68 65 20 64 69 - 73 6B 2E 0D 0A 00 25 00 m the disk....%. 00000180: 41 20 6B 65 72 6E 65 6C - 20 66 69 6C 65 20 69 73 A kernel file is 00000190: 20 74 6F 6F 20 64 69 73 - 63 6F 6E 74 69 67 75 6F too discontiguo 000001A0: 75 73 2E 0D 0A 00 33 00 - 49 6E 73 65 72 74 20 61 us....3.Insert a 000001B0: 20 73 79 73 74 65 6D 20 - 64 69 73 6B 65 74 74 65 system diskette 000001C0: 20 61 6E 64 20 72 65 73 - 74 61 72 74 0D 0A 74 68 and restart..th 000001D0: 65 20 73 79 73 74 65 6D - 2E 0D 0A 00 00 00 00 00 e system........ 000001E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ 000001F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 55 AA ..............U. 00000000: EB 5B 90 4E 54 46 53 20 - 20 20 20 00 02 01 00 00 .[.NTFS ..... 00000130: 07 00 CD 10 EB F2 C3 1D - 00 41 20 64 69 73 6B 20 .........A disk 00000140: 72 65 61 64 20 65 72 72 - 6F 72 20 6F 63 63 75 72 read error occur 00000150: 72 65 64 2E 0D 0A 00 29 - 00 41 20 6B 65 72 6E 65 red....).A kerne 00000160: 6C 20 66 69 6C 65 20 69 - 73 20 6D 69 73 73 69 6E l file is missin 00000170: 67 20 66 72 6F 6D 20 74 - 68 65 20 64 69 73 6B 2E g from the disk. 00000180: 0D 0A 00 25 00 41 20 6B - 65 72 6E 65 6C 20 66 69 ...%.A kernel fi 00000190: 6C 65 20 69 73 20 74 6F - 6F 20 64 69 73 63 6F 6E le is too discon 000001A0: 74 69 67 75 6F 75 73 2E - 0D 0A 00 33 00 49 6E 73 tiguous....3.Ins 000001B0: 65 72 74 20 61 20 73 79 - 73 74 65 6D 20 64 69 73 ert a system dis 000001C0: 6B 65 74 74 65 20 61 6E - 64 20 72 65 73 74 61 72 kette and restar 000001D0: 74 0D 0A 74 68 65 20 73 - 79 73 74 65 6D 2E 0D 0A t..the system... 000001E0: 00 17 00 5C 4E 54 4C 44 - 52 20 69 73 20 63 6F 6D ...\NTLDR is com 000001F0: 70 72 65 73 73 65 64 2E - 0D 0A 00 00 00 00 55 AA pressed.......U.

Although other corruption problems are possible, if any of the strings are incorrect or missing, you should assume the sector is corrupt.

Even if there is no obvious damage, the Partition Boot Sector might not be working correctly. One way to check for this problem is to change the name of NTLDR to anything else and restart Windows NT from the hard disk.

You should see this error message on a FAT primary partition:

Couldn't find NTLDR.

You should see this error message on an NTFS primary partition:

A kernel file is missing from the disk.

These errors indicate that the Partition Boot Sector is okay and that the problem is with a corrupt NTLDR file. In this case, see "Replacing Windows NT Files on the System Partition" within Chapter 5, "Preparing For and Performing Recovery," for information about replacing NTLDR.

If you don't get this error message, then the problem is probably a corrupt Partition Boot Sector. To replace the sector, see "Replacing the Partition Boot Sector," within Chapter 5, "Preparing for and Performing Recovery." Be sure to change the name back to NTLDR so that the Partition Boot Sector can find it again.

NTLDR usually has the Hidden, System, and Read Only attributes set. Because you cannot start Windows NT when the Partition Boot Sector on the boot partition is corrupt, you can start the MS-DOS operating system from the MS-DOS startup floppy disk to change the attributes. To change the attributes by using the MS-DOS attribute command, enter:

attrib -s -h -r ntldr

CMOS Problems

The CMOS typically stores information about the following:

  • Time and date
  • Floppy disks
  • Video type
  • Hard disks
  • Memory installed

Each manufacturer and BIOS vendor can decide what a user should be able to configure, and what the standard configuration is. You can access the CMOS through either a utility or a keyboard sequence, depending on the manufacturer. You should write down or use a utility to print all of the CMOS information.

The computer uses the CMOS checksum to determine if any CMOS values have been changed other than by using the CMOS Setup program. If the checksum is not correct, the computer will not start.

Once the CMOS is correctly configured, CMOS problems are usually caused by one of the following:

  • A weak battery, which can happen if the computer has not been powered on for a long time.
  • The connection between the CMOS and the battery is loose or faulty.
  • The CMOS has been damaged from static electric discharge.

All of these problems can result in information in the CMOS being set to zero or otherwise corrupt, this halting the startup.

Hardware Problems

If a device fails to initialize during POST, there can be a problem with accessing it. If you have changed or added a device since the last startup, the problem might be with the new configuration.

If you have changed your disk configuration, you should check that:

  • SCSI devices are terminated properly.
  • The BIOS is enabled on only the first SCSI controller (if at all). See "Understanding ARC Pathnames" within Chapter 5, "Preparing For and Performing Recovery," for information about whether the controller BIOS should be enabled.
  • There are no IRQ conflicts.

If you have not made any changes, check that

  • Controller cards are seated properly.
  • Cables are properly connected.
  • Disks are all powered up.

Chapter 8, "General Troubleshooting," discusses hardware problems. The Knowledge Base also contains information about troubleshooting these kinds of problems.


Problem Occurs After the Boot Loader Starts

This section describes troubleshooting problems that might occur from the time NTLDR starts executing through the time that you successfully log onto Windows NT. This phase of startup begins when you see the following message:

NTDETECT V1.0 Checking Hardware . . .

Using Checked Version of NTDETECT

On x86-based computers, NTDETECT detects installed hardware components.

There is a debug version of Ntdetect.com on the Windows NT Server product CD, called Ntdetect.chk. If Ntdetect.com fails to detect all of the hardware that you think it should find, you can use the debug version to help isolate the problem. A mouse or a disk controller are the components that typically causes problems.

To use the checked version:

  • Rename Ntdetect.com to Ntdetect.bak in the root folder of your system partition.
  • Copy Ntdetect.chk from Support\Debug\I386 to the root folder.
  • Rename Ntdetect.chk to Ntdetect.com.

The utility Installed on the Windows NT Server Resource Kit CD performs the same functions.

Ntdetect.com has attributes of Hidden, System, and Read Only set when you install Windows NT. You need to clear these attributes to make the file visible. You can change the attributes by using My Computer, Windows NT Explorer, or the command prompt.

To change file attributes by using My Computer or Windows NT Explorer
  1. On the View menu, click Options.
  2. On the View tab, select Show all files. Click OK.
  3. Click the filename NTLDR at the root of the C drive.
  4. On the File menu, click Properties.
  5. In the Attributes box of the General tab, clear the Read Only and Hidden check boxes, and then click OK.

To change the attributes by using the command prompt, enter:

attrib -s -h -r ntldr

Shutdown Windows NT and restart the computer. When Ntdetect.chk executes, it displays information on the screen as it detects the hardware. This is a sample of the kind of information you might see:

Detecting System Component . . . Reading BIOS date . . . Done reading BIOS date (1/20/1994) Detecting Bus/Adapter Component . . . Collecting Disk Geometry . . . Detecting Keyboard Component . . .

After it finishes displaying information about the components, press ENTER so Ntdetect.chk will continue. Ntdetect.chk next displays information about the current nodes for the controllers and peripherals. You need to press ENTER at the end of each screen of information.

When you have finished using Ntdetect.chk, you should rename Ntdetect.com to Ntdetect.chk and rename Ntdetect.bak to Ntdetect.com.

Using the /maxmem Switch

For x86-based computers, the Boot.ini file has a /maxmem switch that enables you to specify the maximum amount of RAM memory that Windows NT can use. You can use this switch to troubleshoot memory parity errors, mismatched SIMM speeds, and other memory-related problems. To use this switch, the memory must be contiguous. You should never specify a value less than 12 for Windows NT Server.

Note

Windows NT Server can run with 12 MB RAM, although it will probably run quite slowly.

You include this switch at the end of the ARC path specified in the [operating systems] section of the Boot.ini file. This example restricts Windows NT Server to using only the first 12 MB RAM.

multi(0)disk(0)rdisk(0)partition(1)\winnt=Windows NT Server 4.0 /MAXMEM=12

Chapter 8, "General Troubleshooting," contains more information about troubleshooting memory problems.

Using the /sos Switch

You can add the /sos switch to the Boot.ini file to have NTLDR display the Kernel and driver names while they are being loaded. Use this switch if Windows NT does not startup and you think a driver is missing or corrupted. See the section "Boot.ini Switches" within Chapter 3, "Disk Management Basics," for information about changing Boot.ini switches.

These examples assume that you have installed Windows NT Server in the folder winnt40 on partition 2.

First, you should see this message:

multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\ntoskrnl.exe

And then this one:

Press spacebar now to invoke Hardware Profile/Last Known Good Menu

Regardless of whether you press the spacebar, you should see these two messages:

multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\hal.dll multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\config.sys

The Hardware Profile/Last Known Good menu displays at this time if you pressed the spacebar or you have more than one hardware profile. After NTLDR finishes processing the hardware profile information, it clears the screen and displays information such as:

multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\c_1252.nls multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\c_437.nls multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\n_intl.nls multi(0)disk(0)rdisk(0)partition(2)\winnt40\FONTS\vgaoem.fon multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\Drivers\Atdisk.sys multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\Disk.sys multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\CLASS2.SYS multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\Diskperf.sys multi(0)disk(0)rdisk(0)partition(2)\winnt40\System32\Ntfs.sys

Fatal System Error: 0x0000006B

In some cases on ESDI disks with more than 1024 cylinders, Windows NT Server appears to have been successfully installed. However, the first time that you attempt to start from the hard disk, NTLDR loads various files and then produces a Fatal System Error: 0x0000006b with the message that Phase 1 Process Initialization failed. Following this message is a hexadecimal dump and system lockup. If you experience this problem, read the section "ESDI Hard Disk" within Chapter 3, "Disk Management Basics," for information about the ESDI controllers that Microsoft has tested.

Stop 0x0000007B — Inaccessible Boot Device

This STOP message means that Windows NT is unable to access the Partition Boot Sector or the required information is not found. A common cause of this error is a virus.

Another cause of the problem is incompatible Logical Block Addressing (LBA). The system BIOS is designed to allow access to fixed disks that use fewer than 1024 cylinders. Many modern disks, however, exceed 1024 cylinders. LBA is used to provide support for these disks. Such support is often built into the system BIOS. However, there are potential problems with LBA:

  • If partitions were created and formatted with LBA disabled, and LBA is subsequently enabled, a STOP 0x0000007B can result. The partitions must be created and formatted while the LBA is enabled. In addition, changing LBA modes from one scheme to another can cause you to have to recreate the partitions and reformat the disk.
  • Some LBA schemes are not compatible with Windows NT. When in doubt, it is best to check with your vendor.

A corrupt Partition Boot Sector can also cause this STOP message, depending upon what part is corrupt. This problem is similar to a virus, except that the corruption is caused by such things as a defective disk or controller, or a bug in a program that somehow has corrupted the Partition Boot Sector.


Troubleshooting Startup Problems on RISC-based Computers

RISC-based computers generally have fewer problems at startup than x86-based computers. This is because they usually do not have problems with viruses destroying the Master Boot Record or the Partition Boot Sector. They also do not have problems with the disk configuration information in the computer not matching what the controller is using.

The startup problems common to RISC-based computers are:

  • Missing or incorrect file(s). This problem is usually the result of a user deleting, moving, or renaming a file that is needed for startup. It is also possible that a device driver is not the correct version for the device.
  • Incorrect firmware. Upgrading to a new version of Windows NT typically requires upgrading the firmware. The firmware upgrades are available through your RISC-based computer vendor.

On RISC-based computers, you can use the /sos switch to display the Kernel and device driver names while they are being loaded. Include this switch on the OSLOADOPTIONS variable in the firmware. See the section "Using the /sos Switch," presented earlier in this chapter, for a description of the output you see when using this switch. There is information about editing the firmware variables in the section titled "Manage Boot Selection Menu," within Chapter 19, "What Happens When You Start Your Computer," in the Windows NT Workstation Resource Guide.

Troubleshooting problems with RISC-based computers can be more difficult than troubleshooting problems with x86-based computers because there are few disk or hardware troubleshooting tools available outside of Windows NT. If you can startup Windows NT, which you might be able to do by using your Windows NT startup floppy disk, try using these utilities:

  • The Windows NT Diagnostics in the Administrative Tools program group, which enables you to look at hardware information.
  • The DiskProbe utility on the Windows NT Server Resource Kit CD, which is a low-level disk editor that enables you to examine and change individual disk sectors.

On RISC-based computers, there are no recovery tools such as those available when you dual-boot MS-DOS on x86-based computers. If your startup problem is because of a problem with information on the hard disk, you might have to remove the disk from the RISC-based computer and install it as a second disk on an x86-based computer to troubleshoot the problem. When you use this approach, you can use a low-level disk editor to examine the information on the disk in the same way you would troubleshoot a problem with a disk on an x86-based computer. Although these kinds of problems do not occur very often, you might have to use this approach after a power failure or system crash.

Note

On NTFS volumes, you need to use Windows NT-based utilities, such as DiskProbe, to examine information on the volume.


Troubleshooting Startup Problems Common to Both x86-based and RISC-based Computers

When starting your computer, Windows NT provides options for using alternative configurations. If you have changed hardware or device drivers since the last startup and Windows NT does not complete startup, try using one of the other options.


Troubleshooting by Using the Last Known Good Configuration

Windows NT provides two configurations in which you can start your computer:

  • Default, the configuration that was saved when you shutdown the computer.
  • Last Known Good, the configuration that was saved when you last logged on to your computer.

The configurations are stored as control sets in the Registry key HKEY_LOCAL_MACHINE\SYSTEM. If you made changes to your configuration when you were last logged on, such as adding drivers, changing services, or changing hardware, the two control sets will contain different information. As soon as you log on however, the information in these control sets will be the same. Therefore, if you are having problems with startup, and think the problems might be related to changes in your configuration, do not log on. Instead, shutdown the computer and restart it. Then, select Last Known Good from the Hardware Profile/Last Known Good menu to recover from the following types of problems:

  • You install a new device driver, restart Windows NT, and the system stops responding. The Last Known Good control set enables you to startup because it does not contain any reference to the new, faulty driver.
  • You install a new video driver and are able to start the system. However, you cannot see anything, because the new video resolution is incompatible with your video adapter. Do not try to log on. If you have the option to shutdown the computer without logging on, do so. If that option is not available, you need to restart your computer by turning it off or using the reset button. Wait for all disk activity to stop before you initiate the restart, especially if the computer has FAT volumes.
  • You accidentally disable a critical device driver (such as the Scsiport driver). Windows NT is not be able to start and automatically reverts to the Last Known Good control set.

Using the Last Known Good control set does not help in the following situations:

  • Any problem that is not related to changes in control set information, such as information like user profiles and file permissions.
  • After you logged on after making changes. Here, the Last Known Good control set has already been updated to include the changes.
  • Switching between different hardware profiles, such as docked and undocked laptops. The Last Known Good control set is only a method to switch between configuration information in the Registry. Use Hardware Profiles for this.
  • Startup failures caused by hardware failures or corrupted files.
  • Copying a new driver over the top of an old one, and the old one is already active.

Chapter 8, "General Troubleshooting," contains more details about troubleshooting by using the Registry key HKEY_LOCAL_MACHINE. For more information about hardware profiles and control sets, see Chapter 19, "What Happens When You Startup Your Computer," in the Windows NT Workstation Resource Guide.


Troubleshooting Video Problems

If your screen stays black or is skewed after a restart, either the video device is not resetting correctly during the restart or the video is sharing an IRQ.

Turn the power off and restart the computer. If the video works, you will probably need to turn the power off each time you restart Windows NT. This problem is video-and system-BIOS related.

If the video is still wrong after turning the power off and restarting, check for IRQ and memory conflicts with other cards on your system. If you are using a PCI-based computer, make certain that the video is not using IRQs 2, 9, or 12.

If you have installed a new video driver, or changed the display type by using the Display option in Control Panel, you might have created an incompatibility between the driver and the video device. One way that you can tell you have a problem is if you get a black screen instead of the logon message when you restart Windows NT.

You can turn off your computer or use the reset button to restart your computer. Then select the Last Known Good configuration. This recovery method is described in "Troubleshooting by Using the Last Known Good Configuration," presented earlier in this chapter.

On x86-based computers, you have another way to recover. When you install Windows NT, it creates two paths to the Windows NT folder, such as:

scsi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Version 4.00" scsi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Server Version 4.00 [VGA mode]" /basevideo

If you select the path with the VGA mode option, Windows NT starts up by using the standard VGA driver. You can then use the Display option to reconfigure your video device.

Note

Windows NT Server version 4.0 requires new video and printer drivers. Windows NT Server version 3.51 drivers for these devices will not work correctly when you are running Windows NT version 4.0.


Troubleshooting Disk Problems That Occur After Logon

This section discusses problems that occur after you have successfully logged on.


Volume is Displayed as Unknown

If you have created and formatted a volume with NTFS or FAT, but you can no longer access files on it, and Disk Administrator displays the volume as Unknown, the Partition Boot Sector for the volume might be bad.

  • For NTFS volumes, there are two other possible causes for this error:
  • Permissions for the volume have been changed.
  • The Master File Table (MFT) is corrupt.

The Partition Boot Sector can be corrupted by viruses. Corruption problems can also occur if you have a dual-boot configuration with Windows 95 and you use the Windows 95 version of Fdisk. To avoid problems with Fdisk, delete the Windows 95 version, make sure that you have the MS-DOS-based version, and run Fdisk only when you start MS-DOS.

To determine if a corrupt Partition Boot Sector is causing the problem, and for the description of the procedures to restore it, see "Replacing the Partition Boot Sector" within Chapter 5, "Preparing for and Performing Recovery."

The permission problem occurs when you have done all the following:

  • Created a second volume.
  • Removed the group Everyone from the Access Control List (ACL).
  • Granted access to a specific user.

The single user has normal access, but when other users log on, or if Windows NT is reinstalled, Disk Administrator sees the drive as unknown.

To correct this problem, log on as an administrator and take ownership of all folders, or add the group Everyone back with full control (default).

If there is corruption in the MFT file, there is no general solution. If you suspect this kind of problem, you should contact your technical support personnel for assistance.


Extended Partition Problems

If a Partition Table that defines a logical drive within an extended partition becomes corrupt, Windows NT can no longer access that volume, or the volumes that follow it on the disk. Once the pointer to the next volume has been lost, Windows NT can no longer find out where the volumes start.

When an extended partition becomes corrupt, it might be possible to rebuild it by using a sector editor or partition table editor.

For information about the organization of extended partitions, see "Logical Drives and Extended Partitions" within Chapter 3, "Disk Management Basics." For information about ways to attempt to repair the extended partition, see the description of the DiskProbe utility within Chapter 7, "Disk, File System, and Backup Utilities."


Chapter 7 - Disk, File System, and Backup Utilities

This chapter explains various disk utilities, file system utilities, and backup utilities and how to use them. It shows where to obtain the utilities and other sources of related information.

Other chapters in this part of the Windows NT Server Resource Guide also identify situations in which you should use the utilities (described in this chapter) and contain more information about them:

  • Chapter 3, "Disk Management Basics."
  • Chapter 5, "Preparing for and Performing Recovery."
  • Chapter 6, "Troubleshooting Startup and Disk Problems."

The utilities described in this chapter are available from different sources.

The following utilities are on the Windows NT Server product CD. When you install Windows NT, they are installed in %systemroot%\System32. You must run all of these utilities from the command prompt. The Section column in the next table identifies the section in this chapter in which the utility is described.

Utility | Purpose | Section
AT | Run Windows NT backup at scheduled time. | Backup
Cacls | Display and modify Access Control Lists (ACLs) for NTFS files and folders. | File System
Compact | Display and change compression of NTFS files and folders. | File System
Convert | Convert volume from FAT to NTFS. | File System
Expand | Expand files that are compressed on the Windows NT Server product CD, the Windows NT Server Resource Kit CD, or that you compressed by using the Compress utility. | File System

The rest of the utilities described in this chapter are on the Windows NT Server Resource Kit CD. You can install the Resource Kit by double-clicking Setup.exe when you load the Resource Kit CD.

The Windows NT Resource Kit utilities are organized into subgroups, by functional area. Rktools.hlp contains information about each of the utilities on the resource kit. To find out which functional area contains which utilities, double-click Rktools.hlp and double-click each Tools group on the Contents screen.

When you install the Windows NT Resource Kit, Setup creates a Resource Kit program group that has Rktools.hlp and Readme.txt in it. It also creates a program group within the Resource Kit program group for each subgroup that you install. You can install only those subgroups that you want by doing a custom install.

To do a custom installation of the Resource Kit

1. Double-click Setup.exe at the root of the Windows NT Server Resource Kit CD.

2. Click the Custom button.

3. Check the group(s) that contains the utilities you want to install.

The following table contains information about each of the Resource Kit utilities described in this chapter. As in the previous table, the Section column identifies the section in this chapter in which the tool is described.

Utility | Type | Purpose | Subgroup | Section
Compress | Command prompt | Compress files and folders. | File | File System
DirUse | Command prompt | Display folder size information, including compression information for NTFS volumes. | File | File System
DiskMap | Command prompt | Display information about the disk and the contents of the Partition Table. | Disk/Fault Tolerance | Disk
DiskProbe | Windows NT-based | Low-level disk editor. | Disk/Fault Tolerance | Disk
DiskSave | MS-DOS-based | Save and restore Master Boot Record and Partition Boot Sector. | Disk/Fault Tolerance | Disk
Expndw32 | Windows NT-based | Expand compressed files. | File | File System
FTEdit | Windows NT-based | Recover stripe sets, stripe sets with parity, and volume sets. | Disk/Fault Tolerance | Disk


Disk Utilities

DiskProbe, DiskSave, and FTEdit are low-level editors. When you use them, you are changing information on the disk without any checks as to whether the changes make sense. Each utility does display messages asking you to verify that you really want to change the information. However, you can easily make changes that have serious consequences, such as:

  • You cannot start any operating system.
  • A volume is no longer accessible.
  • You have to recreate and reformat all of the partitions and logical drives.

Used carefully however, you can solve these same problems when they occur through human error, hardware problems, power outages, and similar events. It is a good idea to get familiar with using these utilities in a test situation before you need to use them for real. Testing is especially important if your configuration has volume sets, stripe sets, extended partitions, or extended volume sets.

DiskMap displays information layout of partitions and logical drives on your disk, and you cannot change information on the disk when using this utility.

Note

You can save and restore Master Boot Records and Partition Boot Sectors by using both DiskProbe and DiskSave. Both utilities save these files in the same format, so they can be saved by using one utility and restored by using the other.


DiskMap - Display a Map of the Disk

This utility produces a report on the configuration of the disk that you specify. It provides information about the disk characteristics and a description for each partition and logical drive on the disk.

DiskMap can be run from the command prompt. The syntax is:

diskmap /d<drive#> [/h]

These are the options for DiskMap

Option | Description
/d<drive#> | Drive# is the physical disk for which you want a map.
/h | Indicates hexadecimal output. The default is decimal output.

Some fields in the DiskMap report are always hex or always decimal, regardless of whether you specify the /h option when you run the utility. These fields are shown in the next table. You can see the fields in the DiskMap sample report, shown later in this section.

Always hex | Always decimal
Signature | The MB portion of the DiskSize field
System ID | Partition number

As an example, Figure 7.1 is a Disk Administrator screen shot of a computer with one hard disk.

Figure 7.1 Disk Administrator screen shot

You get the following report for the disk configuration shown in Figure 7.1 when you enter diskmap /d0 at the command prompt:

Cylinders HeadsPerCylinder SectorsPerHead BytesPerSector MediaType 1023 16 63 512 12 TrackSize = 32256, CylinderSize = 516096, DiskSize = 527966208 (503MB) Signature = 0x14f24efd StartingOffset PartitionLength StartingSector PartitionNumber * 32256 210018816 63 1 210051072 209534976 410256 2 472227840 10321920 922320 3 419618304 10289664 63 4 429940224 8225280 63 5 438197760 12354048 63 6 450584064 16998912 63 7 MBR: Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors * 0 1 1 406 15 63 0x06 63 410193 407 0 1 812 15 63 0x07 410256 409248 813 0 1 914 15 63 0x05 819504 102816 915 0 1 934 15 63 0x01 922320 20160 EBR: (sector 819504) Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors 813 1 1 832 15 63 0x87 63 20097 833 0 1 848 15 63 0x05 20160 16128 0 0 0 0 0 0 0x00 0 0 0 0 0 0 0 0 0x00 0 0 EBR: (sector 839664) Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors 833 1 1 848 15 63 0x01 63 16065 849 0 1 872 15 63 0x05 36288 24192 0 0 0 0 0 0 0x00 0 0 0 0 0 0 0 0 0x00 0 0 EBR: (sector 855792) Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors 849 1 1 872 15 63 0x07 63 24129 873 0 1 905 15 63 0x05 60480 33264 0 0 0 0 0 0 0x00 0 0 0 0 0 0 0 0 0x00 0 0 EBR: (sector 879984) Starting Ending System Relative Total Cylinder Head Sector Cylinder Head Sector ID Sector Sectors 873 1 1 905 15 63 0x87 63 33201 0 0 0 0 0 0 0x00 0 0 0 0 0 0 0 0 0x00 0 0 0 0 0 0 0 0 0x00 0 0

This utility is very useful for producing hardcopy reports for each disk, which should be kept with the other configuration information that you maintain for your computer. You can create a hardcopy by redirecting the output to a printer or to a file, which you can then print. This example creates a file.

diskmap /d0 >disk0map.txt

The first three lines of the output,

Cylinders HeadsPerCylinder SectorsPerHead BytesPerSector MediaType 1023 16 63 512 12 TrackSize = 32256, CylinderSize = 516096, DiskSize = 527966208 (503MB)

are information that DiskMap obtained by using IOCTL_DISK_GET_DRIVE_GEOMETRY. The information is the geometry of the disk as seen by Windows NT. The hardware might have different physical geometry, because translation can be performed either at the hardware or device driver layer. It is important to know what geometry Windows NT is using. You can use this information if you need to repair the Partition Table, which is described in the section entitled "Editing and Repairing the Partition Table," later in this chapter. The TrackSize, CylinderSize, and DiskSize values are bytes.

The second section of the output is information about the disk returned from IOCTL_DISK_GET_DRIVE_LAYOUT. Windows NT uses the signature to correlate information in the HKEY_LOCAL_MACHINE\SYSTEM\DISK Registry key with the appropriate physical disk when the disk contains volume sets or stripe sets. The StartingOffset and PartitionLength fields are the values for each of these data in bytes.

The MBR and EBR sections on the printout describe the contents of the Partition Table(s). The MBR section is for the Partition Table contained on the first sector of the disk. If there is no extended partition on the disk, there are no EBR sections. Otherwise, there is one EBR section for each logical drive in the extended partition. The fields in each of these sections are described in the "Partition Table" section within Chapter 3, "Disk Management Basics."

Each partition that has an asterisk (*) at the left side is a system partition, which contains the files used to load an operating system such as Windows NT. On an x86-based computer, each disk can have a system partition, but there should only be one partition with the * on each disk. RISC-based computers can have more than one system partition on a disk.

The DiskMap utility has several possible error messages. Some messages are not serious, and you can easily correct them. Other messages usually are caused by some type of hardware problem or corruption of the data on the disk. This table describes the error messages that you might see. The N and E in the message indicate numbers.

Message | Meaning
BLOCKED: CreateFile() Failed /dN [Error E] Ensure that you have selected a valid drive number and that the selected drive is not locked by another process. | The attempt to open physical disk N failed. Either some other program, such as Disk Administrator or DiskProbe, has the drive open, or the value following /d is invalid (out of range or not a number).
Unable to get drive layout using IOCTL_DISK_GET_DRIVE_GEOMETRY. Error: [Error E]. This is a fatal error. | The call to DeviceIoControl() with the parameter IOCTL_DISK_GET_DRIVE_ GEOMETRY failed. You would get this error if you removed the disk in a removable media device. Otherwise, it could indicate a hardware failure where a device that was available at startup is no longer available.
Unable to allocate memory | DiskMap tried to allocate memory for a temporary buffer and no memory was available. Try closing other programs.
Unable to get drive layout using IOCTL_DISK_GET_DRIVE_LAYOUT. Error: [Error E]. | The call to DeviceIoControl() with the parameter IOCTL_DISK_GET_DRIVE_LAYOUT failed. In attempting to walk the Partition Table chain, some kind of error was encountered. This error indicates Partition Table corruption, hardware RAID array corruption, hardware failure, or a change in apparent disk geometry that makes portions of the volume inaccessible. More information about why the call failed might be available in other parts of the utility where it walks the chain manually.
Unable to read next EBR. Error: [Error E]. | A call to ReadFile() failed. This is usually caused by an attempt to read past the end of the disk, as in the case where the pointer to the next EBR is not valid. It can also indicate a bad sector at the EBR location.
Next EBR failed to pass sanity check. | This message means that the Ending Head value for each of the four Partition Table entries is not 0 or not equal to TracksPerCylinder-1, or that the last two bytes in the sector are not 0x55 0xAA. The problem is either an error in the chain of EBRs or this sector has been corrupted.
Detected partition corruption. | This message means that the value in the Relative Sector field for a Partition Table entry is not equal to the SectorsPerHead value.

In general, if the partition size and layout displayed by DiskMap looks about right and the utility does not display any error messages, then the Partition Tables are probably correct.

An example of where DiskMap can be very useful is when a Partition Table was written incorrectly and the last EBR referenced is past the end of the disk. Disk Administrator will not initialize in this situation, because it depends on the information from IOCTL_DISK_GET_DRIVE_LAYOUT, which would fail. DiskMap would also display an error about IOCTL_DISK_GET_DRIVE_LAYOUT, but would display the EBRs that it can read up to the point of failure. If you have a hardcopy of a map of the disk that had no errors, you can see where the two chains diverged. You can restore the original partition information by correcting the first EBR that has bad values by using a low-level disk editor such as DiskProbe. Typically, the rest of the original EBRs would not have been damaged by the bad EBR chain. Sometimes, though, it might be necessary to repair more than one EBR.


DiskProbe - a Low-level Disk Editor

This Windows NT-based utility enables you to save, restore, find, examine, and change data on the disk. DiskProbe gives an administrator access to every byte on the physical disk without regard to access privilege, and with it you can change any part of the disk. It is your responsibility to make sure that you have backups of the disk.

After starting DiskProbe, as shown in Figure 7.2, you use the Drives menu to open a physical disk or a logical drive.

Figure 7.2 Opening a disk by using DiskProbe

Clicking Physical Drive on the Drives menu opens the entire physical disk. You can access any sector on the disk. When you read or write sectors, the sector number is the absolute sector from the beginning of the disk.

Clicking Logical Volume on the Drives menu opens the logical drive associated with a drive letter. Sector numbers are relative to the start of the logical drive, and you can only access sectors within the range of the logical drive. You cannot use DiskProbe to access a network drive.

When you have opened either a disk by clicking either Physical Drive or Logical Volume, you can get information about the characteristics of the disk by clicking Volume Information on the Drives menu. You get the same information regardless of how you opened the disk. This information is the same as what you see if you run the DiskMap utility for this disk. You can use this information if you need to repair the Partition Table. Here is an example:

Whenever you use DiskProbe to read a sector, it displays the sector number of the first sector it read in the title bar. It also displays the sector number of the sector you are currently viewing in the status bar. This information is useful if you have read more than one sector.

When you are first using DiskProbe, or are looking at information in an extended partition, it is recommended that you write down the sector number for the start of each partition and logical drive. You should also write down the sector number of the Partition Boot Sector for each partition or logical drive. You can produce a hardcopy of the disk configuration by using the DiskMap utility, which is described earlier in this chapter.

If your disk has volume sets or an extended partition, remembering which primary partition or logical drive you are looking at can become difficult. You can always start over by reading sector 0, which reads the Partition Table for the disk.

Note

In the DiskProbe utility, sectors are numbered starting from zero.

The location of some system information on NTFS volumes is different, depending on which version of Windows NT, was used to format the volume. For example, Windows NT 4.0 writes a backup of the Partition Boot Sector for the volume at the end of the volume. Earlier versions of Windows NT put the backup at the center of the volume.

For more information about DiskProbe, see Dskprobe.hlp and Rktools.hlp on the Windows NT Server Resource Kit CD.

Comparing DiskProbe to Disk Administrator

Although DiskProbe and Disk Administrator both provide you with information about the organization of your hard disks, each utility has additional functionality. Disk Administrator enables you to configure and format your disks. DiskProbe enables you to save and change the data on the disk.

Disk Administrator shows you, for each disk, the size and organization of:

  • Primary partitions
  • Logical drives (single contiguous areas in an extended partition)
  • Stripe sets
  • Volume sets
  • Mirror sets
  • Stripe sets with parity

When displaying information about stripe sets, volume sets, mirror sets, and stripe sets with parity, both DiskProbe and Disk Administrator read the Registry key HKEY_LOCAL_MACHINE\SYSTEM\DISK to determine which disks contain the members of the volumes.

When you view the Partition Table, DiskProbe enables you to determine the starting and ending location of primary partitions, logical drives, and volume sets.

DiskProbe simply displays the information that it finds in each Partition Table, it is up to you to understand how the individual entries in the Partition Table relate to what you have configured on your disks. If your configuration contains extended partitions, you might find it easier to understand the DiskProbe information if you print a screen shot of the Disk Administrator display (by pressing ALT+Print Screen, pasting the screen shot into Paint or a document, and then printing the picture or document). The section "Walking an Extended Partition," presented later in this chapter, contains an example of the Disk Administrator and DiskProbe information for an extended partition.

Note

Because both DiskProbe and Disk Administrator can modify the Partition Table, and DiskProbe enables you to directly modify any sector on a disk, you should never have both of these utilities open at the same time. When you are using DiskProbe, you should also be very cautious about running any other programs. DiskProbe writes directly to the disk without using the file cache, the NTFS log file, or any file system device drivers.

Backing Up and Restoring the Master Boot Record

The Master Boot Record on the hard disk that you use to start your computer is the most important sector on the disk. The Master Boot Record on other disks is not as critical. However, if the partition information in the other Master Boot Records is not correct, you might not be able to access volumes on those disks.

For an example of a Master Boot Record, see Chapter 3, "Disk Management Basics."

To back up the Master Boot Record

1. In the Resource Kit folder, double-click the DiskProbe icon.

2. On the Drives menu, click Physical Drive. You will see the Open Physical Drive dialog box, which is shown in the following figure.

The Available Physical Drives are listed as PhysicalDriven, where n=0 for the first hard disk. Double-click the disk that contains the Master Boot Record you want to save. You should always save the Master Boot Record on the startup disk. In the case of an x86-based computer, the startup disk is usually PhysicalDrive0.

When you have more than one disk, you should back up the Master Boot Record on each disk, since it contains the Partition Table for that disk.

3. In the Handle 0 group box, click Set Active. Click Close.

4. On the Sectors menu, click Read to open the Sector Range dialog box, which is shown in the following figure. Set Starting Sector to 0 and Number of Sectors to 1. Click Read.

Make sure that the sector you read looks like a Master Boot Record, as described within Chapter 3, "Disk Management Basics."

5. On the File menu, click Save As. Enter the filename. Consider saving the file to the Emergency Repair Disk, Windows NT startup floppy disk, or the MS-DOS bootable floppy disk. You can save it on more than one disk. If you have more than one disk whose master Boot Record you are backing up, using a filename such as Mbrdiskn.dsk can help you remember which file corresponds to which disk.

To restore the Master Boot Record

1. In the Resource Kit folder, double-click the DiskProbe icon.

2. On the File menu, click Open. Enter the filename and open the file. Verify that the file looks like a Master Boot Record and that it is 512 bytes. DiskProbe displays a message if the size of the file you open is not a multiple of 512.

3. On the Drives menu, click Physical Drive. The Available Physical Drives are listed as PhysicalDriven, where n=0 for the first hard disk. Double-click the disk that contains the Master Boot Record you want to restore.

4. In the Handle 0 group box, clear the Read Only check box, and click Set Active. Click Close.

5. On the Sectors menu, click Write to open the Write Sector dialog box. Set Starting sector to write data to 0. Click Write it.

DiskProbe displays a message box so you can verify the information.

Displaying and Using the Partition Table

The Master Boot Record is the first sector on each hard disk. The first step in troubleshooting Partition Table problems should be to read the Master Boot Record and look at the Partition Table. The description in this section applies to viewing the Partition Table in the Master Boot Record. See "Walking an Extended Partition," presented later in this chapter, for information about finding the Partition Table for an extended partition.

To display the Partition Table

1. Read the Master Boot Record by using steps 1 through 4 in the procedure for backing up the Master Boot Record, given earlier in this chapter.

2. On the View menu, click Partition Table to see the information displayed in a user-friendly manner. You will see a screen similar to the following:

Figure 7.3 DiskProbe Partition Table view

DiskProbe makes it easy for you to look at the information for each volume. In the Partition table index list box, double-click the partition number for which you want to see the Partition Table entry.

Click the Next Partition button to see the information in the first sector of the next partition. For a primary partition, clicking the Next Partition button reads the Partition Boot Sector of the next partition. When the next partition is an extended partition, clicking Next Partition reads the Partition Table sector for the first logical drive in the extended partition.

For a primary partition, clicking the Go button next to the Relative Sector field reads the Partition Boot Sector for the current partition. When the System ID field is EXTENDED, clicking the Go button reads the Partition Table for the next logical drive in the extended partition.

If you make changes to the Partition Table, you must explicitly write the sector to disk by clicking Write on the Sectors menu.

When you are viewing the information for an extended partition in the Partition Table area of the Master Boot Record, the Total Sectors field is the total size of the extended partition, which is usually larger than the size of the first logical drive in the partition.

Walking an Extended Partition

If the disk has an extended partition, finding the information for each logical drive is more complicated than just looking at the Partition Table in the Master Boot Record, but DiskProbe does the work for you. "Logical Drives and Extended Partitions," within Chapter 3, describes the organization of an extended partition.

Information for the logical drives in an extended partition is basically chained from one logical drive to the next. The term walking an extended partition means that utilities like DiskProbe and DiskMap use the information defined for one logical drive in the chain to find the next logical drive in the chain. Knowing how to walk an extended partition is necessary if one of the links in the chain becomes corrupted, and you want to repair it.

The description in this section applies when you are viewing the Partition Table information in the first sector of each logical drive.

To help make the descriptions easier to understand, following is a screen shot from Disk Administrator, and the information from DiskProbe for the extended partition shown in the screen shot. The extended partition includes volume set E, logical drives I and K, and 4 MB of unused space between E and L. This example is the same disk configuration used in the section "DiskMap — Display a Map of the Disk," presented earlier in this chapter.

Note

This example is for illustration purposes, and is not a good organization for the disk, because the free space at the end of the primary partition is unusable. This is because you can have only four Partition Table entries in the Master Boot Record. In this example, primary partitions C, D, and L each use one entry. The extended partition, which includes volume set E, logical drives I and K, and the free space between E and K, uses the other entry. Disk Administrator displays an error message if you try to use any of the area after drive L to create a partition or extend an NTFS logical drive.

The distinction between the two areas of free space is that the one on the left is free space within an extended partition, while the free space on the right, which has a different background pattern, is not a part of any partition.

To walk the extended partition in this example, start with the information for Partition 3 in the Partition Table on relative sector 0. Partition 3 points you to the first logical drive in the extended partition. By following the links in the Partition Table entry for each logical drive, you can find the information for all of the logical drives.

The next table identifies which sectors contain information about the extended partition and the logical drives. The table also describes which buttons to click to walk the extended partition.

Relative sector | Contents
0 | Partition 3 of the Master Boot Record contains an EXTENDED entry, which is the information about the first part of volume set E. Click Go when viewing Partition 3 to read the Partition Table for the first part of volume set E.
819504 | Partition 1 describes the first part of volume set E. Partition 2 is an EXTENDED entry with the information for logical drive I. Click Next Partition when viewing Partition 1 to read the Partition Table for logical drive I.
839664 | Partition 1 describes logical drive I, Partition 2 is an EXTENDED entry with the information for logical drive K. Click Next Partition when viewing Partition 1 to read the Partition Table for logical drive K.
855792 | Partition 1 describes logical drive K. Partition 2 is an EXTENDED entry with the information for the second part of volume set E. Click Next Partition when viewing Partition 1 to read the Partition Table for the second part of volume set E.
879984 | Partition 1 describes the second part of volume set E. Partition 2 is all zeroes (end of the extended partition).

The next table shows the information in Partition 3 of the Master Boot Record and each of the Partition 1 entries for the extended partition.

Field Name | Master Boot Record entry | First part of E (10 MB) | I (8 MB) | K (12MB) | Second part of E (16 MB)
System ID | EXTENDED | NTFS FT | FAT | NTFS | NTFS FT
Boot Indicator | NO_ SYSTEM | NO_ SYSTEM | NO_ SYSTEM | NO_ SYSTEM | NO_ SYSTEM
Start Head | 1 | 1 | 1 | 1 | 1
End Head | 15 | 15 | 15 | 15 | 15
Start Sector | 1 | 1 | 1 | 1 | 1
End Sector | 63 | 63 | 63 | 63 | 63
Start Cylinder | 813 | 813 | 833 | 849 | 873
End Cylinder | 914 | 832 | 848 | 872 | 905
Relative Sector | 819504 | 63 | 63 | 63 | 63
Total Sectors | 102816 | 20097 | 16065 | 24129 | 33201

When the System ID field for a Partition 2 in an extended partition contains the value EXTENDED, double-click Partition 1 in the Partition table index list box, and then click Next Partition to read the first sector of the next logical drive. The only information in the first sector of a logical drive is a Partition Table, which has two entries. The Partition 1 entry contains information about the current logical drive, and the Partition 2 entry is the information for the next logical drive in the extended partition. The System ID for each Partition 2 entry should be EXTENDED unless you are at the end of the extended partition.

The next screen shot shows the Partition Table entry for the first part of volume set E; the Partition Table is located at relative sector 819504.

When the System ID field contains any value except EXTENDED or UNKNOWN, clicking the Go button next to the Relative Sector field reads the Partition Boot Sector for the logical drive.

To view the information for Partition 2 (the next logical volume), double-click Partition 2 or click Next Partition while viewing the information for Partition 1.

The Relative Sector field for each Partition 2 entry in an extended partition is the offset from the beginning of the extended partition, not the offset from the beginning of the Partition Table associated with the Partition 1 entry. Therefore, do not use the Go button to try to read the Partition Boot Sector for Partition 2.

Note

Sometimes, the System ID byte for NTFS volume sets, stripe sets, mirror sets, and stripe sets with parity does not have the correct value. It should be 0x87, which DiskProbe displays as NTFS FT. Instead, it might be 0x86, which DiskProbe displays as FAT FT. Windows NT uses information in the Partition Boot Sector to determine which file system to use, so this incorrect value causes no problems, although it can be confusing to a person trying to understand the data on the disk. To be certain which file system is being used for a volume, look at the Partition Boot Sector.

Viewing the Partition Boot Sector

You can use DiskProbe to view the information in Partition Boot Sectors. You see a formatted view of the information in the BIOS Parameter Block and the Extended BIOS Parameter Block. For a description of these structures, see "Partition Boot Sector," within Chapter 3, "Disk Management Basics."

To view a Partition Boot Sector

1. In the Resource Kit folder, double-click the DiskProbe icon.

2. On the Drives menu, click Logical Volume. In the Logical Volumes list box of the Open Logical Volume dialog box, double-click the drive letter for the partition or logical drive whose Partition Boot Sector you want to read.

3. In the Handle 0 group box, click Set Active. Click OK.

4. On the Sectors menu, click Read to display the Read Sectors dialog box. Set Starting Sector to 0 and Number of Sectors to 1.

5. On the View menu, click NTFS Bootsector or FAT Bootsector to see the information.

The next screen shot shows the NTFS Bootsector view of primary partition D for the disk configuration shown in Figure 7.1.

When viewing an NTFS Partition Boot Sector, there are Go buttons next to the fields Clusters to MFT and Clusters to MFT mirr. When you click one of these buttons, it reads the first sector of the MFT or the MFT mirror, respectively. For information about these structures, see "Master File Table (MFT) and NTFS System Files" within Chapter 17, "Disk and File System Basics," in the Windows NT Workstation Resource Guide.

As described earlier in this section, Windows NT writes a backup of the NTFS Partition Boot Sector at the logical center of the volume (Windows NT version 3.51 and earlier) or the end of the volume (Windows NT 4.0). You can use the Volume Middle and Volume End buttons to read the backup Partition Boot Sector. However, these are some situations (when using Windows NT version 3.51 or earlier) where the backup Partition Boot Sector does not get written in the correct location:

  • Converting a volume from FAT to NTFS.
  • Extending a volume set.

View the sector you read to make sure it looks like an NTFS Partition Boot Sector, and that the information in it is accurate for the volume.

When viewing a FAT Partition Boot Sector, there is also a Volume End button, but there is no backup of the FAT Partition Boot Sector on the volume. If you are trying to find where volumes begin and end so you can repair a Partition Table, you can use the Volume End button for both FAT and NTFS partitions or logical drives to read what should be the sector immediately before the beginning of the next partition or logical drive.

Note

If you are viewing a backup NTFS Partition Boot Sector, do not use the Go, Volume End, or Volume Middle buttons. These buttons read the correct sectors only when you are viewing the Partition Boot Sector at the beginning of the volume.

Backing Up and Restoring the Partition Boot Sector

The Partition Boot Sector contains information that the file system uses to access the volume. On x86-based computers, the Master Boot Record uses the Partition Boot Sector on the system partition to load the operating system kernel files, or in the case of Windows NT, the boot loader.

For examples of a Partition Boot Sector for a FAT and an NTFS volume, see Chapter 3, "Disk Management Basics."

There are several procedures that you can use, depending on whether you are backing up or restoring the Partition Boot Sector for:

  • A primary partition
  • A logical drive, which is a single contiguous area in an extended partition
  • Several Partition Boot Sectors in an extended partition
  • A volume set
  • A stripe set
  • A mirror set
  • A stripe set with parity

You can open the disk to read the Partition Boot Sector by using either Physical Drive or Logical Volume on the Drives menu. When you use Physical Drive, you have to read the Partition Table to find the address of the Partition Boot Sector. When you use Logical Volume, you read the Partition Boot Sector by reading sector 0 of the logical drive. You cannot read the Master Boot Record when you use Logical Volume.

To back up a Partition Boot Sector for a primary partition by using Physical Drive

1. Read the Partition Table and view it by using the procedure in "Displaying and Using the Partition Table," presented earlier in this section.

2. In the Partition table index list box, double-click the partition number for the Partition Boot Sector that you want to save. For instance, to save the Partition Boot Sector for the system partition, double-click the partition number that has the Boot Indicator set to SYSTEM.

3. To read the Partition Boot Sector, click the Go button next to the Relative Sector field. On the View menu, click NTFS BootSector or FAT BootSector to see the information displayed appropriately. Make sure that the sector you just read looks like a Partition Boot Sector, as described within Chapter 3, "Disk Management Basics."

4. On the File menu, click Save As. Enter the filename. Consider saving the file to the Emergency Repair Disk, the Windows NT startup floppy disk, or the MS-DOS bootable floppy disk. You can save it to more than one disk. When you are saving a Partition Boot Sector, using a name such as PBSssssssssDISKn.dsk, where ssssssss is the relative sector of the Partition Boot Sector and n is the disk number, can help you remember what the file contains.

To back up the Partition Boot Sector by using Logical Volume

1. In the Resource Kit folder, double-click the DiskProbe icon.

2. On the Drives menu, click Logical Volume. In the Logical Volumes list box, double-click the drive letter for the partition whose Partition Boot Sector you want to save.

3. In the Handle 0 group box, click Set Active. Close the dialog box.

4. On the Sectors menu, click Read. Set Starting Sector to 0 and Number of Sectors to 1. Make sure that the sector you read looks like a Partition Boot Sector, as described within Chapter 3, "Disk Management Basics."

5. On the File menu, click Save As. Enter the filename. Consider saving the file to the Emergency Repair Disk, the Windows NT startup floppy disk, or the MS-DOS bootable floppy disk. You can save it to more than one disk. When you are saving a Partition Boot Sector in this manner, using a name such as PBSdDSKn.dsk, where d is the drive letter of the logical drive, and n is the disk number, can help you remember what the file contains. Using a name such as this assumes that you will not be changing drive letters.

To back up the Partition Boot Sectors in an extended partition by using Physical Drive

1. Read the Partition Table and view it by using the procedure in "Displaying and Using the Partition Table," presented earlier in this section.

2. In the Partition table index list box, double-click the partition number for the extended partition, and then click Go. Doing this reads the first Partition Table entry in the extended partition.

3. You can walk the extended partition to find the logical drive whose Partition Boot Sector you want to back up. When you walk the extended partition, view the information for Partition 1 and click Go to read the Partition Boot Sector. You can use the Search function on the Tools menu to find each Partition Boot Sector. See "Finding a Partition Boot Sector," presented later in this chapter, for information about finding these disk sectors.

You can also print a map of the disk by using the DiskMap utility, which provides you with the address of the Partition Table entry for each logical drive. You can then use DiskProbe to read the first sector of the logical drive whose Partition Boot Sector you want to back up, and use the Go button to read the Partition Boot Sector.

Once you have read a Partition Boot Sector, on the View menu, click NTFS BootSector or FAT BootSector to see the information displayed appropriately. Make sure that the sector you just read looks like a Partition Boot Sector, as described within Chapter 3, "Disk Management Basics."

4. On the File menu, click Save As. Enter the filename. Consider saving the file to the Emergency Repair Disk, the Windows NT startup floppy disk, or the MS-DOS bootable floppy disk. When you are saving a Partition Boot Sector, using a name such as PBSssssssssDISKn.dsk, where ssssssss is the relative sector of the Partition Boot Sector and n is the disk number, can help you remember what all of the files contain.

To restore the Partition Boot Sector for a primary partition by using Physical Drive

1. In the Resource Kit folder, double-click the DiskProbe icon.

2. On the Drives menu, click Physical Drive. In the Available Physical Drives group box, the disks are listed as PhysicalDriven, where n=0 for the first hard disk. Double-click the disk that contains the Partition Boot Sector that you want to replace.

3. In the Handle 0 group box, clear the Read Only check box, click Set Active, and click Close.

4. If you know the address of the sector you need to write, skip to step 6. To use DiskProbe to compute the sector, first read the Partition Table and view it by using the procedure in "Displaying and Using the Partition Table," presented earlier in this section. Figure 7.3 shows the DiskProbe Partition Table view.

5. In the Partition table index list box, double-click the partition number for the Partition Boot Sector that you want to replace. For example, to view information about the Partition Boot Sector for the system partition, double-click the partition number that has the Boot Indicator set to SYSTEM.

The Relative Sector field contains the sector number for the Partition Boot Sector. Write down this number.

6. On the File menu, click Open, and enter the filename of the file that contains the Partition Boot Sector. Open the file. Verify that it looks like a Partition Boot Sector.

7. On the Sectors menu, click Write to display the Write Sector dialog box. In the Starting sector to write data, enter the sector number from step 5 (or that you already know is the correct sector). Click the option button for the disk to which you want to write the sector. Click Write it.

8. DiskProbe displays a message box so you can verify the information.

To restore the Partition Boot Sector by using Logical Volume

1. In the Resource Kit folder, double-click the DiskProbe icon.

2. On the Drives menu, click Logical Volume. In the Logical Volumes list box of the Open Logical Volume dialog box, double-click the logical drive whose Partition Boot Sector you want to restore.

3. In the Handle 0 group box, clear Read Only, click Set Active, and click Close.

4. On the File menu, click Open, and enter the filename of the file that contains the Partition Boot Sector. Open the file. Verify that it looks like a Partition Boot Sector and is 512 bytes. DiskProbe displays an error if the file size is not a multiple of 512.

5. On the Sectors menu, click Write to display the Write Sector dialog box. In the Starting sector to write data, enter 0 for the Starting sector to write data. Click Write it.

6. DiskProbe displays a message box so you can verify the information.

To restore the Partition Boot Sector in an extended partition by using Physical Drive

1. If you know the address of the Partition Boot Sector that you want to restore (which you would know if the sector number is part of the filename), follow the procedure for restoring the Partition Boot Sector (given earlier in this chapter) for a primary partition, skipping steps 4 and 5. You are done.

If you do not know the address, you can find it by walking the extended partition. Follow steps 1 through 3 in the procedure for backing up the Partition Boot Sector for an extended partition (given earlier in this chapter). Even though the Partition Boot Sector that you read is the one you want to replace, when you read it, DiskProbe displays its relative sector number. Write down this number.

You can also calculate the address of the Partition Boot Sector by using a DiskMap output for the disk. The sector number for a Partition Boot Sector is the address of the EBR for the logical drive + the Relative Sector value.

2. In the Handle 0 group box of the Open Physical Drive dialog box, be sure that Read Only is cleared.

3. On the File menu, click Open, and enter the filename of the file that contains the Partition Boot Sector. Open the file. Verify that it looks like a Partition Boot Sector.

4. On the Sectors menu, click Write to display the Write Sector dialog box. In the Starting sector to write data, enter the sector number that you found in step 1. Click the option button for the disk to which you want to write the sector. Click Write it.

5. DiskProbe displays a message box so you can verify the information.

If you formatted an NTFS volume when running Windows NT version 4.0, a backup of the Partition Boot Sector for NTFS primary partitions and logical drives is located at the end of the partition or logical drive. Earlier versions of Windows NT put the backup at the center of the volume. If you did not make a backup of the Partition Boot Sector, you can find the backup sector and copy it to the first sector of the volume.

To restore the backup NTFS Partition Boot Sector

1. In the Resource Kit folder, double-click the DiskProbe icon.

2. "Finding a Partition Boot Sector," presented later in this chapter, describes different methods for finding the Partition Boot Sector. When you find a Partition Boot Sector within the boundaries of an NTFS volume, make sure that the data are reasonable for the volume. If you have a deleted volume, or extended an NTFS volume, there might be old, invalid, Partition Boot Sectors on the disk. Save the backup to a disk.

3. Close any handles that you opened to find the backup.

4. On the Drives menu, click Logical Volume. Click the Close Handle button for any drives or logical volumes that are currently open. In the Logical Volumes list box of the Open Logical Volume dialog box, double-click the logical drive whose Partition Boot Sector you want to restore.

5. In the Handle 0 group box, clear Read Only and click Set Active. Click OK.

6. On the File menu, click Open, and enter the name of the file you copied to disk in step 2. Open the file.

7. On the Sectors menu, click Write to display the Write Sector dialog box. Since you are going to be writing to relative sector 0, make sure that the active handle is a drive letter, not PhysicalDriven. Enter 0 for the Starting sector to write data. Click Write it.

8. DiskProbe displays a message box so you can verify the information.

Finding a Partition Boot Sector

This section discusses some approaches for finding primary partitions and logical drives on your disk in order to repair the Partition Table, which is discussed in "Editing and Repairing the Partition Table," presented later in this chapter.

When you are looking for Partition Boot Sectors in order to repair the Partition Table, you know that some information is wrong or missing. Therefore, you need to verify that the information you use to find a Partition Boot Sector, or a Partition Table in an extended partition, is accurate. For example, if you use the Number of Sectors field for one primary partition to calculate the location of the Partition Boot Sector for the next partition, make sure that there is a valid Partition Boot Sector at that sector.

The easiest way to find the start of a primary partition is to find the Partition Boot Sector for the partition. For an extended partition, subtract the sectors per track from the address of the Partition Boot Sector to find the Partition Table entry for the logical drive.

The Partition Boot Sector for the first partition on your hard disk is always the first sector on head 1 of cylinder 0. Because disks typically have 32 or 63 sectors per track, you can usually find the Partition Boot Sector for the first partition at either relative sector 32 or relative sector 63. You can get the sectors-per-track information by clicking Volume Information on the Drives menu.

If you think that the relative sector field for a partition or logical drive is correct, you can read the sector by clicking Go when you are viewing its information to see if it looks like a Partition Boot Sector.

There is also a Total Sectors field on the Partition Table view. If you think this field is accurate, you can use this value to calculate the start of the next primary partition or logical drive.

The FAT and NTFS Partition Boot Sectors each have a field that contains the total number of sectors. If you already know or have found the start of a partition or logical drive, you can add the number of sectors to the starting sector to find the start of the next partition or logical drive. For an NTFS Partition Boot Sector, on the View menu, click NTFS BootSector. The Total sectors field contains the value you want. For a FAT volume, on the View menu, click FAT Bootsector. If the size of the primary partition or logical drive fits in 16 bits, the Small sectors field contains the size. Otherwise, the size is in the Large sectors field.

You can also use DiskProbe to search for Partition Boot Sectors. As you find each one, write down its location, and use the Partition Table view in DiskProbe to enter the information.

There are three situations in which you can find a Partition Boot Sector that is not at the beginning of a volume. You need to know about these other Partition Boot Sectors so you do not use the information about where these Partition Boot Sectors are located to repair the Partition Table.

  • If you formatted an NTFS volume, or converted a volume from FAT to NTFS when running Windows NT version 4.0, each NTFS volume has a backup of its Partition Boot Sector at the end of the volume. Earlier versions of Windows NT put the backup at the middle of the volume when you formatted it, but did not create a backup when you converted the volume.
  • When you extend an NTFS volume set, Windows NT version 4.0 puts a new copy of the Partition Boot Sector in the middle of the extended volume set. It does not remove the old copy of the Partition Boot Sector. If you extend a volume set when running Windows NT version 3.51, it does not remove the old copy of the Partition Boot Sector either, nor does it write a new one.
  • There can be old, invalid Partition Boot Sectors on the disk if you have deleted volumes.
To search for Partition Boot Sectors

1. In the Resource Kit folder, double-click the DiskProbe icon.

2. On the Drives menu, click Physical Drive. The Available Physical Drives in the Open Physical Drive dialog box are listed as PhysicalDriven, where n=0 for the first hard disk. Double-click the disk that you want to open, click Set Active, and click Close.

3. On the Tools menu, click Search. The information that you search for depends upon whether you want to find a FAT or an NTFS Partition Boot Sector. If you check the Search at offset check box and specify an Offset in hex at which to search for a specific value, the search runs much faster than searching each entire sector. You can search the entire disk if you do not change the default values in the First sector to search and Last sector to search fields.

This is an example of a search for an NTFS Partition Boot Sector.

Note

The contents of the Partition Boot Sector for an NTFS volume can be slightly different, depending on whether you formatted the volume when running Windows NT version 4.0 or earlier versions of Windows NT. If you specify a value in the Offset in hex field, you might need to search at a different offset depending on the data you are searching for, and which version of Windows NT you used to format the volume. For example, the string "discontinguous" starts at location 19A when you use Windows NT version 4.0 to format the volume. But discontinguous is at hex location 195 if you formatted the volume when running Windows NT version 3.5. The string NTFS starts at offset 3, regardless of the version of Windows NT you used to format the volume. If you don't know which version of Windows NT was used to format a volume, search for NTFS. Note that DiskProbe will find matches in sectors that are not Partition Boot Sectors.

4. If DiskProbe finds a match, it displays the address of the sector, as the following figure shows:

Be sure to verify that each sector DiskProbe finds is really a Partition Boot Sector. The View menu enables you to look at the data as bytes or formatted as an NTFS or a FAT Partition Boot Sector.

Editing and Repairing the Partition Table

You can use DiskProbe to display and change your Partition Table. Repairing a damaged Partition Table is risky, and should never be attempted by a user not familiar with the procedure. If all of the partitions on the disk are primary partitions, the repair process is much simpler than if you have an extended partition, volume sets, stripe sets, mirror sets, or stripe sets with parity.

If the wrong partition is set as the system partition, or you do not have a system partition on the disk, you can use DiskProbe to change this information in the Partition Table. If you have configured your system partition as a mirror set, you need to set the Boot Indicator field on the shadow partition. If this flag is not set and the original partition or the disk with the original partition fails, you will have to use the Windows NT startup floppy disk to start Windows NT.

Note

The system partition is always a primary partition. The original partition is the one from which you created the mirror set. The copy of the original partition is called the shadow partition.

To change or set the Boot Indicator field

1. View the Partition Table by using the procedure described in "Displaying and Using the Partition Table," presented earlier in this chapter.

2. Double-click each partition number in the Partition table index list box to determine which one is the system partition, or that none is set as the system partition. The partition that has the Boot Indicator field set to SYSTEM is the system partition.

3. To clear the Boot Indicator field for a partition, double-click its partition number, double-click NOSYSTEM in the Boot Indicator list box.

4. To set the system partition, double-click its partition number, and double-click SYSTEM in the Boot Indicator list box.

5. Make sure that the disk is in read/write mode. On the Drives menu, click Physical Drive to see the Open Physical Drive dialog box. Clear the Read Only check box, if it is checked. Click Close.

6. On the Sectors menu, click Write, and enter 0 in Starting sector to write to. Click Write it.

7. DiskProbe displays a message box so you can verify the information.

When you create a volume set, stripe set, mirror set, or stripe set with parity, Windows NT sets the fault tolerant (FT) bit of the System ID byte in the Partition Table. This bit indicates that Windows NT needs to use the Registry key HKEY_LOCAL_MACHINE\SYSTEM\DISK to know how to find all of the members of the volume. Because volumes cannot be accessed without the DISK key, they can only be accessed by Windows NT. In a dual-boot configuration, the other operating system cannot use a partition with the FT bit set.

In general, you should use Disk Administrator, and not DiskProbe, to change the value of this field. You should only change this field to remove the FT flag, and then only to break a mirror set. You might want to set or clear the FT flag to test recovery procedure, but be sure to have a backup of the Registry and the data on the partition before you do so.

To clear the FT flag for a primary partition

1. View the Partition Table by using the procedure described in "Displaying and Using the Partition Table," presented earlier in this chapter.

2. Double-click the partition number in the Partition table index list box for which you want to change the value of the FT flag.

3. If you want to remove the FT flag from a FAT partition, you need to figure out whether the partition should be FAT 12 bit, FAT 16 bit, or FAT Large. See the section titled "System ID Field," within Chapter 3, "Disk Management Basics," for information about the types of FAT partitions. Double-click either FAT 12 bit, FAT 16 bit, or FAT Large in the System ID field.

4. If you want to remove the FT flag from a NTFS partition, double-click NTFS in the System ID field.

5. Make sure that the disk is in read/write mode. On the Drives menu, click Physical Drive to see the Open Physical drives dialog box. Clear the Read Only check box, if it is checked. Click Close.

6. On the Sectors menu, click Write, and enter 0 in Starting sector to write to. Click Write it.

7. DiskProbe displays a message box so you can verify the information.

When you have found the Partition Boot Sectors, you can calculate all of the information for the Partition Table entries. If you do not know the values for the number of heads, number of sectors per track, or number of cylinders for the disk, open a handle by clicking either Physical Drive or Logical Volume on the Drives menu, and then click Volume Information on the Drives menu.

If none of the information in your Partition Table is correct, you might be safer to try to do a complete backup of the data on the disk. It might even be faster to backup and restore the data instead of repairing the Partition Table. You can then recreate and reformat the partitions and logical drives, and restore all of the data.

Note

If a partition or logical drive extends beyond cylinder 1023, set the Starting and Ending Sector, Head, and Cylinder fields to the maximum values. Maximum values indicate to Windows NT that it needs to use the information in the Partition Boot Sector to know how to access the volume. Remember that your system and boot partitions should not go beyond cylinder 1023 if you have set up your computer to dual-boot MS-DOS or Windows 95.

Repairing the Partition Table

1. For primary partitions, view the Partition Table by using the procedure described in "Displaying and Using the Partition Table," presented earlier in this chapter. For an extended partition, the section "Walking an Extended Partition," presented earlier in this chapter, describes finding the Partition Table entry for each logical drive.

2. Double-click the partition number for which you want to change information. Enter the new values.

3. Make sure that the disk is in read/write mode. On the Drives menu, click Physical Drive to see the Open Physical Drive dialog box. Clear the Read Only check box, if it is checked. Click Close.

4. On the Sectors menu, click Write, and enter the sector number of the Partition Table that you read in step 1. If you are changing information for primary partitions, the sector number is 0. Click Write it.

5. DiskProbe displays a message box so you can verify the information.


DiskSave - Back Up and Restore Critical Disk Sectors

DiskSave is an MS-DOS-based utility that enables you to save the Master Boot Record (MBR) and Partition Boot Sector (PBS) as binary files. You must start MS-DOS to run this utility. It will not run from the command prompt.

You should save these files to your Windows NT startup floppy disk or your MS-DOS bootable floppy disk. If your computer fails to start because it has a problem using the MBR or PBS, you can restore them and try the startup again.

This tool also enables you to turn off the FT bit in the System ID field of the system partition. You should turn off the bit on the system partition on the shadow disk if you are unable to start Windows NT when the original disk has failed.

The Master Boot Record contains code that the system BIOS on x86-based computers uses to read the Partition Table and find the Partition Boot Sector of the system partition. This sector also contains the Partition Table. If this sector becomes damaged, the computer cannot find or start the operating system.

The Partition Boot Sector contains code that loads the operating system kernel or a boot loader. A corrupt Partition Boot Sector can also cause startup failures.

Note

If either of the sectors that you restore does not match the configuration of your computer, you can make your problems worse. Always be sure to save the Master Boot Record and the Partition Boot Sector whenever you make changes that affect them.

These are the DiskSave functions:

  • F2, back up the Master Boot Record. This function saves cylinder 0, head 0, sector 1 of the startup disk to the filename that you enter. You need to save a new copy of this record any time that you create or delete a partition, or change the file system used on a partition.
  • F3, restore the Master Boot Record. This function copies the file that you specify to cylinder 0, head 0, sector 1 of the startup disk. Restoring this sector also replaces the Partition Table. There are no checks to determine if the sector is a valid Master Boot Record.
  • F4, backup the Partition Boot Sector. This function saves the first sector of the system partition on disk 0 to the filename specified.
  • F5, restore the Partition Boot Sector. This function replaces the first sector of the system partition with the contents of the specified file. There are no checks to determine if the sector is a valid Partition Boot Sector.
  • F6, disable fault tolerance on the startup disk. This function is useful when Windows NT will not start from a mirror set of the system partition. The function looks for the system partition. It then checks to see if the System ID byte has the high bit set. Windows NT sets the high bit of the System ID field if the partition is a member of a fault-tolerant volume. Disabling this bit has the same effect as breaking the mirror set. DiskSave does not allow you to reenable the bit once it has been disabled.

If you use F6 to turn off the FT bit to be able to start, you still need to break the mirror set after you have started Windows NT. Use Disk Administrator to break the mirror set, which turns off the FT bit in the shadow partition. You need to do this so the Registry and disk information match.

When DiskSave makes calls to the system BIOS, it checks the status of each call. The normal return value is zero. Originally, a nonzero value indicated an error, and the error codes were documented. Currently, there are system BIOSs that return nonzero values, which are not documented. These nonzero values do not seem to be errors. So far, all of these nonzero values that are not errors have occurred when using IDE disks.

If the value is non-zero, DiskSave displays a message at the bottom of the screen. If you see a message about a system BIOS call returning a nonzero value, it would be a good idea to check whether the function worked correctly. One way to check is to start Windows NT, and use the Windows NT-based utility DiskProbe to compare the sector that you tried to save or restore with a copy of the data. For example, if you see a message about a nonzero return code when you select F4 to save the Partition Boot Sector, finish saving the sector to a file. Then, using DiskProbe, read the Partition Boot Sector from disk, and compare the contents to the file that you just saved.

To use DiskSave to back up the Master Boot Record or Partition Boot Sector

1. Start MS-DOS. Enter disksave at the command prompt. You now have the following options:

F2 — Backup the Master Boot Record

F3 — Restore Master Boot Record

F4 — Backup the Boot Sector

F5 — Restore Boot Sector

F6 — Disable FT on the Boot Drive

2. Press F2 to save the Master Boot Record and F4 to save the Partition Boot Sector. You need to enter the full name for the file, including the path. For example, to save the Master Boot Record to a folder on your C drive, use a name such as C:\Backup\Mbrdisk0.dsk. If you copy it to a floppy disk, the path should be similar to A:\Mbrdisk0.dsk.

Note

DiskSave only saves the Master Boot Record on disk 0 and the Partition Boot Sector for the system partition on disk 0.

To use DiskSave to replace the Master Boot Record or Partition Boot Sector

1. Start MS-DOS. Enter disksave at the command prompt. You have the following options:

F2 — Backup the Master Boot Record

F3 — Restore Master Boot Record

F4 — Backup the Boot Sector

F5 — Restore Boot Sector

F6 — Disable FT on the Boot Drive

2. Press F3 to replace the Master Boot Record and F5 to replace the Partition Boot Sector. You need to enter the full name for the file, including the path. For example, if you have saved the Master Boot Record on your Emergency Repair Disk or the Windows NT startup floppy disk, the path might be A:\Mbrdsk0.dsk.

Note

DiskSave only restores the Master Boot Record on disk 0 and the Partition Boot Sector for the system partition on disk 0.


FTEdit - Recovering Volume Sets, Stripe Sets, and Stripe Sets With Parity

The FTEdit utility on the Windows NT Server Resource Kit CD aids in the recovery of stripe sets, volume sets, stripe sets with parity, and mirror sets. For more information about using FTEdit, see Ftedit.hlp on the Windows NT Server Resource Kit CD.

Note

You can recover and rebuild information for all of these volumes in the same way. However, rebuilding a mirror set with FTEdit is a waste of time, since the mirror set has to be regenerated anyway. You are better off simply breaking the mirror set by using Disk Administrator, and then recreating it. See Disk Administrator Help for the procedures.

Because stripe sets and volume sets are not fault tolerant, Windows NT Server performs orphan processing differently than it would for stripe sets with parity and mirror sets. If one of the disks in a stripe set or volume set fails, the entire volume is no longer usable, and all the primary partitions or logical drives that are members of the volume are marked as orphans. In Disk Administrator, the members of the volume are displayed as Unknown.

All data about the configuration of volume sets, stripe sets, mirror sets, and stripe sets with parity are contained in the HKEY_LOCAL_MACHINE\SYSTEM\DISK Registry key. This disk configuration information is stored in binary format, so it is not practical to edit it manually. When the Registry information is corrupt or missing, and no backups are available, you can use FTEdit to build the Registry information and allow the operating system to read the volumes.

For example, if the disk containing the boot partition becomes unusable, or the computer fails, you might want to move the disks containing the volumes to another computer. Alternatively, you might decide to reinstall the operating system on a new disk. In either case, the operating system does not have any information about the volumes.

The operating system has information about which disks are members of volumes, but it cannot distinguish between a stripe set, a stripe set with parity, a volume set, or a mirror set without the Registry information. In this situation, when the volumes are displayed in Disk Administrator, the file system might be displayed as Unknown, and there will be no drive letter assigned to the volumes. This is to prevent writing to the volume, which could corrupt it.

When using FTEdit to rebuild the DISK Registry subkey, you need to know the order in which the partitions on the disks were combined to create the volume. The following scenario shows why order is important.

A previous user created a volume set by combining unpartitioned areas on three disks in this order:

  • 2 MB on disk 2
  • 3 MB on disk 0
  • 4 MB on disk 1

When a volume set is created, the Partition Boot Sector is the first sector on the first area selected. Data are written to the areas in the order in which they are combined. Thus, if someone created a 6 MB file on this volume set, the file would occupy the following areas:

  • 2 MB on disk 2
  • 3 MB on disk 0
  • 1 MB on disk 1

Now you need to use FTEdit to rebuild the volume set. You select the disks in the order disk 0, disk 1, and then disk 2. Windows NT will not be able to find the Partition Boot Sector for the volume set, because the first sector of the volume set that you rebuilt is on disk 0, which contains only data. The Partition Boot Sector is actually on disk 2, but that disk area is at the end of the volume set you created. Your attempt to rebuild the volume set has failed, because you did not know the order in which to combine the disk areas.

The remainder of this section describes using FTEdit to build Registry information for a stripe set with parity that has been moved from another computer. (Disks 1, 2, and 3 are the disks that have been moved.) Each disk is 519 MB and has one partition. Both computers are running Windows NT Server version 4.0.

To rebuild a stripe set with parity

1. Open Disk Administrator, so that you can update the disk configuration information. Disk Administrator needs to store the disk signature and other basic disk information before the disks can be recognized.

2. Open FTEdit. The dialog box in Figure 7.4 is displayed.

Figure 7.4 Using FTEdit to recover a stripe set with parity

The Disks group box identifies all of the disks connected to the computer. The Partitions group box contains information about the disk currently selected, or the first disk, if none are selected. Disk 0 is two gigabytes, and contains two partitions.

3. On the Edit menu, click Create FT Set. In the FT Set Type dialog box, click the Option button for the type of volume you are building. In this example, click Stripe Set with Parity.

4. In the Disks list box, select the first disk that will be a member of the stripe set with parity. Available partitions are displayed in the Partitions list box on the right.

Double-click the partition from each disk that will make up the stripe set with parity. The disk and partition information will be displayed in the list box on the lower right. The title of this list box reflects the type of volume being built. For this example, the title is Stripe Set with Parity. The next screen shot shows the dialog box after double-clicking Partition 1 on each of Disk 1, Disk 2, and Disk 3.

5. Click the Save FT Set button. The information is transferred to the FT Set Member Information list box. Check to make sure the information is correct. FTEdit should look like the following illustration:

The Partitions list box shows the information for Disk 0. The disks that are used in creating the new volume are those listed in the FT Set Member Information list boxes.

6. On the Edit menu, click Save Changes to System. The following message box is displayed:

7. Exit FTEdit, close any open programs, and restart the system. You need to do this to get the new information loaded into the Registry.

8. Open Disk Administrator.

Click one of the partitions in the stripe set with parity. If the status bar has a message like Stripe set with parity #N [INITIALIZING], the computer on which you were previously using the stripe set with parity did not finish shutdown. Wait for Disk Administrator to finish the initialization. If the volume was functional before the disks were moved, and the correct information was entered in FTEdit, the data on the volume should be intact.

9. From the Disk Administrator Tools menu, click Drive Letter. In the Assign Drive Letter dialog box, click Assign drive letter, and then choose a drive letter for the new volume.

The volume is now accessible from Windows NT Explorer, My Computer, and by the rest of the operating system.

10. After confirming that the volume is correctly configured and is accessible, be sure to add this new configuration information to the records that you keep for this computer.

You might want to back up the stripe set with parity at this time.

These same steps can be used to recover volume sets and stripe sets. To successfully use FTEdit to build Registry information, you must know the following information:

  • Which disks contain stripe sets, stripe sets with parity, and volume sets.
  • Which partitions belong to the stripe sets, stripe sets with parity, and volume sets.
  • The order in which the partitions were combined into the stripe sets, stripe sets with parity, or volume sets.

If your configuration involves multiple stripe sets, stripe sets with parity, and volume sets on several different disks, you might face a very difficult job remembering which primary partitions and logical drives belong to which volumes. For this reason, it is a good idea to keep the disk configuration simple, and to keep recovery information as up-to-date as possible.

Note

FTEdit edits the binary information in the Registry. It cannot recover damaged or corrupt data on the disk.


File System Utilities

The utilities described in this section are available on either the Windows NT Server product CD, or the Windows NT Server Resource Kit CD. This table shows which ones are on which CD.

Utility | Location
Cacls | product CD
Compact | product CD
Compress | resource kit CD
Convert | product CD
Diruse | resource kit CD
Expand | product CD
Expndw32 | resource kit CD


Cacls: Changes ACLs of NTFS Files and Folders

You can use the cacls utility to display or modify access control lists (ACL) of files or folders. A description of the command options follows the syntax. This is the format of the command:

CACLS <filename|folder> [/t] [/e] [/c] [/g user:perm] [/r user [...]][/p user:perm [...]] [/d user [...]]
Option | Description
filename or folder name | Displays ACLs.
/t | Changes ACLs of specified files in the current folder and all subfolders.
/e | Edit ACL instead of replacing it.
/c | Continue on access denied errors.
/g user:perm | Grant specified user access rights, where perm can be: R Read C Change (write) F Full control
/r user | Revoke specified user's access rights (only valid with /e).
/p user:perm | Replace specified user's access rights, where perm can be: N None R Read C Change (write) F Full control
/d user | Deny access to the specified user.

Wildcards can be used to specify more than one file in a command. You can specify more than one user in a command also.

If you already have permissions set for multiple users on a folder or file and do not use the /e option, all user permissions are removed except for the user and permissions specified on the command line. You should use the following syntax when modifying user permissions to include read, change, and full control respectively:

cacls <filename|folder> /e /r <username> cacls <filename|folder> /e /g <username>:<permission> cacls <filename|folder> /e /p <username>:<permission>

The cacls utility does not provide a /y option that answers automatically with Y for Yes to the ARE YOU SURE? Y/N prompt. However, you can use the echo command to pipe the character Y as input to the prompt when you are running cacls in a batch file. Use the following syntax to automatically answer Y:

echo y| cacls <filename|folder> /g <username>:<permission>

Note

Do not enter a space between the y and the pipe symbol (|). If you do, cacls fails to make the permission change.


Compact: Compresses and Uncompresses NTFS Files and Folders

The compact utility is the command line version of the compression functionality in My Computer or Windows NT Explorer. The compact command displays and alters the compression of folders and files on NTFS volumes. It also displays the compression state of folders. For more information about this utility, type compact /? at the command prompt. The following table describes the options.

The format of the command is:

compact [/c] [/u] [/s[:folder]] [/a] [/i] [/f] [/q] [filename [...]]
Option | Description
none | Displays the compression state of the current folder.
/c | Compresses the specified folder or file.
/u | Uncompresses the specified folder or file.
/s[folder] | Specifies that the requested action (compress or uncompress) be applied to all subfolders of the specified folder, or to the current folder if none is specified.
/i | Ignores errors.
/f | Forces compression or uncompression of the specified folder or file.
/a | Displays files with the hidden or system attribute.
/q | Reports only the most essential information.
filename | Specifies a pattern, file, or folder. You can use multiple filenames and wild cards.

There are reasons why you would want to use this utility instead of My Computer or Windows NT Explorer:

  • You can use compact in a batch script. Using the /i option enables you to skip files that cannot be opened when you are running in batch mode, such as when a file is already in use by another program.
  • If the system crashed when compression or uncompression was occurring, the file or folder is marked as Compressed or Uncompressed, even if the operation did not complete. You can force the operation to complete by using the compact utility with the /f option (with either the /c or /u).

Note

The Compact utility automatically compresses or uncompresses all of the files and subfolders when you change the compression state of a folder. It does not ask whether you want to change the compression state of the files or subfolders within it.


Compress: Compresses Files or Folders

This command line utility can be used to compress one or more files. You cannot open a file that has been compressed by using this utility. You have to expand it by using Expand or Expndw32 first.

To use this utility, type compress with the appropriate options at the command line:

compress [-r] [-d] source [destination]

Option | Description
-r | Renames compressed files.
-d | Updates compressed files only if out of date.
source | Specifies the source file. The "*" and "?" wildcards can be used.
destination | Specifies the destination file or path. The destination can be a folder. If source specifies multiple files and the -r option is not specified, then destination must be a folder.

Note

You should not use this utility to compress files or folders on NTFS volumes. Instead, compress NTFS files and folders by using the Compact utility or by setting or clearing the Compressed attribute in My Computer or Windows NT Explorer. See Chapter 18, "Choosing a File System," in the Windows NT Workstation Resource Guide, for information about using My Computer or Windows NT Explorer.


Convert: Converts a Volume From FAT to NTFS

You can use the Convert utility to convert a volume from the FAT file system to the NTFS file system. This utility performs the conversion within the existing volume. You do not need to back up and restore the files when you use this utility.

You cannot convert the Windows NT boot partition while you are running Windows NT. Therefore, convert gives you the choice of converting the partition the next time you start Windows NT. When you convert the partition this way, Windows NT restarts twice to complete the conversion process.

To use this utility, type convert with the appropriate options (explained in the table following the syntax) at the command line:

convert drive: /FS:NTFS [/v]

Option | Description
drive | Logical drive that you want to convert.
/FS | You must specify that you want to convert to the NTFS file system.
/v | Run the utility in verbose mode.


DirUse: Provides Information About Usage of Disk Space

You can use the DirUse utility on the Windows NT Server Resource Kit CD to obtain disk space usage per folder. For more information about DirUse, type diruse /? at the command line, or see the Windows NT Resource Kit Tools Help for information.

This utility is useful to get the actual usage of space for compressed files and folders in NTFS volumes.

The format of the command is:

diruse [/s | /v] [/q:#] [/m | /k | /b] [/a] [/l] [/d] [/o] [/c] [/,] [/*] [dirs]

The option of interest for compressed folders and files is /c, which causes the display of compressed file or folder size instead of apparent size. For example, if your D drive is an NTFS volume, type diruse /s /m /c d: at the command prompt.

To see compression information for an individual file, you can use My Computer or Windows NT Explorer, select the file, and select Properties from the File menu.


Expand and Expndw32: Expand Compressed Files

You can use two utilities to expand one or more compressed files from your Windows NT CD, or a file that you compressed by using compress.

You can use Expndw32, the Windows NT-based expand utility, in one of these ways:

  • If you have installed the Windows NT Server Resource Kit, you can double-click the Expand Files icon in the File Tools program group.
  • From My Computer or Windows NT Explorer, open the Expndw32.exe file. If you have installed the Windows NT Server Resource Kit, this utility is in the folder into which you installed the Windows NT Server Resource Kit. On the Windows NT Server Resource Kit CD, use the version that corresponds to the hardware platform that you are using.

For help while you are using the utility, choose the Help button or press F1.

The MS-DOS-based expand utility runs from the command line. Type the expand command with the appropriate options, as shown in the table:

expand [-r] source [destination]

Option | Description
-r | Renames expanded files.
source | Specifies the source file. The "*" and "?" wildcards can be used.
destination | Specifies the destination file or path. The destination can be a folder. If source specifies multiple files and the -r option is not specified, then destination must be a folder.


Backup Utilities

AT: Enables You to Schedule Windows NT Backup

The Windows NT Backup utility, Ntbackup, does not include functionality for scheduling unattended backups. However, by using the Schedule service with the command line capabilities of the Ntbackup utility, you can set up unattended backups.

The following procedure shows how to use the Schedule service and the Ntbackup utility to schedule an unattended backup of the entire C drive of a computer with an installed tape device. With minor modifications, these steps could also allow for scheduling unattended backups from a computer on a network to a computer with an installed tape device or other configurations.

To schedule unattended backup

1. Start the Schedule service on the computer with the tape device already installed. This can be done by using the Services option in Control Panel, clicking Schedule, and clicking Start. Alternatively, you can configure the Schedule service to start every time Windows NT starts by clicking Startup and setting the Startup Type to Automatic.

2. Using any text editor, such as Notepad, create a command file, such as, Mybackup.cmd to perform the commands to backup the files.

This example

ntbackup backup c: /D "My Backup Files" /B /L "c:\backup.log"

does the following:

  • Backs up all files on the C drive.
  • Replaces any files currently on the tape.
  • Labels the backup set "My Backup Files."
  • Backs up the local registry.
  • Logs all backup information to C:\Backup.log.

3. Using the AT command, schedule the command file (Mybackup.cmd) to run when desired. The following AT command schedules Mybackup.cmd to execute at 11:00 P.M. every Monday, Wednesday, and Friday:

AT 23:00 /every:M,W,F MYBACKUP.CMD

When there is no tape in the drive and you use the AT command without the interactive switch to run Windows NT Backup, the backup encounters an error or is unable to accept the command line. As a result, Windows NT Backup stops responding. You cannot run Windows NT Backup again until you restart Windows NT.

Use the /INTERACTIVE switch with the AT command to open the interactive desktop. This way, if any errors occur, you will be able to correct them and continue, or quit Windows NT Backup.

For information about AT options, type AT /? at a command prompt or search the online Command Reference for AT. For additional information on available Ntbackup options, use the Help menu when running Ntbackup.exe.


Chapter 8 - General Troubleshooting

This chapter identifies tools that are available in Windows NT to help you troubleshoot problems. It contains information about troubleshooting hardware problems, and how to use information in the Registry to determine why services aren't working correctly. It also contains an example of using information in the Registry for troubleshooting.

Careful record keeping is essential to successful troubleshooting. You should have records of your network layout, cabling, previous problems and their solutions, dates of installation of hardware and software, and so on, all readily accessible.

Many problems can be avoided with routine virus checks. Be sure to check for viruses before installing or upgrading Windows NT on a computer that is already in use.

This chapter gives information about other chapters with troubleshooting help; it explains methodology; provides an overview of Windows NT tools; describes hardware problem-solving; and explains how to identify which services or drivers are working.


Sources of Troubleshooting Information

In addition to the troubleshooting tools that are described in this chapter, there are several other sources of troubleshooting information:

  • Chapter 6, "Troubleshooting Startup and Disk Problems," discusses what you can do to find the cause of problems when your computer fails to complete startup.
  • The following chapters are in the Windows NT Workstation Resource Guide:
    • Chapter 23, "Overview of the Windows NT Registry," describes how to use information in the Registry for troubleshooting and configuration maintenance.
    • Chapter 25, "Configuration Management and the Registry," provides problem solving techniques using the Registry.
    • Chapter 39, "Windows NT Debugger," describes the different types of STOP messages. It also contains information about using the Windows NT Debugger.
  • The Messages database, included in this Resource Kit, is another source of troubleshooting information. Here, thousands of messages are documented, with the probable cause and recommended solution to each of them. In particular, the Kernel STOP errors that appear when the system fails (with a blue screen) are documented in the Messages database. Chapter 38 in the Windows NT Workstation Resource Guide, "Windows NT Executive Messages," discusses the various types of messages generated by the Windows NT Executive, and categorizes them by their type and severity.
  • Windows NT Help contains a troubleshooting topic.
  • Appendix A in the Windows NT Server Start Here book describes how to overcome problems installing Windows NT 4.0 on x86-based computers.
  • The Windows NT Server Start Here book describes Microsoft's AnswerPoint Information Services, which provides easy telephone access to the latest technical and support information for Microsoft products.
  • The Microsoft Knowledge Base contains support information developed by Microsoft product support specialists. You can search for all Windows NT troubleshooting articles by specifying winnt and tshoot in the query. The Windows NT Knowledge Base is included on the Windows NT Server Resource Kit CD. It is also included in the:
    • Microsoft Developer Network (MSDN) CD.
    • TechNet CD.
    • Microsoft Internet FTP host, ftp.microsoft.com.
    • Technical Support and Services category on the Web page http://www.microsoft.com/server.


Troubleshooting Methodology

This section discusses approaches for solving a problem and presents an example of a troubleshooting scenario. There are three parts to this methodology:

  • Isolating the problem.
  • Identifying whether the action has ever worked properly on this computer, or works on another computer.
  • Defining an action plan.


Isolating the Problem

First, try to isolate the problem. What, precisely, is not working correctly? Try to narrow down exactly what you expect to have happen versus what is happening.

For example, if your computer does not complete startup, you need to identify how far it gets, and write down any error messages. On an x86-based computer, if you get an error such as Missing operating system from the system BIOS when you start your computer, the problem is very different than if startup fails after the boot loader (NTLDR) starts. You know that the NTLDR has started when you see the message

NTDETECT V1.0 Checking Hardware . . .

Another way to isolate the problem is to figure out if there are related programs or functionality that works correctly on this computer. If so, what are the differences between what works and what does not work?


Identifying Whether It Works in Other Situations

Has what you are trying to do ever worked on this computer before? If so, something might have changed that affects it. Have you changed hardware or installed new software? Has somebody else been using the computer, and could that person have made changes you do not know about?

If this program or functionality has never worked on this computer, compare the setup and configuration on this computer with the same program on another computer to identify differences.

As an example, identical 624 MB IDE disks are installed on two different x86-based computers. On one computer, 609 MB are available after creating partitions. On the other computer, only 504 MB are available. If you look at the messages that the system BIOS displays when starting up the two computers, you may see that the computer with 609 MB has a newer BIOS than the other computer. You would need to upgrade the other computer's system BIOS, or obtain a third-party translation utility that enables the computer to access the entire disk.


Defining an Action Plan

Try to identify all of the variables that could affect the problem. As you troubleshoot the problem, try to change only one of these variables at a time. Keep records of what you do and the effect of each action.

It's advantageous to develop your plan on paper. Decide what steps you want to take, and what you expect to do based on the results of each step. Then do the steps in order, and follow your plan.

If you see a result for which you have no plan:

  • Go back to the isolation phase.
  • Identify what happens in similar situations.
  • Define another plan.


Troubleshooting Scenario

Here is a scenario that shows applying this approach to an actual problem. A user was trying to upgrade a home computer to a newer version of Windows NT 4.0 (before the final product was available). The user was about half finished with copying files from the CD to the hard disk when a message appeared saying that a file could not be copied. This was how the user isolated the cause of the problem.

The user has successfully installed earlier versions of the software on this computer. Since the last upgrade of Windows NT, the CD had been used to install another program, with no problems.

Nothing has been changed on the computer since the last upgrade, except installing the other program. That program should have no relationship to the problem. Other people can install the same version of Windows NT from CD on similar computers.

The user noticed that the CD-ROM drive made noises like it was spinning faster and then slower just before the error message.

These are the steps that he used to identify and recover from the problem.

Step 1. Check the event log to see if there are any errors logged. The CD ROM device was reporting bad blocks on the CD, so Windows NT knew that there were problems.

Step 2. Inspect the CD for dust or scratches. There were no obvious problems on the CD, and the user previously had no problems using the CD.

Step 3. Copy files from the CD manually rather than running Windows NT Setup. The file that caused the error copied fine, but other files on the CD could not be copied.

Step 4. Get another CD of the same version and try to install Windows NT from it. (Perhaps there is a problem with the CD itself.) Windows NT Setup failed on the same file on both CDs, and manually copying files fails on the same files.

Step 5. Install software from other CDs that have worked on this computer before. The user noted that some work, some do not. The ones that do not work have more data on them than ones that install successfully. Therefore, something must be wrong with accessing data on the later tracks of the CD. Data is recorded on CDs starting on the innermost track. CDs vary their spin rate when reading inner versus outer tracks. Something might be wrong with the motor synchronization spin rate.

Step 6. Look inside the CD-ROM drive for signs of dust or hair that might interfere with proper operation at one end of the read head's range of motion. A hair was found stuck to the read head.


Using Troubleshooting Tools

This section provides a brief overview of the troubleshooting tools that are available on the Windows NT Server product CD and the Windows NT Server Resource Kit CD.


Windows NT Tools

These tools are installed when you install Windows NT Server:

Tool |  | Purpose |  | For more information:
Event Viewer |  | Display the system, security, and application logs. |  | Chapter 37, "Monitoring Events," in the Windows NT Workstation Resource Guide.
Performance Monitor |  | Measure your computer's efficiency, identify and troubleshoot possible problems, and plan for additional hardware needs. |  | Chapter 10, "About Performance Monitor," in the Windows NT Workstation Resource Guide. Chapter 8, "Monitoring Performance" in the Windows NT Server Concepts and Planning book.
Task Manager |  | Monitor active applications and processes on your computer, and start and stop them. |  | Chapter 11, "Performance Monitoring Tools," in the Windows NT Workstation Resource Guide.
Windows NT Diagnostics |  | Enables you to view hardware information in the Registry, such as currently loaded device drivers and IRQ values. |  | "Using the Windows NT Diagnostics Administrative Tool," presented later in this chapter.
Windows NT Hardware Detection Tool (NTHQ) |  | Identifies installed hardware and settings for diagnostic purposes. |  | "Using the Windows NT Hardware Detection Tool (NTHQ)," presented later in this chapter.
Network Monitor | Determines problems during session initialization, problems related to broadcast storms, and troubleshooting packets for transmission problems between computers. |  | Chapter 10, "Monitoring Your Network," in the Windows NT Server Concepts and Planning book.


Windows NT Server Resource Kit Tools

The Windows NT Server Resource Kit contains many tools that can be used for troubleshooting. For information about all of the tools available in the Windows NT Server Resource Kit, refer to the online Resource Kit Tools Help (Rktools.hlp) and double-click each of the tools groups from the Contents page.


Troubleshooting Hardware Problems

There are three Microsoft products that you can use to help troubleshoot hardware problems:

  • Hardware Compatibility List (HCL)
  • Windows NT Hardware Detection Tool (NTHQ)
  • Windows NT Diagnostics Administrative Tool


Using the Hardware Compatibility List (HCL)

The most common cause of hardware problems is the use of hardware that is not listed on the Hardware Compatibility List (HCL). The HCL included in the Windows NT Server Resource Kit lists the hardware components that have been tested and have passed compatibility testing with Windows NT version 4.0. It is especially important for you to refer to the HCL if you plan to use any modems, tape backup units, and SCSI adapters.

The latest HCL is available on:

  • The Web at http://www.microsoft.com/ntserver/
  • Microsoft's FTP server at ftp://microsoft.com/bussys/winnt/winnt_docs/hcl

To avoid problems, make sure that you are using a device make and model that is listed on the HCL. If several models from one manufacturer are included in the HCL, only those models are supported; a slightly different model might cause problems. Where special criteria are required for a model to be supported (for example, if a particular version of driver is required), this information is described as a footnote in the HCL. As additional hardware is tested, the HCL is updated, in this way new device drivers and other system components are added to the HCL. The updated list and software are available through the electronic services listed at the end of the HCL.


Using the Windows NT Hardware Detection Tool (NTHQ)

NTHQ is an MS-DOS-based program. The next procedure describes how to run the program.

To run NTHQ

1. When running Windows NT, insert a blank 3.5-inch floppy disk in the drive.

2. Run Makedisk.bat from the \Support\Hqtool directory on the Windows NT Server product CD.

3. Leave the floppy disk inserted, and shutdown your computer.

4. When your computer restarts, you are running NTHQ.

The file Readme.txt on the floppy disk contains details about NTHQ. You can see the same information by clicking the Help button on the NTHQ screen.

These are the three ways that NTHQ is most often used:

  • Print hardware information, save it to a file, and keep the report and file with the other configuration information for your computer. This report can be used when planning to change the configuration.
  • If you are having problems installing Windows NT, you can start NTHQ from the floppy disk and use it for troubleshooting, The Readme.txt file contains troubleshooting tips for installation problems.
  • If you cannot start Windows NT, or have installed new hardware and cannot access it, NTHQ might help you troubleshoot the problem. Because NTHQ enables you to view the hardware that it detects, you can find out if any devices are not being detected. For example, if you have not changed your configuration since the last time you produced an NTHQ report, run a new one and compare the results. If you find a difference, you might have a hardware problem.


Using the Windows NT Diagnostics Administrative Tool

You can use this program to display Registry information in an easily-readable format. The Windows NT Diagnostics Administrative Tool enables you to:

  • View information about the hardware connected to the computer.
  • Identify device drivers and services that should be started when you start the computer.

To run Windows NT Diagnostics

1. Click the Start button.

2. Click Programs.

3. Click Administrative Tools (Common).

4. Double-click Windows NT Diagnostics.

The information that you can view is organized into nine tabs. The next screen shot shows the kind of information that you see when you click the System tab.

These are the tabs that you can select in Windows NT Diagnostics:

  • Version shows operating system and hardware information, such as the number and type of processors.
  • System displays more details about the computer, including the type of processor and the Hardware Abstraction Layer (HAL). The System tab is shown in the preceding screen shot.
  • Display describes the video display and its driver.
  • Drives displays information about the disks connected to the computer, the partitions and logical drives on hard disks, and network shares.
  • Memory displays physical memory and page file information.
  • Services provides the status of all services and devices. It provides more information than is available by using the Services and Devices options in Control Panel.
  • Resources displays information about IRQs, I/O ports, DMA channels, and memory addresses.
  • Environment displays system and user environment settings.
  • Network displays user and network information.


Other Approaches to Troubleshooting Hardware Problems

If your hardware components are listed on the HCL, and you are still having problems, check that the physical connections are secure.

If you are using a SCSI device, check it termination. Even if you are sure the termination is correct, and you are having problems that could be due to incorrect termination, open the computer case and check again. You should use active rather than passive terminators whenever possible.

Note

Terminators are used to provide the correct impedance at the end of a cable. If the impedance is too high or too low, internal signal reflections can take place. These echoes represent noise on the cable, and can corrupt subsequent signals, which can result in degraded performance or data loss.

Passive terminators are resistors with the appropriate resistance value for the characteristic impedance of the cable. Active terminators are slightly more sophisticated electronics that are able to better maintain the correct impedance necessary to eliminate signal reflection.

Verify that the SCSI cables are not longer than they need to be. If a two-foot cable is long enough to connect the device to the controller, do not use a three-foot cable just because you have one available. The acceptable lengths vary depending on such factors as: whether you are using basic SCSI, SCSI-2, wide SCSI, ultra-wide SCSI, differential SCSI; the quality of the termination; and the quality of the devices being used. Consult your hardware documentation for this information.

Check your hardware configuration. I/O and interrupt conflicts that went unnoticed under another operating system must be resolved when you switch to Windows NT. Likewise, you must pay much closer attention to CMOS and EISA configuration parameters when using Windows NT.

The Knowledge Base is a good source of information for hardware problems. There are several articles about memory problems, memory parity errors, SCSI problems, and other hardware information in the Knowledge Base.

If your computer crashes randomly and inconsistently, you might have memory problems. On x86-based computers, you can use the /maxmem switch in your Boot.ini file to troubleshoot memory problems. Chapter 6, "Troubleshooting Startup and Disk Problems," contains more information about the /maxmem switch and video problems.


Troubleshooting Using HKEY_LOCAL_MACHINE

Problems can often be traced to services, device drivers, or startup control data. The Registry key HKEY_LOCAL_MACHINE contains this configuration information, so it is a good place to look for information to solve these types of problems. You have two Registry editors that you can use to look at information in the Registry:

  • Regedt32.exe has the most menu items, and more choices for the menu items. You can search for keys and subkeys in the Registry.
  • Regedit.exe enables you to search for strings, values, keys, and subkeys. This feature is useful if you want to find a specific value or string.

Most of the examples in this section use the Regedt32.exe. You see the following screen when you run Regedt32.exe:

The following table briefly describes the Registry keys.

Key | Description
HARDWARE | Describes the physical hardware in the computer, the way device drivers use that hardware, and mappings and related data that link Kernel-mode drivers with various user-mode code.
SAM | Contains security information for user and group accounts.
SECURITY | Contains the local security policy, such as specific user rights.
SOFTWARE | Describes the per-computer software.
SYSTEM | Controls system startup, device driver loading, Windows NT services, and operating system behavior.

The HARDWARE and SYSTEM keys are the most useful for troubleshooting.

Note

Do not change information in the Registry when you are using it for troubleshooting. Instead, use the options in Control Panel, such as Services, Devices, Network, and SCSI Adapters, to change Registry information.

The Registry information and examples in this section are for a Windows NT Server computer that uses the TCP/IP network protocol. It uses a DHCP server to get IP addresses. If your computer has a different configuration, or has third-party device drivers or services installed, the Registry will contain different information.


HKEY_LOCAL_MACHINE\HARDWARE

This key describes the physical hardware in the computer. Since the data in the HARDWARE key is stored in binary form, the best way to view the data are by using Windows NT Diagnostics, one of the programs in the Administrative Tools (Common) program group. See the section titled "Using the Windows NT Diagnostics Administrative Tool," presented earlier in this chapter, for more information about the program.

For more information about the HKEY_LOCAL_MACHINE\HARDWARE key, see Chapter 23 in the Windows NT Workstation Resource Guide, "Overview of the Windows NT Registry."


HKEY_LOCAL_MACHINE\SYSTEM

The HKEY_LOCAL_MACHINE\SYSTEM key contains information that controls system startup, device driver loading, Windows NT services, and operating system behavior. All startup-related data that must be stored (rather than computed during startup) is saved in the SYSTEM key. This screen shot shows the SYSTEM key and its subkeys.

The most important troubleshooting information in the Registry key HKEY_LOCAL_MACHINE\SYSTEM are the control sets. A control set contains system configuration information, such as which device drivers and services to load and start. There are at least two control sets, and sometimes more, depending on how often you change system settings, or have problems with the settings you choose. The preceding screen shot shows the following control sets:

  • Clone
  • ControlSet001
  • ControlSet002
  • CurrentControlSet

The Registry subkey HKEY_LOCAL_MACHINE\SYSTEM\Select identifies how the control sets are used, and determines which control set is used at startup. This subkey contains the following value entries:

  • Current. Identifies which control set is the CurrentControlSet. When you use Control Panel options or Registry editor to change the Registry, you are changing information in the CurrentControlSet.
  • Default. Identifies which control set will be used the next time you start Windows NT, unless you select Last Known Good Configuration. Default and Current typically contain the same control set number.
  • Failed. The control set that was pointed to by Default when a user last started the computer by using the LastKnownGood control set.
  • LastKnownGood. The control set that is a clean copy of the last control set that actually worked. After a successful logon, the Clone control set is copied to the LastKnownGood control set.

The next screen shot shows the value entries for the Select subkey.

Note

The Registry editors each display the Registry in a similar way. The window on the left contains the key and subkey names. The window on the right contains value entries. In the preceding screen shot, one value entry is Current : REG_DWORD : 0x1. In this example, Current is the name, REG_DWORD is the data type, and 0x1 is the value. These terms will be used in the rest of this section.

The values for the value entries in the Select subkey identify which control set is Current, Default, Failed, and LastKnownGood. For example, a value of 0x1 indicates that you should look at ControlSet001 to find the infromation.

In the preceding screen shot, Current and Default are both 0x1. Failed is 0, and LastKnownGood is 0x2.

Therefore, ControlSet001 is the Current and the Default control set. ControlSet001 will be the one modified if you make any changes by using options in Control Panel. ControlSet001 will be used for the Default control set the next time you start the computer.

ControlSet002 is the LastKnownGood control set. If you decide to use the Last Known Good control set to start the computer, Windows NT will use ControlSet002.

For more information about the use of the control sets, see:

  • Chapter 6, "Troubleshooting Startup and Disk Problems"
  • Chapter 19, "What Happens When You Start Your Computer," in the Windows NT Workstation Resource Guide
  • Chapter 25, "Configuration Management and the Registry," in the Windows NT Workstation Resource Guide
  • The online help file Regentry.hlp on the Windows NT Server Resource Kit CD


Finding Service and Device Dependencies

This section describes using information in the Control and Services subkeys to troubleshoot problems with your computer. The next screen shot shows the CurrentControlSet and its subkeys.

When you install Windows NT, it creates the Control and Services subkeys for each control set in HKEY_LOCAL_MACHINE\SYSTEM. Some information, such as which services are part of which group, and the order in which to load the groups, is the same for all Windows NT computers. Other information, such as which devices and services to load when you start your computer, is based on the hardware installed on your computer and the network software that you select for installation.

Each control set has four subkeys:

  • Control — Contains startup data for Windows NT, including the maximum size of the Registry.
  • Enum—Contains the Plug and Play hardware tree.
  • Hardware Profiles—Enables you to define different configurations for your computer and select the one you want to use at startup.
  • service drivers that can be loaded by the boot loader, the I/O Manager, and the Service Control Manager. It also contains subkeys describing which drivers are attached to which hardware devices, as well as the services that are installed on the system.

ServiceGroupOrder Subkey

You can see the order in which device drivers should be loaded and initialized by viewing the Registry subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder. Individual drivers that are members of a service group are loaded in this order:

  • System Bus Extender
  • SCSI miniport
  • Port
  • Primary disk
  • SCSI class
  • SCSI CDROM class
  • Filter
  • Boot file system
  • Base
  • Pointer Port
  • Keyboard Port
  • Pointer Class
  • Keyboard Class
  • Video Init
  • Video
  • Video Save
  • File system
  • Event log
  • Streams Drivers
  • PNP_TDI
  • NDIS
  • TDI
  • NetBIOSGroup
  • SpoolerGroup
  • NetDDEGroup
  • Parallel arbitrator
  • Extended base
  • RemoteValidation
  • PCI Configuration

"Service Groups," presented later in this chapter, lists drivers that are in each group.

Services Subkey

The Registry subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Service name controls how services are loaded. This section describes some of the value entries for this subkey, with an explanation of their values. The next screen shot shows the subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation and its value entries.

Figure 8.1. The Registry subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation

DependOnGroup

When a subkey has a value for the DependOnGroup value entry, at least one service from the group must be loaded before this service is loaded. This table shows services that have a value for DependOnGroup. The LanmanWorkstation service, shown in Figure 8.1, has a value for the DependOnGroup value entry.

Service | Depends on
Cdfs | SCSI CDROM Class
Cdrom | SCSI miniport
Disk | SCSI miniport
LanmanServer | TDI
LanmanWorkstation | TDI
LmHosts | Network Provider
NetBIOS | TDI
Parallel | Parallel arbitrator
Scsiprnt | SCSI miniport
Scsiscan | SCSI miniport
Sfloppy | SCSI miniport

DependOnService

This value entry identifies specific services that must be loaded before this service is loaded. The "Troubleshooting Example," presented later in this chapter, shows how you can use information in the DependOnService value entry to determine which services need to be started.

This table lists the services on the example computer that have a value for DependOnServices.

Service | Depends on |  |
Alerter | LanmanWorkstation |  |
Browser | LanmanWorkstation | LanmanServer | LmHosts
ClipSrv | NetDDE |  |
DHCP | Afd | NetBT | TCP/IP
Messenger | LanmanWorkstation | NetBIOS |
NetBT | TCP/IP |  |
NetDDE | NetDDEDSDM |  |
NetLogon | LanmanWorkstation | LmHosts |
Parallel | Parport |  |
Replicator | LanmanServer | LanmanWorkstation |

By knowing the dependencies, you can troubleshoot a problem more effectively. For example, if you stop the Workstation service, the Alerter, Messenger, and Net Logon services are also stopped, because they are dependent upon the Workstation service. If an error occurs when you try to start the Workstation service, any of the files that are part of Workstation service could be missing or corrupt. This is also why, if you start one of the services that depend on Workstation service, the Service Control Manager will automatically start the Workstation service if it is not already running.

ErrorControl

This value entry controls whether an error during the startup of this driver will cause the system to switch to the LastKnownGood control set. If the value is 0 (ignore, no error is reported) or 1 (normal, error reported), startup proceeds. If the value is 2 (severe) or 3 (critical), an error is reported and LastKnownGood control set will be used.

The ErrorControl value for LanmanWorkstation is 0x1, which indicates that if there was an error starting LanmanWorkstation, an error would be logged in the event log, but Windows NT would complete startup.

ImagePath

This value entry identifies the path and file name of the driver. You can use My Computer or Windows NT Explorer to verify the existence of the named file. The ImagePath for LanmanWorkstation is %SystemRoot%\system32\services.exe.

Start

This value entry determines when services are loaded during system startup. If a service is not starting, you need to know when and how it should be starting. Then look for the services that should have been loaded prior to this service. The values are described as follows:

Value | Meaning | Description
0 | Boot | Loaded by the boot loader (NTLDR or OSLOADER) during the startup sequence.
1 | System | Loaded at Kernel initialization during the load sequence.
2 | Auto Load | Loaded or started automatically at system startup.
3 | Load On Demand | Driver is manually started by the user or another process.
4 | Disabled | Driver is not to be started under any condition. If a driver is accidentally disabled, reset this value by using the Services option in Control Panel. File System drivers are the one exception to the Start value. They are loaded even if they have a start value of 4.

Type

The Type value entry helps you know where the service fits in the architecture. These are its possible values:

Value | Description
0x1 | Kernel device driver.
0x2 | File System driver, which is also a Kernel device driver.
0x4 | Set of arguments for an adapter.
0x10 | A Win32 program that can be started by the Service Controller and that obeys the service control protocol. This type of Win32 service runs in a process by itself.
0x20 | A Win32 service that can share a process with other Win32 services.

Many of the services that have a Type value of 0x20 are part of the Services.exe. For example, if your network protocol is TCP/IP, and you are configured to use a DHCP server to get IP addresses, these services that have a Type value of 0x20 are in the Services.exe:

  • Alerter
  • Browser
  • DHCP
  • EventLog
  • LanmanServer
  • LanmanWorkstation
  • LmHosts
  • Messenger
  • NtLmSsp
  • PlugPlay

These services are part of the Netdde.exe:

  • NetDDE
  • NetDDEdsdm
Services Groups

Many device drivers are arranged in groups to make startup easier. When device drivers are being loaded, Windows NT loads the groups in the order defined by ServiceGroupOrder. The next table shows which drivers are in each group.

Group name | Services |  |
BASE | Beep | KSecDD | Null
Boot Files System | Fastfat | Fs_Rec |
Event log | EventLog |  |
Extended Base | Modem Parallel | Scsiprnt | Serial
File System | Cdfs Msfs | Npfs | Ntfs
Filter | Cdaudio Changer | Diskperf Ftdisk | Simbad
Keyboard Class | Kbdclass |  |
Keyboard Port | i8042prt |  |
NDIS | EE16 | NDIS |
NetBIOSGroup | NetBIOS |  |
NetDDEGroup | NetDDE |  |
Network | Mup | Rdr | Srv
NetworkProvider | LanmanWorkstation |  |
Parallel Arbitrator | Parport |  |
PCI Configuration | PCIDump |  |
PlugPlay | PlugPlay |  |
Pointer Class | Mouclass |  |
Pointer Port | Busmouse | Inport | Sermouse
Port | none |  |
PNP_TDI | NetBT | Tcpip |
Primary Disk | Abiosdsk Atdisk | Floppy | Sfloppy
RemoteValidation | NetLogon |  |
SCSI CDROM Class | Cdrom |  |
SCSI Class | Disk | Scsiscan |
SCSI Miniport | Aha154x Aha174x aic78xx Always ami0nt amsint Arrow atapi BusLogic Cpqarray dac960nt dce376nt | Delldsa DptScsi dtc329x Fd16_700 Fd7000ex Fd8xx mitsumi mkecr5xx Ncr53c9x Ncrc700 Ncrc710 ncrc810 | Oliscsi Ql10wnt slcd32 Sparrow Spock T128 T13B tmv1 Ultra124 Ultra14f Ultra24f Wd33c93
SpoolerGroup | Spooler |  |
Streams Drivers | none |  |
System Bus Extender | Pcmcia |  |
TDI | Afd | DHCP |
Video | Ati Cirrus Dell_DGX Et400 Jazzg30 Jazzg364 Jzvxl484 | mga mga_mil ncr77c22 psidisp qv s3 tga | v7vram VgaSave wd90c24a wdvga weitekp9 Xga
Video Init | VgaStart |  |
Video Save | VgaSave |  |

Troubleshooting Example

This section describes using information in the DependOnGroup and DependOnService to find the cause of the following error message that you see after you log on.

You can use the Event Viewer to see which services or drivers did not start.

To run Event Viewer

1. Click the Start button.

2. Click Programs.

3. Click Administrative Tools (Common).

4. Double-click Event Viewer.

5. If the screen is displaying a log other than System Log, on the Log menu, click System.

The event log shows the following entries:

Sometimes, as you can see by the preceding System Log screen shot, several events are logged at approximately the same time. In this example, the newest event is entered at the top. Usually, if you look at the oldest event, you will find the reason that all of the events are logged. In the preceding example, the fourth entry from the top was the first one logged at 1:41:24. Double-clicking on it results in this event detail.

But if you look in the Registry there is no subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Workstation. You have two methods that you can use.

You can use Regedit.exe to find the name anywhere in the control set.

To use Regedit.exe to find the Workstation service

1. Click the Start button.

2. Click Run, and enter Regedit.exe.

3. Double-click HKEY_LOCAL_MACHINE, double-click SYSTEM, double-click CurrentControlSet, and click Services.

4. On the Edit menu, click Find.

5. In the Find what box, enter Workstation and check the Keys and Data checkboxes. Clear Match whole string only.

6. Click Find.

7. If the match is not what you are looking for, on the Edit menu, click Find Next until you find the correct key.

If you think that the service name is part of the key name, you can use the Windows NT Registry Editor.

To use Regedt32.exe to find the Workstation service

1. Click the Start button.

2. Click Run, and enter Regedt32.exe.

3. Double-click HKEY_LOCAL_MACHINE, double-click SYSTEM, double-click CurrentControlSet, and click Services.

4. On the View menu, click Find key.

5. In the Find what box, enter Workstation. Clear Match whole word only and Match case.

6. Click Find Next.

Both Registry editors find a match on the subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation. The DisplayName value entry contains the name that you see when you use the Services icon in Control Panel, or the Services tab in the Windows NT Diagnostics administrative tool, to view information about services.

Therefore, this subkey is the one you are searching for. Its Start value is 0x4, which means it is disabled. It should be set to 0x2, which indicates it would start automatically when you start Windows NT.

As it turns out, you specifically disabled the Workstation service by using the Services icon in Control Panel and setting the Startup Type to Disabled. Then, the computer was restarted to see what happened.

But what about the other errors that are in the event log? If you double-click each of the first three entries, you find the following descriptions:

The Messenger service depends on the Workstation service which
failed to start because of the following error. The specified service is disabled and cannot be started. The Computer Browser service depends on the TCP/IP NetBIOS
Helper service which failed to start because of the following error. The dependency group or service failed to start. The TCP/IP NetBIOS Helper service depends on the NetworkProvider
group and no member of this group started.

Changing the LanmanWorkstation service to start automatically will solve the problem with the Messenger service failing to start.

The Computer Browser and TCP/IP NetBIOS errors are both the result of no member of the NetworkProvider group starting. How do you find what services are in the NetworkProvider group? Regedt32.exe doesn't have an option to search for data, so you can use the Regedit.exe to find the NetworkProvider group.

To use Regedit.exe to find the NetworkProvider group

1. Click the Start button.

2. Click Run, and enter Regedit.exe.

3. Double-click HKEY_LOCAL_MACHINE, double-click SYSTEM, double-click CurrentControlSet, and click Services.

4. On the Edit menu, click Find.

5. In the Find what box, enter NetworkProvider and check the Data checkbox.

6. Click Find Next.

The only subkey that has a Group value of NetworkProvider is LanmanWorkstation. Changing LanmanWorkstation to start automatically will also solve these problems.


Identifying a Service or Driver That Doesn't Start

Some services are configured to start automatically on Windows NT. The specific services depend on your computer configuration, and which network services and protocols you are using.

You can use the Services option on Control Panel to view which services should have started automatically and see which ones did start. For example, the next screen shot was taken when the Workstation service was disabled.

You can see that TCP/IP NetBIOS Helper is configured to start automatically, but it did not start. The section "Troubleshooting Example," presented earlier in this chapter, describes why it did not start.

Sometimes, if a file that is needed to load or run Windows NT becomes corrupt or is deleted, the system displays a message about a problem with the file. You might also get information logged in the event log. You can use the message or the information in the event log to find the problem.

Not all executables or dynamic link libraries report missing or corrupt files, and the symptoms can be unpredictable with a file missing. What do you do if there is no indication of an error, but you think some component did not start correctly?

You can check to see if all the Windows NT system files exist and appear to be uncorrupted. Symptoms of file corruption include a file being an unusual size (for example, zero bytes or larger than its original size), or having a date or time that does not match the Windows NT installation date or dates on service packs that you have installed. You can compare files in your %systemroot%\System32 folder and subfolders with files in these folders on another computer that has the same Windows NT version and service packs installed.

If you think that you might be having a problem with a Windows NT system file, you can run Windows NT Setup and repair the problem by using the Verify Windows NT system files option.

If you can log on to your computer, you can use the Drivers utility on the Windows NT Server Resource Kit CD to display information about all the drivers that were loaded. If you have previously printed the output from the Drivers utility (by redirecting the output to a printer or a file), you can compare the previous output with one that you produce when you think you might be having problems with drivers not loading. Another method of determining if there are drivers missing from the list is to run the Drivers utility on a similar computer and compare the results.

The following table is a description of the output from the Drivers utility. The most important field is ModuleName, which is the name of the component.

Column | Definition
ModuleName | The driver's file name.
Code | The non-paged code in the image.
Data | The initialized static data in the image.
Bss | The uninitialized static data in the image. This is data that is initialized to 0.
Paged | The size of the data that is paged.
Init | Data not needed after initialization.
LinkDate | The date that the driver was linked.

To get a hardcopy of the output from the Drivers utility enter drivers >filename at the command prompt, and then print the file. The next example shows some of the output from a Drivers report.

ModuleName Code Data Bss Paged Init LinkDate ------------------------------------------------------------------------ ntoskrnl.exe 265472 39040 0 432128 76800 Mon Apr 15 16:28:07 1996 hal.dll 19904 2272 0 8992 10784 Wed Apr 10 10:24:22 1996 Atdisk.sys 12352 64 0 0 10368 Wed Apr 10 10:30:24 1996 Disk.sys 2304 0 0 7648 1504 Wed Apr 10 10:31:18 1996 CLASS2.SYS 6112 0 0 1472 1024 Thu Apr 11 09:21:58 1996 Ftdisk.sys 22880 32 0 1504 2048 Fri Apr 12 12:00:30 1996 Diskperf.sys 2048 0 0 0 768 Wed Apr 10 10:30:17 1996


How To Obtain the BackOffice and NT Server 4.0 Resource Kit Utilities CDs

While TechNet includes the full document set for the BackOffice and NT Server 4.0 Resource Kit, the utilities CDs are available separately from your local ordering center or subsidiary. This is due to the size of these utilities. We apologize in advance for any inconvenience this may bring and hope to have these utilities included in our regular editions in the future. In the meantime, TechNet subscribers in North America may order the BackOffice and NT Server Resource Kit Utilities CDs by calling 1-800-344-2121 and asking for the part number(s) shown below. There is a $10.00 (US) shipping and handling charge for each order.

Solution Providers: If you receive TechNet as a benefit of the Microsoft Solution Provider program, please calling 1-800- SOLPROV in the United States or your local subsidiary to order these parts.

If you want this Utilities CD… | Ask for this part number
BackOffice Resource Kit Utilities | 098-67156
MS Windows NT 4.0 Resource Kit Utilities CD | 098-67157

Outside of North America, you may obtain these CDs by calling your local subsidiary or (510) 275-0826 (Untied States). Local shipping and handling and other charges may apply.


Introduction

Welcome to the Microsoft® Windows NT® Server Resource Kit Supplement 1 book. The Supplement 1 book supports use of Windows NT Server with a network and the Internet, and provides answers about issues Microsoft product support people consider timely and important. The in-depth, technical information in this book builds on information in the documentation for the Windows NT Server version 4.0 operating system and in the Microsoft Windows NT Server Resource Kit version 4.0. Some Supplement 1 information also pertains to the Microsoft Windows NT Workstation Resource Kit version 4.0.

Supplement 1 includes a compact disc (CD) containing utilities for both Windows NT Workstation and Windows NT Server. The CD also provides an online version of the Windows NT Workstation Resource Kit: Windows NT Workstation Resource Guide.


About the Windows NT Server Supplement 1 Book

This book includes the following chapters and appendixes:

Chapter 1, "Securing Your Web Site," discusses how features of Microsoft Internet Information Server (IIS) version 2.0 and Microsoft Windows NT Server 4.0 can combine to protect your World Wide Web site against intruders.

Chapter 2, "Locating Network Resources," provides information about using a Microsoft Domain Name System (DNS) server to connect to the Internet and to identify your IIS sites for remote users.

Chapter 3, "Adding Bandwidth for Internet Connectivity," introduces the new Internet telecommunications infrastructure, describes how to estimate your network's bandwidth requirements, and explains how to evaluate different options for providing an IIS connection to the Internet.

Chapter 4, "Using ISDN," discusses how Windows NT Server provides built-in support for Integrated Services Digital Network (ISDN), a high-speed, fully digital telephone service you can use to connect to the Internet.

Chapter 5, "Monitoring Virtual Memory," describes how Internet Information Server uses the Windows NT virtual memory system and suggests techniques for determining whether your server has enough physical memory to operate efficiently.

Chapter 6, "Preventing Processor Bottlenecks," discusses some common causes of computer processor overload and several monitoring methods to avoid bottlenecks.

Chapter 7, "Monitoring Bandwidth and Network Capacity," examines bandwidth and network capacity on an Internet Information Server and suggests methods to measure and improve transmission rates and connection handling.

Chapter 8, "Effects of IIS Security Features on Performance," describes techniques to measure the performance overhead required by security features and ways to accommodate security requirements without impairing server performance.

Chapter 9, "Monitoring Dynamic Page Generation," covers techniques for monitoring the Common Gateway Interface (CGI) and Internet Server Application Programming Interface (ISAPI), which are used to generate dynamic Web pages on Internet Information Server.

Chapter 10, "Additional Network Services: Enterprise Level," describes the business reasons for selecting Directory Service Manager for NetWare and Web Administration for Windows NT Server at the fictitious Terra Flora Corporation, described in Windows NT Server Resource Kit: Windows NT Server Networking Guide.

Appendix A, "Major Revisions to Existing Resource Kit Books," supplements and corrects errors in the Windows NT Workstation Resource Guide and Windows NT Server Networking Guide, covering major changes that will not be incorporated into reprinted editions of these books.

Appendix B, "Minor Revisions to Existing Resource Kit Books," lists the changes to be incorporated into reprints of Windows NT Server Resource Kit and Windows NT Workstation Resource Kit books.

The Supplement 1 book also provides a glossary that consolidates several earlier Windows NT Resource Kit glossaries.


Resource Kit Compact Disc

The Supplement 1 CD contains information resources, tools, and utilities that make networking and working with Windows NT even easier than before. This new CD replaces all previous ones.

Note

The utilities on this CD are designed and tested for the U.S. version of Windows NT 4.0. Use of these utilities with any other version of Windows NT may cause unpredictable results.

Two major items included on the Supplement 1 CD are a Help file of Performance Monitor counter descriptions and a Help file with explanations and suggested user actions for the majority of the messages included in Windows NT 4.0. This Windows NT Messages Help file also includes new messages from various Windows NT components, including Internet Information Server and DNS.

Updates to these files and others will be provided, when available, on the Microsoft Web site for the Windows NT Resource Kits. For the exact site address, as well as the addresses of other Microsoft information sites, see the Rktools.hlp file.

After installing the Windows NT Server Resource Kit, please refer first to the following three files:

The Readme.wri file, which contains a complete list of all the tools and utilities on the Supplement 1 CD and additional setup instructions for some of them.

The Rkdocs.hlp file, which provides a single entry point for all of the major components of the Resource Kit's online documentation.

The Rktools.hlp file, which provides an overview of the Resource Kit tools and utilities and basic instructions on how to use many of them, along with links to additional documentation and, in some cases, to the program files.

The most current corrections to these tools and utilities and their documentation, as well as the POSIX and Perl source code files, are available on the Internet at the following Microsoft FTP site:

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt40/

The following notes describe some of the enhancements made to the existing tools and utilities, and introduce new tools and utilities added for this Supplement 1 release:

  • The Network Connections tool, Netcons.exe, enables you to click on a taskbar icon to view a list of all mapped network connections. You can double-click a listed connection to start an instance of a command prompt window or Windows Explorer.

  • The LinkCheck tool, Linkck.exe, tests all the hypertext markup language (HTML) links in a page, directory, or Web site. LinkCheck features a graphical user interface.

  • Microsoft Desktops, Desktops.exe, now includes an improved user interface along with a desktop creation wizard and other new features.

  • The second beta version of our Telnet Server, Telnetd.exe, provides major enhancements including an easier installation process, greater manageability, and improved performance.

  • The CACLS tool, Cacls.exe, now enables you to set from the command line all options offered through File Manager or Windows Explorer.

  • The telephony application programming interface (TAPI) Heartbeat Monitor tool, Tapihart.exe, monitors telephony servers. It checks to ensure the telephony server is functioning and provides basic usage information.

  • The Microsoft Index Server works with Windows NT Server 4.0 and Internet Information Server 2.0 to provide your organization with access to all documents stored on your intranet or Internet site. Using Index Server, you can perform full-text searches and retrieve all types of information from any Web browser in just about any format. You can also use Index Server to create customized query forms and search-results pages, optimize your query service, query in seven different languages, and write content filters. In addition, Index Server performs automatic self-maintenance.

  • The Windows NT Registry Entry Help file, Regentry.hlp, has been updated with new entries; see especially the entries for Internet Information Server.


Resource Kit Support Policy

The SOFTWARE supplied in the Windows NT Server Resource Kit is not officially supported. Microsoft does not guarantee the performance of the Windows NT Server Resource Kit tools, response times for answering questions, or bug fixes to the tools. However, we do provide a way for customers who purchase the Windows NT Server Resource Kit to report bugs and receive possible fixes for their issues. You can do this either by sending Internet mail to Rkinput@Microsoft.com or by referring to one of the options listed in the Windows NT Server Start Here book, which is included with your Windows NT Server product. This electronic mail address is only for Windows NT Server Resource Kit related issues.

The SOFTWARE (including instructions for its use and all printed and online documentation) is provided "AS IS" without warranty of any kind. Microsoft further disclaims all implied warranties, including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the SOFTWARE and documentation remains with you.

In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the SOFTWARE be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the SOFTWARE or documentation, even if Microsoft has been advised of the possibility of such damages.


Chapter 1 - Securing Your Web Site

A home page on the World Wide Web represents an open invitation to every Internet user. With the increase in numbers of corporate Web sites (a twofold increase from 1995 to 1996, according to International Data Corporation), technology professionals must learn to guard their networks against Internet-borne intruders.

A vigilant system administrator might feel safe in providing Gopher and File Transfer Protocol (FTP) services. But when implementing the World Wide Web (WWW) service, the system administrator has to confront several questions:

How secure is a corporate network that has a Web site?

Can someone on the Internet intercept and copy a user's ID and password?

Is a site that allows anonymous users truly secure?

This chapter answers these questions and describes how Windows NT Server and Internet Information Server (IIS) combine to provide a thoroughly integrated security solution for their Internet services.

This chapter focuses on Internet Information Server version 2.0 and Windows NT Server version 4.0 and includes the following sections:

"Using Built-in Windows NT Server Security"

"How Internet Information Server Security Works"

"Using Internet Service Manager Security Features"

"Using SSL to Safeguard Transmitted Data"

"Using Internet Services Application Program Interface (ISAPI) Security Functions"

"Guarding Against SYN Attacks"


Using Built-in Windows NT Server Security

Windows NT Server has powerful security features that protect server files against external attack. However, before setting up Internet Information Server, the Windows NT Server administrator should take these security steps:

Disable floppy disk booting.

Stipulate that users cannot share logons and passwords.

Follow proper password creation guidelines.

Rename the Administrator account and use the account lockout feature.

Keep the Guest account disabled.

Review user permission levels.

Implement a logon screen with a notice prohibiting unauthorized access and use.

You always need to explain to your users that they have security responsibilities. Users must have passwords and renew them at a set interval. You must make it known that users are not permitted to share user IDs and passwords. At the same time, you must also state that your network is meant for your company to conduct its business, and that any other use of its software and hardware is discouraged. Users should then acknowledge their responsibilities, either in a written or an electronic form. By doing this, you clearly demonstrate that your company is protecting its information assets. This acknowledgment helps you protect your company's right to legal recourse against anyone who causes malicious damage to its data resources. Legal notices on logon screens are a way that you can gain this important acknowledgment from external users. You should also post legal notices for Internet users on your Web page.

For more information on displaying legal notices for a user of Windows NT, see the section "Displaying a Legal Notice Before Logon" in Chapter 6, "Windows NT Security," in the Windows NT Workstation Resource Kit: Windows NT Workstation Resource Guide.


Windows NT Server Security Features

Windows NT Server incorporates the features found in the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) Division C Controlled Access Protection, called C2 for short.

Table 1.1 compares C2 criteria with Windows NT Server features.

Table 1.1 C2 Criteria and Windows NT Server Equivalent

C2 Criteria | Windows NT Server feature
Discretionary Access Control | Access Control List.
Object Reuse | NTFS-deleted files cannot be undeleted. Data in memory is not left behind to be reused.
Auditing | Windows NT Server logs identify users and actions.
User Identification and Authentication | Logon and password.
Protection | Memory and files are protected by NTFS; they cannot be accessed directly. Kernel runs in 32-bit protected mode.

For more information on how to set up your computer according to the TCSEC C2 requirements, see the Microsoft Windows NT Administrator's Security Guide.

Windows NT Server gives you comprehensive protection against Internet intruders at the file level with an Access Control List (ACL) and a user ID and password requirement. Other security features work behind the scenes to keep the data in your server's memory secure. Finally, you always have the ability to track users.


Access Control Lists (ACLs)

Windows NT Server protects information resources by requiring assigned user accounts and password authentication. A system administrator can control access to these resources by defining a user's access level. Perhaps the greatest advantage of integrating the Internet Information Server with Windows NT Server is that there is no need to duplicate a directory of user accounts. Internet Information Server uses the Windows NT Server directory database of user accounts.

In the Windows NT Server File System (NTFS), the system administrator adds a user to an Access Control List. The ACL allows the user to access a file, and at the same time, the ACL can prevent the user from copying or executing a file.

Note

Internet Information Server always uses the identity of the WWW or FTP client before attempting to access a file or program. (If anonymous access is being used, then the WWW server uses the IUSR_computername account.) For better security and flexibility than you can get with FAT partitions, use an NTFS partition for all Internet services ¾ WWW, FTP, and Gopher — and for all virtual directories.

Because client applications need access to server directories to load dynamic-link libraries (DLLs), an incorrectly configured Access Control List can result in unavailable files and resources. Therefore, when designing your IIS services, always keep in mind the full range of data files and DLLs that a user might need. If you set up directories that contain the necessary files for your users and assign the directory and folders the correct level of NTFS permissions, you can guarantee security while providing uninterrupted service to your users.


Access Control Entries (ACEs)

Each Access Control List is made up of Access Control Entries (ACEs). An ACE specifies that a user or group of users has access or auditing permissions for a file or resource. There are three ACE types — two for discretionary access control and one for system security.

The discretionary ACEs are AccessAllowed and AccessDenied. These explicitly grant and deny access to a user or group of users. NTFS always processes an AccessDenied ACE before an AccessAllowed ACE. The first AccessDenied ACE that denies a user access to a resource causes the ACEs to cease further processing.

The Windows NT Server operating system reserves system security ACEs for its own use. For example, SystemAudit is a system security ACE that Windows NT Server uses to log security events. These events range from identifying users who access particular files to generating and logging security audit messages.


How Internet Information Server Security Works

Internet Information Server security builds on the security available with Windows NT Server 4.0. Every connection request that Internet Information Server receives must undergo a rigorous, step-by-step validation process. The Internet Information Server security process is responsible for:

1. Checking the source IP address.

2. Identifying and authenticating Internet users.

3. Assigning logon modes.

4. Allowing access by using NTFS.

Figure 1.1 illustrates how this process works.

Figure 1.1 How Internet Information Server verifies each Internet connection request

In addition, Windows NT Server applications can have Common Gateway Interface (CGI) and ISAPI extensions that require additional logon and password requirements. (For more information on CGI and ISAPI, see "Using ISAPI Security Functions," later in this chapter.)

It is also important to note that each Internet service ¾ WWW, Gopher, and FTP ¾ has different security requirements. When you set up an Internet server, it is best to review which services you plan to provide and to install only those services.

For more installation and configuration information, see the Microsoft Internet Information Server Installation and Administration Guide. For a detailed discussion on Internet security, see Chapter 3, "Server Security on the Internet," in the Microsoft Windows NT Server Resource Kit: Windows NT Server Internet Guide.


Checking the Source IP Address

You can configure Internet Information Server to grant access to specific IP addresses and subnet masks. In this way, you allow only specific users to access your Internet server. At the same time, by specifying IP addresses, you can prevent entire networks or an individual site from accessing your server. This technique is especially useful to block an address from which you have logged a volume of suspicious activity.

Internet Information Server checks the source IP address of every received packet against the settings you specified on the Advanced tab of the WWW Service Properties dialog box. You can use that dialog box to set separate IP address access restrictions for each Internet Information Server service.

Note

If your Internet server is attached to a proxy server or firewall, your source IP address emanates from the proxy server or firewall. In such cases, your filter must distinguish an external source IP address from the source IP address of your firewall or proxy server. Set your system to log and restrict any incoming packet with an external source IP address that exactly matches your internal proxy server and firewall source address. Such packets usually indicate that an Internet user is "spoofing" (mimicking) your source IP address in an attempt to gain access to your network.


Configuring Internet Information Server IP Settings

Configuring your Internet server to grant or deny access to a specific source IP address or subnet mask is a simple procedure in Internet Information Server. And it provides a very effective first-level barrier against unauthorized users.

Û To configure the Internet Information Server IP settings

1. In the Internet Service Manager, choose the service. From the Properties menu, click Properties, and then click Service Properties. Click the Advanced tab. (For an example, see Figure 1.2.)

2. In the IP Address box, type the IP address or subnet mask to which you want to grant or deny access, then click Add.

3. Select Denied Access or Granted Access, then click OK.

Figure 1.2 Using the Advanced tab of the WWW Service Properties dialog box to grant or deny access

Although you can set access control for each Internet service by specifying an IP address, you cannot do so for individual virtual directories. If you need to set IP address restrictions on an individual virtual directory, you must either design an ISAPI filter or purchase one from a third party. An ISAPI filter can examine the request source's Uniform Resource Locator (URL), mapped directory path, or source IP address, and then grant or deny access to the virtual directory. For more information, see "Using ISAPI Security Functions," later in this chapter.


Identifying and Authenticating Internet Users

For successful user identification, authentication, and logon, Internet Information Server goes through a five-step process. During this process, Internet Information Server checks that:

1. The supplied user name and password are valid.

2. There are no specific account restrictions in place.

3. The account is not disabled or locked out.

4. The account password has not expired.

The user is following the correct logon protocol, either local or network.

Of the five situations listed above, the last — using an incorrect logon protocol — is the most common reason that a user cannot access the WWW or FTP service. (The Gopher service only requires anonymous authentication.) For more information on authentication, see Chapter 3, "Server Security on the Internet," in the Windows NT Server Internet Guide.


Assigning Logon Modes

On a computer running Windows NT Server, users who do not belong to the Administrators group also do not, by default, have the Log on Locally user right. In the case of FTP or WWW basic authentication, Internet Information Server attempts by default to log the user on as a local user. With Internet Information Server 2.0 or later, you can change the default logon method by changing the Registry setting, unless the Windows NT Challenge / Response option is checked in the Service Properties dialog box. (Although you should change system configuration by using administrative tools whenever you can, some logon mode settings can be changed only by modifying Registry values.)

Warning

To add or modify a Registry value entry, use administrative tools such as Control Panel or System Policy Editor whenever possible. Using a Registry editor (Regedit or Regedt32) to change a value can have unforeseen effects, including changes that can prevent you from starting your system.


Logon Modes in Internet Information Server

Registry value entries for the WWW service are located in the following Registry path:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\W3SVC
\Parameters

That value entry that controls logon is LogonMethod:

LogonMethod REG_DWORD 0 | 1 | 2

Table 1.2 explains what the numerical values for LogonMethod represent. (For more information on how logon modes work with authentication and user accounts in the IIS services, see Table 1.3, "Services, Authentication, Logon Mode, and Accounts," later in this section.)

Table 1.2 Logon Mode Registry Values

Value | Logon Mode | Definition
0 (default) | Log on Locally | A local user: logon password required.
1 | Log on as Batch | Similar to local, except the user is logged off after a process or thread completes.
2 | Log on as Network | Remote, network, user: accepts cryptographic verification.

Registry value entries for the FTP service are located in the following Registry path:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\MSFTPSVC
\Parameters

Registry value entries for the Gopher service are located in the following Registry path:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\GOPHERSVC
\Parameters


Allowing Access by Using NTFS

After a user logs on, Windows NT Server associates the user with a set of credentials. These credentials are used to create the user's Security Context. The Security Context defines the user's logon mode. The logon mode then determines how NTFS allows the user access to files. Windows NT Server supplies a special user account that corresponds to each Internet service.

Table 1.3 lists the default authentication methods and logon modes and their corresponding Windows NT Server user accounts.

Table 1.3 Services, Authentication, Logon Mode, and Accounts

Service | Authentication Method | Default Logon Mode | Windows NT User Account
WWW | None (Anonymous) | Local | WWW anonymous account (typically IUSR_computername)
WWW | HTTP Basic | Local | Specified by Web user
WWW | Windows NT Server challenge / response | Always network | Specified by Web user
WWW | Windows NT Server challenge / response (as a Guest account) | Local | WWW anonymous account if Guest access is enabled (typically IUSR_computername)
FTP | Anonymous | Local (Change to network recommended)* | FTP anonymous account (typically IUSR_computername)
FTP | FTP user name / password | Local (Change to network recommended)* | Specified by FTP user
Gopher | None (always Anonymous) | Local (Change to network recommended)* | FTP anonymous account (typically IUSR_computername)

* Preferred because Windows NT Server accepts cryptographic validation.

In the local and batch logon modes, Windows NT Server requires the user's actual password, except for anonymous accounts. In the network logon mode, Windows NT Server accepts cryptographic validation. To make sure that users with local and batch logon modes are configured correctly, you can create a new user group, such as Web Users, and grant the local and batch rights to that group.


Anonymous User Account

Anonymous authentication handles client requests that do not contain a user name and password. Each Internet Information Server service maintains a Windows NT Server user name and password for these anonymous requests. You can view and set an anonymous logon user account in the Internet Service Manager Service Properties dialog box.

During setup, Internet Information Server creates the IUSR_computername account for anonymous connections. For example, if the server name is SERVER1, the default anonymous user name is IUSR_SERVER1.

Internet Information Server Setup creates the same anonymous logon user account for all Internet services. But Internet services can use either the same anonymous account or different accounts.

In the Windows NT Server security model, every user account has a unique security ID (SID). Windows NT Server tracks permissions through the SIDs. Permissions are recorded within an Access Control List.

For anonymous requests, NTFS grants permission based on the request's Access Control List. If the ACL does not assign these permissions to the anonymous logon user, then the request fails. If the server file does not grant permissions to an anonymous user account, you can eliminate the chance that an intruder might access a server file by selecting only the Allow Anonymous option in the WWW Service Properties dialog box.

You can set the Internet Information Server WWW service to respond to failed anonymous requests by selecting the Windows NT Server Challenge / Response option in the Service Properties dialog box. In this case, the server asks for a Windows NT Server user name and password. An intruder can take advantage of this to gain access to a server.

Because the Gopher service offers a published menu, it requires only anonymous authentication. You should configure FTP and Gopher users for the network logon mode. However, the FTP and WWW services also provide file and data transfer, which requires a higher level of anonymous security.

Note

Do not use the network logon mode if you are using a remote SQL Server with Integrated Security, or any other second-level server that requires authentication. Although the network logon mode allows a user to access the primary Internet server, the primary Internet server is unable to authenticate the user for a remote or second-level server.


WWW Service Security

Servers that host Web sites allow Internet users to launch server applications and extract data. For the system administrator, the interaction between the client browser and the Web site presents the most challenging security problem.

Several scenarios can occur:

The WWW service receives a user name and password.

When the WWW service receives a client request with a user name and password, it does not use the anonymous logon user account. Instead, the WWW service first processes the user name and password. Then, if the service does not grant permission to access the requested resource, the service generates a message and sends it back to the client.

The WWW service receives an anonymous request that does not have specific permissions.

An anonymous WWW service request fails when the anonymous logon user account does not have permission to access the desired resource. The WWW service response to the client indicates which authentication scheme the WWW service supports. If the response indicates that the WWW service supports hypertext transfer protocol (HTTP) Basic authentication, most Web browsers display a dialog box in which the user can enter a name and password. The Web browser then reissues the request with credentials that include the user name and password.

The Web browser connecting to the WWW service supports Windows NT Server challenge/response.

The scenario is different when a Web browser supports the Windows NT challenge/response authentication protocol and the WWW service also supports this protocol. In this case, if an anonymous request to the WWW service fails because it lacks adequate permissions, the Web browser then automatically uses the Windows NT challenge/response authentication protocol. The browser sends a user name and encrypted password from the client to the service. The WWW service reprocesses this client request with the user name and encrypted password.

The WWW service supports basic authentication and Windows NT Server challenge/response.

A more complicated security process can occur when the WWW service supports basic authentication and Windows NT challenge/response. When this happens, the WWW service returns both authentication methods to the browser in a hypertext markup language (HTML) header. The browser reads the HTML header to choose an authentication method. If the header lists the Windows NT challenge/response protocol first and the browser supports this protocol, the browser uses it. A browser that does not support the challenge/response protocol uses basic authentication. Currently, Windows NT Server challenge/response authentication is supported only by Internet Explorer version 2.0 or later.


Using Internet Service Manager Security Features

You use the Internet Service Manager interface (shown in Figure 1.3) to administer WWW, Gopher, and FTP services.

Figure 1.3 Internet Service Manager

You can use the Internet Service Manager to administer security, and also to configure Secure Sockets Layer (SSL) keys and initiate secure communication through a WWW service connection.


Setting Security Properties

You can select an Internet service and change its properties; these properties include security options. The section "Checking the Source Address," earlier in this chapter, described how to configure Internet Information Server to check source IP addresses. In addition, you can specify in the Internet Service Manager Service Properties dialog box that passwords are encrypted before they are transmitted. Because the Windows NT security model is built into the Internet Service Manager, you can authorize users to administer your Internet services and you can authorize users to grant read and write permissions to directories.

Note

To keep others from viewing your directory structure and naming convention, leave the Directory Browsing Allowed box in the WWW Service Properties dialog box in its default, unselected mode.

The Service Properties dialog box contains a Logging property sheet that controls important aspects of your Internet server's log. You can set your log's format, either in a standard or National Center for Supercomputing Applications (NCSA) format. You can also set new logs to open automatically at specified intervals or when the log reaches a certain size. The log records valuable information about your Internet server, which includes a client's user name, IP address, and what operation the client performed on which computer. The log even records which files the client accessed.


Authentication Options

For the WWW service, you can choose any or all of these Internet Service Manager authentication options in the Service Properties dialog box:

Allow Anonymous

When you select this box, the WWW service processes anonymous connections and uses the anonymous logon user name and password for these connections. When you clear this box, the WWW service rejects all anonymous connections. In this case, the WWW service uses the basic or Windows NT challenge/response authentication protocol to access the resource.

Basic (clear text)

When you select this box, the WWW service processes requests by using basic authentication.

Warning

This check box is cleared by default for security reasons. Basic authentication sends Windows NT Server user names and passwords across the network without encryption.

Windows NT Challenge/Response

This box is selected by default. It sets the WWW service to use the Windows NT challenge/response protocol to honor requests by clients to send user account information. This protocol uses encrypted passwords for secure transmission. Windows NT challenge/response authentication works only with version 2.0 and later of Internet Explorer for Windows NT and Windows 95. For more details on when the server automatically uses challenge/response, see the "WWW Service Security" section earlier in this chapter.

The FTP service options include:

Allow Anonymous Connections

When you select this box, the user enters the user name "Anonymous." The FTP service processes these connections for the Windows NT user account specified in the FTP Service Properties dialog box. When you clear this box, users must enter valid Windows NT user names and passwords to log on to the FTP service.

Allow only anonymous connections

When you select this box, the FTP service rejects user logons with a user name other than Anonymous.

Warning

The FTP service sends Windows NT Server user names and passwords across the network without encryption. For security, this box is cleared by default.

Gopher services

The Gopher service allows only anonymous connections.


Using SSL to Safeguard Transmitted Data

Digital packets transmitted between Web browser and Web server by using Transmission Control Protocol/Internet Protocol (TCP/IP) are susceptible to unauthorized interception. In the case of anonymous access, such as in most Gopher or FTP service requests, this is not an issue. However, you usually secure your data transmission when you are conducting confidential business transactions that involve sensitive financial information or electronic correspondence.

There is no standard way to secure the FTP or Gopher service. You can use the Secure Sockets Layer protocol in Internet Information Server to transmit your encrypted information through the WWW service. This gain in security will cost processor performance, however.

The Secure Sockets Layer protocol provides data privacy, integrity, and authentication in a point-to-point connection between a Web browser and a Web server. Internet Information Server can send and receive private communication across the Internet with a browser that supports SSL. (SSL is based on a combination of public key and symmetric key cryptography, in addition to digital signature and certificate technology.)

Browser and server, although they have never before communicated with each other, can transmit encrypted data by using an agreed-upon method, a cryptographic key pair. By using digital signatures, each party can positively identify the other.

For international communications, you must limit your SSL key to 512 bits. The 1024-bit and 768-bit key options cannot be used internationally. For more information on SSL, see Chapter 3, "Server Security on the Internet," in the Windows NT Server Internet Guide, and the online Windows NT Server Microsoft Internet Information Server Installation and Administration Guide.

Both the browser and the server use an SSL security handshake to initiate a secure TCP/IP connection. The client and server agree on the level of security they will use and how to fulfill authentication requirements for their connection. After the handshake, the only role of SSL is to encrypt and decrypt the WWW service byte stream. The WWW service and the Web browser encrypt all the information in both request and response, including:

The URL the client is requesting.

Any submitted form contents, such as credit card numbers.

Any WWW service user names and passwords.

All data the server sends back to the client.

To maintain the performance level of your computer running Windows NT Server, consider using SSL only for highly sensitive information such as credit card transactions. Presently, SSL-encrypted transmissions are slower than unencrypted transmissions. As a consequence, Web server performance levels drop because of the encryption.

During the SSL session setup, browsers usually generate multiple threads reading from the server. This means that a client can initiate three or four session setups simultaneously that amount to nearly a quarter of a second of real processor time (3sessions x 85 milliseconds). During the SSL session setup, the initial private-key process takes approximately 85 milliseconds of real processor time for a 1024-bit key. Adding to this processor time are the interrupts for new packets and the input/output completion.

Once the server starts encrypting the stream back to the client, the overhead is 14 to 18 instructions per byte, depending on the architecture. Also, the maximum window size of an SSL encapsulated message is only 16K. The server cannot send larger, more efficient streams of data back to the client. Also, this SSL activity takes place in user mode, thus preventing the server from using TransmitFile or other fast APIs to send the data.

For more information on maximizing server performance, see Chapter 6, "Preventing Processor Bottlenecks," later in this book.


Using ISAPI Security Functions

The Internet Server Application Programming Interface (ISAPI) provides security functions for Windows NT Server and the Internet Information Server Database Connector. Because ISAPI figures prominently in Windows NT Server, this section discusses the advantages of ISAPI over the Common Gateway Interface (CGI), the differences between an ISAPI application and filter, and how to install an ISAPI filter in Windows NT Server.


CGI and ISAPI

The Common Gateway Interface is one method that a Web browser can use to run an application on your server. You can write a CGI application in a script and run it through a Perl interpreter; or you can compile the application in C/C++.

Windows NT Server relies on ISAPI instead of CGI as a method to efficiently request information from other applications. Unlike CGI, an ISAPI application exists as a dynamic-link library rather than an executable program. The ISAPI DLL is a communication pipe between Internet Information Server and an Internet service. The WWW service loads ISAPI DLLs when needed.

An ISAPI application can also take advantage of the Win32 API and the Open Database Connectivity (ODBC) standard. An ISAPI application provides better performance because it takes advantage of memory pointers and does not have to be restarted to process new data requests.

If multiple clients request dynamic content that can be supplied by one ISAPI DLL, then the WWW service loads the DLL only once. It unloads the DLL from memory if it goes unused for a long period. The advantage to loading an ISAPI DLL once is that the DLL is loaded in the WWW service process, and the Web server's performance improves when it does not have to switch among multiple processes. The Web server also does not need to create and destroy new processes.

When loaded, the ISAPI DLL code is part of the WWW service and the ISAPI application then acts as an extension.

The Internet Information Server works with two types of ISAPI DLLs:

ISAPI applications are add-ons that permit dynamic content generation and, when requested, explicit content generation. Explicit pages reside on a Web server; dynamic pages are not assembled until the client requests them. For more information, see Chapter 9, "Monitoring Dynamic Page Generation."

ISAPI filters add themselves to the path between the client and the server. An ISAPI filter modifies or monitors all input and output and is able to change the behavior of the server. (See Figure 1.4.)

Figure 1.4 The ISAPI filter can provide an additional security barrier


Installing an ISAPI Filter

Internet Information Server uses ISAPI filters to monitor HTTP transactions and to authenticate users. Before Internet Information Server can load these filters, they must be added to the W3SVC key in the Registry. After they are added, Internet Information Server loads these ISAPI filters automatically when the WWW service starts.

Û To install an ISAPI filter

1. Copy the filter DLL to an appropriate subdirectory, such as Scripts or Cgi-Bin.

2. Run Regedt32.exe.

3. Add the full path of the filter DLL to this Registry path:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\W3SVC
\Parameters
\Filter DLLs

Note

If there is more than one filter DLL file, separate them with commas. For example:

c:\Inetsrv\Server\Sspifilt.dll,c:\Inetsrv\Scripts\Myfilter.dll

The security precautions you must take for ISAPI Scripts subdirectories are similar to the permissions you have in place for Cgi-Bin subdirectories. Always review who has write permission to the ISAPI Scripts and Cgi-Bin subdirectories.


Guarding Against SYN Attacks

A SYN attack refers to an intruder proliferating SYN (synchronizing character) messages in a malicious attempt to deny users access to a server by generating an overwhelming amount of half-open Transmission Control Protocol (TCP) port connections.

You can prevent Internet "mail bombings" ¾ unwanted incoming mass electronic messages ¾ by judicious use of IP address settings and permissions. However, protecting your Web site against SYN attacks is not so simple.


How SYN Attacks Happen

In a normal message exchange, a client initiates access to your server by contacting your system. The client first sends a SYN message; your server responds to the client with a SYN-ACK message. Your server retains this half-open TCP port connection until the client returns an ACK (acknowledgment) message and establishes a connection.

A SYN attack (also called "SYN flooding") occurs when your server receives a SYN message with an incorrect source IP address. Your system responds with a SYN-ACK message and waits for an ACK reply that never arrives.

In the meantime, the intruder sends more SYN messages with incorrect IP addresses. Your server sets up a queue for each of these half-open connections.

Although your server can eventually become hindered in responding to legitimate users, these queues are small and do not necessarily place extraordinary demands on your server's processing capacity. But during a SYN attack, a given TCP port reaches its limit of half-open connections and, until resources are freed up, responds to further connection requests with a port reset. Thus, the intentional proliferation of half-open connections can prevent legitimate users from gaining access to the attacked server. This can shut down operations for an organization dependent on access by Internet, such as an Internet service provider.


How to Prevent SYN Attacks

SYN attacks take advantage of the Transmission Control Protocol and do not exploit any inherent weakness in Windows NT Server. SYN attacks are not harmful to your information resources, but they can tie up your Internet service in a destructive way.

To prevent SYN attacks, first you must ensure that your network is not a source of SYN attacks. To do this, set the filter attached to your proxy server or firewall to examine packets and prevent them from going out if their source address is not the same as your network address.

At the same time, make sure your Internet service provider has appropriate filters in place to discourage SYN attacks.

As part of system maintenance, it is a good idea to log activity on TCP ports. Then, if the volume of SYN requests dramatically increases, the administrator can deal with the problem before users report difficulty gaining access to resources.

If you suspect that your server is experiencing a SYN attack, at the command prompt type:

netstat -n -p tcp

An Active Connections report appears, which shows instances of SYN_RECEIVED connections. An abnormal amount of SYN_RECEIVED connections can indicate a SYN attack.

For the latest information on how you can use Windows NT Server to protect your Internet services against SYN attacks, search the Knowledge Base by using the keywords "SYN attack."


Chapter 2 - Locating Network Resources

The Internet is a collection of networks that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with other computers on the Internet. The Domain Name System (DNS) is used in TCP/IP networks to identify and locate shared network resources such as World Wide Web or e-mail servers by using host and domain names and IP addresses. You must use DNS if you connect your private intranet to the Internet, so remote users can access your Web, File Transfer Protocol (FTP), or Gopher server running under Internet Information Server and Windows NT Server version 4.0.

Microsoft DNS server is one of the TCP/IP networking services included in Windows NT Server. It enables you to provide and manage DNS services for intranets and the Internet. Microsoft DNS server is based on a client/server architecture using data records referred to as resource records to locate computers and other resources on TCP/IP networks.

This chapter is provided for network administrators and support personnel who need to administer Microsoft DNS servers to support networks that connect to the Internet. This chapter contains the following sections:

"Uniform Resource Locators, Names, and IP Addresses." This section describes how Internet computer addresses are formed.

"DNS Name Servers." This section describes DNS name servers, how DNS name servers manage domain name space, and the naming conventions Internet service providers (ISPs) offer.

"Using Microsoft DNS Server." This section provides some introductory information on Microsoft DNS server.

"Using DNS Manager to Configure Zones and Create DNS Resource Records." This section briefly describes DNS Manager, how to configure primary and secondary zones for Microsoft DNS server, and the different types of resource records and how to create them by using DNS Manager.

"Troubleshooting Microsoft DNS Server." This section offers some suggestions for solving problems with Microsoft DNS server.

This chapter supplements Chapter 9, "Managing Microsoft DNS Servers," in Microsoft Windows NT Server Resource Kit: Windows NT Server Networking Guide. If you need more information about DNS, the management of Microsoft DNS servers, or the integration of Microsoft DNS servers with Windows Internet Name Service (WINS) servers and Dynamic Host Configuration Protocol (DHCP) servers, see that chapter or the Windows NT Server Networking Supplement.


Uniform Resource Locators, Names, and IP Addresses

To allow remote users on the Internet to connect to computers on your intranet, for example a Web server running under Internet Information Server, you must use DNS, the name resolution service used on the Internet. While NetBIOS computer names and Windows Internet Name Service (WINS) are the name resolution service traditionally used in Windows-based TCP/IP networks, DNS is used on the Internet


Uniform Resource Locators

Every resource available to remote users over the Internet must have a location identifier referred to as a Uniform Resource Locator (URL). The URL is a naming convention that uniquely identifies the location of a computer, directory, file, or document on the Internet. A basic URL identifies a computer that contains directories, documents, or files. For example, the URL for a Web server at Microsoft looks like this: http://www.microsoft.com.

A URL is composed of several pieces of information. The first part of the URL indicates the TCP/IP-based protocol used to access the remote computer. For Web servers, the URL starts with http:, because hypertext transfer protocol (HTTP) is the protocol used to access Web servers. For FTP servers, the URL starts with ftp:, because FTP is the protocol used to access FTP servers.

The second part of the URL is composed of the DNS host name, enterprise or organization domain name, and an Internet domain name. The second part of the URL looks like this: www.microsoft.com, where www is the host name or host alias,microsoft is the enterprise domain name, and com is the top-level Internet domain name.

A complex URL that connects your computer to a specific document or file has more than these two parts and includes directory and document names. For example, the URL used to connect to an article published for small businesses on the Microsoft Web server looks like this:

http://www.microsoft.com/technet/analpln/smallbiz/sbnisp.htm#What's_an_ISP?2


Host and Domain Names

As previously described, the second part of a basic URL used to connect to a specific computer includes the DNS host name, the name of the enterprise or organization domain in which the intranet server is located, and the name of the top-level Internet domain in which the enterprise is registered.

DNS is based on a conceptual hierarchical structure called the domain name space. The root or topmost level of the domain name space is managed by the Internet Network Information Center (InterNIC). In the United States, there are seven domain name servers providing name resolution services at the root level. When you install Microsoft DNS server, the Internet Protocol (IP) addresses of these root name servers are made available in a file named cache.dns.

Under the top-level domains are additional groupings referred to as second-level domains. Second-level domains can also be divided into other, lower levels with additional domains, which themselves can be subdivided into more lower-level domains, and so on.

One of the top-level domains of the Internet is the .com domain, a commercial domain used mainly within the United States. Contained within the .com domain are second-level domains that contain the enterprises registered with InterNIC as part of the .com domain. The names of each of these second-level domains identify the enterprise connected with that particular domain; for example, the domain name microsoft.com identifies the domain containing all computers that exist within Microsoft Corporation.

Individual computers exist within a domain. Each computer in the domain must have its own name, referred to as the host name. The combination of a host name, the enterprise domain name, and the Internet top-level domain name creates a name that is unique across the Internet. This unique name is referred to as the fully qualified domain name (FQDN). Each part of the FQDN is joined to the others by using the . character (the period, also referred to as a dot), creating a name that looks like this: www.microsoft.com.


IP Addresses

To participate on the Internet, every workstation and server computer must have a unique FQDN, and this FQDN must be mapped to a unique IP address. If a computer is multihomed, meaning that it is associated with more one IP address, each of the computer's IP addresses also must be unique.

TCP/IP, the protocol used throughout the Internet, is a routeable protocol, meaning that data can be passed, or routed, from one TCP/IP network to another. The intermediary devices that connect networks, referred to as routers, use IP addresses, rather than friendly names such as www.microsoft.com. The IP addresses provide routers an efficient method for locating computers and for addressing messages (in the form of IP packets) between computers. Therefore every device attached to a TCP/IP network must be identified by a unique IP address.

An IP address is a structured 32-bit number divided into four numeric fields separated by the . character (the period, also referred to as a dot), for example 172.46.8.34. Each of the four numeric fields is a byte (8 bits) in length. Each field can represent some number between 0 and 255; 255 is the maximum value that can be expressed by using 8 bits.

The four fields of an IP address represent two pieces of information, the network ID and the host ID of a computer. The network ID identifies a physical network. All computers on the same physical network must have the same network ID, and the network ID must be unique throughout the Internet. The host ID identifies a workstation, server, router, or other TCP/IP device. Each computer connected to a TCP/IP network must have a host ID.

Your intranet network administrator or Internet service provider (ISP) must provide a host ID and network ID for each computer that connects to the network. This IP address can either be manually configured or dynamically assigned by using Dynamic Host Configuration Protocol (DHCP) servers.

To connect your intranet to the Internet, you can obtain an allocation of network IDs for your enterprise computers by contacting either your ISP or the following regional Internet Registries:

InterNIC, the regional Internet Registry for the United States. Contact InterNIC at http://www.internic.net/.

Reseaux IP Europeene (RIPE) NCC, the regional Internet Registry for Europe. Contact RIPE NCC at http://www.ripe.net/.

Asia-Pacific Network Information Center (AP-NIC), the regional Internet Registry for Asia-Pacific. Contact AP-NIC at http://www.apnic.net/.


DNS Name Servers

In Internet terminology, computers referred to as name servers provide services that maintain name- to-IP address mappings. These DNS name servers provide this information to client computers and programs that need to connect to other computers on a network.

When a user types a URL into an Internet browser, the browser first contacts a DNS name server to resolve the host and domain name portion of the URL to an IP address. After the DNS name server returns the name-to-IP address mapping, the browser can connect to the remote computer by using the IP address.

The Internet implementation of DNS distributes the responsibility for maintaining name-to-IP address mapping to DNS name servers located throughout the Internet. Each DNS name server on the Internet manages only a portion of the domain name space and is said to be authoritative for only that portion it manages. In other words, each DNS name server only maintains DNS data for the domain for which it is authoritative and no other.

When other name servers on the Internet need name-to-IP address mappings, they contact the authoritative name server for names of any computers contained within the domain for which the server is authoritative. This process allows the DNS data and management of that data to be distributed across the Internet.

A DNS name server can manage an entire domain or one or more subdomains by using administrative groupings referred to as zones. A zone is an administrative and DNS server database grouping used to manage all or part of an enterprise domain. If the domain is large (containing many subdomains and computers) the domain authoritative name server can delegate management of parts of the domain to one or more other DNS name servers.


Primary and Secondary DNS Name Servers

Each zone must be managed by using at least one primary and one secondary DNS name server. A primary name server contains the original name- to - IP address mappings in a zone file located on the local computer. A secondary name server contains a copy of the zone's name- to - IP address mappings. It receives this copy from a master name server, either the primary server or some other secondary DNS server.

Note

Although a secondary name server can receive its zone data from another secondary name server, this configuration is not recommended. It is recommended that a secondary name server receive the zone data from a primary zone server. For more information, see Request for Comments (RFC) 1912, "Common DNS Operational and Configuration Errors." RFCs are the official documents of the Internet Engineering Task Force (IETF) specifying the details for TCP/IP protocols.

Using both a primary and a secondary server is required to provide database redundancy and a degree of fault tolerance. Providing a primary and a secondary DNS name server is also a requirement for domain registration with InterNIC.

If you establish a site on the Internet and register your enterprise with InterNIC, you must provide information about both your primary and secondary name servers. InterNIC established this requirement to ensure registered domains can always provide the name- to - IP address mappings needed for Internet connectivity. For more information about primary and secondary DNS servers, see later sections of this chapter.

Note

For more information about InterNIC registration requirements, contact the InterNIC registration site at: http://www.internic.net/.


Using a DNS Name Server Provided by an Internet Service Provider

If you connect your enterprise to the Internet, you are using an Internet service provider (ISP). ISPs can be large corporations, such as telephone companies, or small businesses that provide specialized services. In any case, ISPs can provide more than the telecommunication link to the Internet.

The services ISPs can provide include DNS servers and databases. You can choose to use only DNS servers and services provided by your ISP, only your own enterprise DNS name servers, or some combination.

If yours is a small enterprise, perhaps using a single computer running Windows NT Server with Internet Information Server, you may want to use only the DNS services and technical experience provided by your ISP. An ISP can help you choose and register your enterprise domain with InterNIC and maintain DNS servers and resource records with your enterprise computers' name- to - IP address mappings.

The domain name options that an ISP can offer your company's Internet site include the following:

yourcompany.ISPname.com. This form means your enterprise is a subdomain in the ISP enterprise domain.

yourcompany.com. This form means your enterprise is its own domain and is not a subdomain of any other enterprise.

Many enterprises prefer the second option because such a name identifies an enterprise as a second-level enterprise. The second option also allows flexibility in choosing an ISP. If you use the second option, you do not need to change and reregister the enterprise domain if you later switch to a different ISP.

If you choose to provide your own DNS server and services and use your ISP only for a telecommunications link, you are responsible for administering the DNS server and database files that contain the name-to-IP address mappings for computers in your intranet domain. You must create name-to-IP address mappings for any computer that has a static IP address (that is, a permanent IP address). Such computers include any Windows NT Server computer configured with Internet Information Server with services that will be accessed by users on the Internet.

Note

If you are using dial-up networking to connect to your ISP, see the section "Configuring Dial-Up Networking for ISP DNS," later in this chapter.


Using Microsoft DNS Server

Microsoft DNS server for Windows NT Server version 4.0 is an RFC-compliant DNS name server based on a client/server architecture. Because Microsoft DNS server is an RFC-compliant name server, it can be used with other DNS name servers such as UNIX-based DNS name servers as either a primary or secondary name server.

You can install Microsoft DNS server on a computer running Internet Information Server or on any computer running Microsoft Windows NT Server 4.0.

Note

If you choose to use some combination of your intranet and your ISP's DNS name servers to provide the primary and secondary name servers required by InterNIC, you must correctly add and configure the ISP DNS servers and zones in Microsoft DNS server using DNS Manager. For more information on how to do so, see "Configuring Primary and Secondary Servers and Zones," later in this chapter.

A computer configured with Microsoft DNS server can manage one or more zones and zone databases. You also can create up to a maximum of 15 virtual DNS servers on a multihomed computer configured with Microsoft DNS server. The Microsoft DNS server support for zones and virtual DNS servers enables you to configure your computers in the fashion that best supports your business and networking requirements.

DNS name server zone files contain name-to-IP address mappings and other identifying information (such as a host alias name) in data records referred to as resource records. These resource records must be created for any computer in a zone that has a static IP address and that is a resource for users on the Internet.

Note

Resources that are frequently used by remote users on the Internet are manually assigned static IP addresses. However, the interoperability of Microsoft DNS server and Microsoft WINS servers enables you to dynamically create IP addresses for your intranet computers by using Microsoft DNS, Microsoft WINS, and DHCP servers. For more information, see Chapter 9, "Managing Microsoft DNS Servers," in Windows NT Server Networking Guide.

To help you create and edit resource records and perform other DNS server management tasks, Microsoft DNS server provides DNS Manager. DNS Manager is automatically installed when you install Microsoft DNS server. DNS Manager eliminates the need to manually edit text files and enables you to create a full range of DNS resource records.


Using DNS Manager to Configure Zones and Create DNS Resource Records

DNS Manager is automatically added to Administrative Tools on the Program menu when you install Microsoft DNS server on a computer running Windows NT Server 4.0. You use DNS Manager to administer local and remote Microsoft DNS servers and to create the resource records that provide name resolution information and support connectivity for remote users on the Internet and TCP/IP intranets.

Û To start DNS Manager

1. Click the Start button.

2. Point to Programs.

3. Point to Administrative Tools.

4. Click DNS Manager.

The tasks you can perform using DNS Manager include the following:

Adding DNS servers for local server, remote server, and virtual server management.

Configuring server properties.

Configuring primary and secondary zones.

Configuring transfer of data between primary and secondary zones. Such transfer of data is referred to as a zone transfer.

Adding A (address) records with host name-to-IP address mappings for computers in the zone that are assigned static IP addresses. For more information on different resource record types, see Table 2.1, "DNS Resource Record Types," later in this chapter.

Adding PTR (pointer) records with IP address - to - host name mappings. (Each PTR record must have a corresponding A record and vice versa.)

Adding CNAME (alias), MX (mail exchange), and other resource records as needed.

Monitoring usage of DNS servers by using DNS Manager statistics.

Editing and maintaining zone configurations and resource records as needed.

For a more complete list of the tasks and procedures you can perform by using DNS Manager, see the "How To" topic in Microsoft DNS Manager Help.

Note

You cannot administer or create resource records on non-Microsoft DNS servers by using DNS Manager. To administer such records, use a text editor or the tool provided by the non-Microsoft DNS server.


Configuring Primary and Secondary Zones

With DNS Manager, you can add or change Microsoft DNS servers and the zones managed by those servers. It is important to note that when creating the primary and secondary servers required for Internet connectivity, you must first define and configure a server by using DNS Manager. You then define one or more zones managed by that server.

The generally used reference to primary and secondary DNS servers is actually misleading when applied to the actual configuration and operation of DNS name servers. Because each DNS server manages its portion of the domain name space using the administrative grouping of a zone, data on the server is stored in zone files.

When data is transferred between primary and secondary servers, it is the zone files that are transferred. Microsoft DNS server is designed to incorporate this operational characteristic by assigning the primary or secondary characteristic to the zone file. In other words, the designation of primary or secondary data source is configured on a zone-by-zone basis and not a server-by-server basis. You configure zone properties to create the primary or secondary data files.


An Example Configuration of Primary and Secondary Zones

The following procedures provide an example of how to add a Microsoft DNS server and primary and secondary zones. This example assumes that the server managing the primary zone is configured on the local computer and that the server managing the secondary zone is located on a remote computer in the same network that is configured with Microsoft DNS server. In addition to illustrating zone concepts, this example also illustrates that you can manage multiple computers configured with Microsoft DNS server from one central computer configured with Microsoft DNS server.

Û To add the Microsoft DNS server that will manage the primary zone

1. In DNS Manager, double-click the Server List icon.

2. On the DNS menu, click New Server, and in the Add DNS Server dialog box enter either the DNS server host name or the IP address.

3. Click OK.

DNS Manager automatically creates the new server icon in the right pane of the DNS Manager window.

Û To configure server properties

1. Right-click the server icon, and click Properties.

2. Click the Interfaces tab.

3. Type an IP address, and click Add.

4. Repeat until all IP addresses configured on the server are entered. You can enter only a maximum of 15 IP addresses, even if the computer is a multihomed computer configured to support more than 15 IP addresses.

If you do not specify IP addresses on the Interfaces tab and the computer is a multihomed computer configured with more than 15 IP addresses, you might encounter Event 410 or 520 errors. These errors occur in part because if no IP addresses are specified, by default Microsoft DNS Manager attempts to monitor all IP addresses configured on the server computer.

5. If you are using a DNS forwarder to control access to the Internet, click the Forwarders tab, and enter the IP address of the Microsoft DNS server that is designated as the forwarder.

6. Click OK.

Û To add a server on the local computer that represents a remote computer configured with Microsoft DNS server

1. In DNS Manager, double-click the Server List icon.

2. Click New Server, and in the Add DNS Server dialog box enter either the DNS server host name for the remote computer or its IP address.

3. Click OK.

DNS Manager automatically adds a new server icon that represents the remote server in the right pane of the DNS Manager window.

If you follow the preceding procedures for a local and a remote server, the servers are added to DNS Manager on the local computer. For the sake of brevity in this example, configuration of the remote server properties is not presented. The next procedures in this example show the creation of primary and secondary zones.

Note

Before creating a zone, make sure you have correctly configured TCP/IP Properties by entering the correct host name and domain name for the local computer on the DNS page in the Microsoft TCP/IP Properties dialog box. To reach this dialog box, click the Start button, point to Settings, and click Control Panel. Double-click the Network icon, click the Protocols tab, click TCP/IP Protocol in the Network Protocols list, and then click Properties.

Û To add a primary zone

1. Right-click the local server icon, and click New Zone to start the zone wizard.

2. Click Primary, and then click Next.

The zone wizard prompts you for additional information and then automatically creates the zone and zone file and adds SOA, NS, and A data records to the zone file.

Tip

To create a reverse-lookup zone, use this same procedure and use a zone name that complies with the reverse-lookup name format (nnn.nnn.nnn.in-addr.arpa). For example, the reverse-lookup zone to contain PTR records for IP addresses 172.16.16.1 through 172.16.224.254 would be named .16.172.in-addr.arpa.

Whenever possible, create a reverse-lookup zone for each zone before adding A records for computers contained in that zone, so that you can use the automatic Create PTR Record option in the Add Host dialog box.

Û To add a secondary zone

1. Right-click the remote server icon, and click New Zone to start the zone wizard.

2. Click Secondary, and enter the requested information.

3. Click Next.

The zone wizard prompts you for additional information and then automatically creates the zone and zone file and adds the SOA, NS, and server A records to the zone file.

After you have successfully added a zone, you can perform additional configuration by changing the zone properties as described in the following list:

Change the zone from a primary to secondary, or vice versa, by using the General tab.

Modify the default server time-to-live (TTL) values, by using the SOA Record tab.

Modify the refresh and zone transfer rates, by using the SOA Record tab.

Configure the primary zone server to automatically notify the secondary zone server when changes are made to the primary zone files, by using the Notify tab.

Configure the zone server to use WINS for host name resolution, by using the WINS Lookup tab. On a reverse-lookup zone, this tab is labeled WINS Reverse Lookup.

The following figure illustrates the Zone Properties dialog box for a normal zone.

Figure 2.1 Zone Properties dialog box

The only difference in the Zone Properties dialog box for a reverse-lookup zone is the text on the WINS Lookup tab, as illustrated in the following figure.

Figure 2.2 Zone Properties dialog box for reverse-lookup zone


Adding Resource Records

After you create a zone, you can add A, PTR, and other resource records for computers logically contained within the zone. To display a menu of actions that you can perform on the zone, point to the zone folder and right-click.

The two menu commands you can use to add information about the computers in the zone are New Host and New Record.

Figure 2.3 Zone Menu

You must use the New Host command to add A and PTR records for the zone computers that have statically assigned IP addresses. The A resource record provides the name-to-IP address mapping used in name resolution. The PTR resource record contains the reverse look-up (IP address - to - name) mapping that is needed by some programs.

The following figure illustrates the New Host dialog box.

Figure 2.4 New Host dialog box

You use the New Record command to add other types of DNS resource records such as CNAME (alias), MX (mail exchange) or ISDN records.

The following figure illustrates the New Resource Record dialog box.

Figure 2.5 New Resource Record dialog box

The following table lists the types of resource records you can create and edit by using DNS Manager.

Table 2.2 DNS Resource Record Types

Record type | Description
A | An address record that maps a host name to an IP address in a DNS zone. Its counterpart the PTR resource record is used to map an IP address to a host name in a DNS reverse lookup zone (those in the in-addr.arpa. DNS domain). It's important you add an A record for every computer in the zone that has a static IP address, including the local DNS name server and any computer running Internet Information Server.
AFSDB | An address record that gives the location of either an Andrew File System (AFS) cell database server or a Distributed Computing Environment (DCE) cell's authenticated name server. The AFS system uses DNS to map a DNS domain name to the name of an AFS cell database server. The Open Software Foundation's DCE Naming service uses DNS for a similar function.

Table 2.2 DNS Resource Record Types (Continued)

Record type | Description
CNAME | A canonical name resource record, which creates an alias for the specified host name (that is, a name synonymous with the host name). You can use CNAME records to hide the implementation details of your network from the clients that connect to it. For example, in the Terra Flora case study used in the Windows NT Server Resource Kit, ftp.terraflora.com is an alias (that is, a CNAME) for the real name of the computer that runs the Terra Flora FTP server. A CNAME or alias also allows the FTP server to be moved easily to a different computer if necessary. If such a move is required, only the CNAME record need change, not the actual computer name.
HINFO | The host information resource record, which identifies a host's hardware type and operating system. The CPU type and operating system identifiers used in an HINFO record should come from the list of computer and system names in RFC 1700.
ISDN | The Integrated Services Digital Network (ISDN) resource record, a variation of the A resource record. Rather than mapping a host name to an IP address, the ISDN record maps the host name to an ISDN address. An ISDN address is a phone number that consists of a country code, an area code, a local phone number, and optionally a subaddress. Use the ISDN resource record in conjunction with the RT resource record, described following.
MB | The mailbox resource record. This record, which is experimental, specifies a DNS host with the specified mailbox. Other related experimental records are the MG resource record, the MR resource record, and the MINFO resource record, all described following.
MG | The mail group resource record. This record, which is experimental, specifies a mailbox that is a member of the mail group (that is, mailing list) specified by the DNS domain name. Other related experimental records are the MB resource record, the MR resource record, and the MINFO resource record.
MINFO | The mailbox information resource record. This record, which is experimental, specifies the mailbox that is responsible for a specified mailing list or mailbox. Other related experimental records are the MB resource record, the MG resource record, and the MR resource record.
MR | The mailbox rename resource record. This record, which is experimental record, specifies a mailbox that is the proper rename of the other specified mailbox. Other related experimental records are the MB resource record, the MG resource record, and the MINFO resource record.

Table 2.2 DNS Resource Record Types (Continued)

Record type | Description
MX | The mail exchange resource record, which specifies a mail exchange server for a DNS domain name. A mail exchange server is a host that will either process or forward mail for the named DNS domain. Processing mail means either delivering it to the addressee or passing it to a different type of mail transport. Forwarding the mail means sending it to its final destination server, sending it by using Simple Message Transfer Protocol (SMTP) to another mail exchange server closer to its final destination, or queuing it for a specified amount of time.
NS | The name server resource record, which identifies the DNS server or servers for the DNS domain. NS resource records appear in all DNS zones and reverse zones (those in the in-addr.arpa DNS domain).
PTR | The pointer resource record, which maps an IP address to a host name in a DNS reverse zone (those in the in-addr.arpa DNS domain). Its counterpart, the A (address) resource record, is used to map a host name to an IP address in a DNS zone.
RP | The responsible person resource record, which indicates who is responsible for the specified DNS domain or host. You can specify multiple RP records for a given DNS domain or host. The record has two parts: an e-mail address in the same DNS format as the one in the SOA resource record, and a DNS domain name that points to additional information about the contact.
RT | The route through resource record, which specifies an intermediate host that routes packets to a destination host. The RT record is used in conjunction with the ISDN and X.25 resource records. It is syntactically and semantically similar to the MX record type and is used in much the same way.
SOA | The start of authority resource record, which indicates that this DNS server is the authoritative source of information for the data within this DNS domain. The SOA resource record is the first record in each of the DNS database files. It is created automatically by DNS Manager when you create a new DNS zone.
TXT | The text resource record, which associates general textual information with an item in the DNS database. A typical use is for identifying a host's location (for example, "Location: Building 26S, Room 2499"). The text string must be less than 256 characters, but you can associate multiple TXT resource records with one item.
WINS | A record that contains the IP address of the WINS server configured on this DNS Server for WINS name resolution. A WINS record is automatically created by configuring a zone property for WINS lookup. In other words, it is not created by using the Add Record command in DNS Manager.

Table 2.2 DNS Resource Record Types (Continued)

Record type | Description
WINS_R | A record that instructs Microsoft DNS server to use a NetBIOS node adapter status (nbtstat) command to resolve a DNS client reverse-lookup query. The reverse-lookup query requests the name of a computer identified only by an IP address. A WINS_R record is automatically created by configuring a zone property for WINS reverse lookup. In other words, it is not created by using the Add Record command in DNS Manager.
WKS | The well-known service resource record, which describes the services provided by a particular protocol for a particular interface. The protocol is usually TCP or User Datagram Protocol (UDP) but can be any of the entries listed in the Protocols file (Systemroot\System32\Drivers\... \Protocol on the drive where your Windows NT Server system files reside). The services described are the services listed below port number 256 in the Services file (\Systemroot\System32\Drivers\...\Services).
X.25 | The X.25 resource record is a variation of the A resource record. Rather than mapping a host name to an IP address, the X.25 record maps the name to an X.121 address. X.121 is the International Standards Organization (ISO) standard that specifies the format of addresses used in X.25 networks. The X.25 resource record is designed for use in conjunction with the RT resource record.

All of the resource records listed in the preceding table are commonly used by DNS name servers on the Internet except for the WINS and WINS_R resource records. These records are specifically implemented for interoperability between Microsoft DNS servers and Microsoft WINS servers.

Because these records are unique to Microsoft DNS servers, when transferring primary zone files to a secondary zone, these records should not be copied to a DNS name server running non-Microsoft DNS server software.

If you are using WINS lookup or WINS reverse lookup with a non-Microsoft DNS server, use the following procedure.

Û To prevent copying WINS or WINS_R records to a non-Microsoft DNS server

1. Start DNS Manager.

2. Right-click the folder for the appropriate zone.

3. Click Properties.

4. Click the WINS Lookup or WINS Reverse Lookup tab.

5. Select the Settings only affect local server check box.

6. Click OK.

The remaining sections of this chapter provide information about using the New Host and New Record commands to provide the information that allows remote users to locate your Internet Information Server and Web, FTP, and Gopher services.


Resource Records for Web, FTP, and Gopher Services

As noted in the online Windows NT Server Microsoft Internet Information Server Installation and Administration Guide, to allow remote Internet users to access information on a computer configured with Internet Information Server (IIS), you must use a static IP address for that computer.

After you install and configure Internet Information server, A and PTR records must be added to the DNS primary zone in which your Internet Information Server computer is located. If this primary zone is managed by Microsoft DNS server, you can use the New Host option to add the A and PTR resource records. For information about adding A and PTR records, see DNS Manager Help or the Windows NT Server Networking Guide.

The A and PTR resource records contain the name-to-IP address mappings and IP address-to-name mappings that allow users on the Internet to connect to a remote computer. However, additional types of resource records can be used to help balance the load of traffic on a computer configured with Internet Information Server or to mask the actual configuration of your Internet Information Server. The remainder of this section describes these additional types of resource records.


Creating an Alias

The host name portion of a URL may actually be an alias, also referred to as a canonical name. In the address http://www.microsoft.com, www is an alias commonly used for World Wide Web servers, Microsoft is the domain name, and .com indicates the commercial branch of the DNS hierarchy of names for the Internet.

The CNAME resource record is used to establish an alias name in DNS server zone files. CNAMEs are frequently used in conjunction with Web, FTP, and Gopher servers and when a host name is changed. The following figure illustrates the New Resource Record dialog box used to create CNAME records.

Figure 2.6 Adding a CNAME record

In the preceding illustration, an alias of www is being associated to a host name. The use of CNAMEs is accepted on the Internet for generalized names for servers such as www to indicate a Web server. However, other uses of the CNAME records can create problems for DNS name resolution throughout the Internet.

RFC 1912, which describes common errors in the creation of DNS resource records, states: "Don't use CNAMEs in combination with RRs (that is, resource records) which point to other names like MX, CNAME, PTR and NS." For more information on these resource record types, see Table 2.1, "DNS Resource Record Types," earlier in this chapter.


Using Round-Robin to Distribute Traffic Among Your Servers

Microsoft DNS server supports a process referred to as round-robin, which balances the number of clients connecting to Internet sites supported by multiple servers. Round-robin is specified by RFC 1794. To make use of round-robin, you use an alias such as the generalized server name www.

To understand how round-robin works, consider the following example. Suppose a user types the URL http:\\www.microsoft.com into an Internet browser. Doing so causes a name resolution query for www.microsoft.com to be sent to a DNS name server. The DNS name server returns a list of name-to-IP address mappings for each CNAME resource record that maps a host name to the alias www.microsoft.com.

The next time the DNS server receives a name resolution query for www.microsoft.com, the order of the list CNAME records is changed in a round-robin fashion. The address mapping that was first in the previous list is last in the new list. Because the process on the client computer generally uses the first name-to-IP address mapping in the list, the client connects to a server different from the server connected to on the previous request. In this manner, client connections to the Internet site are distributed among the supporting servers.

To enable round-robin when you use multiple servers to support a Web, FTP, or Gopher site, create CNAME records for each server as described in the preceding section, "Using An Alias."


Configuring Resource Records for Virtual Servers

You can configure a single computer running under Windows NT Server and Internet Information Server with multiple IP addresses and FQDNs so that it appears to remote users that there are additional servers, referred to as virtual servers. This feature makes it possible to service Web requests for two or more domain names (for example, company1.com and company2.com) by using a single computer configured with Internet Information Server. For example, an ISP can use this feature to service multiple companies by using a single computer running Windows NT Server and Internet Information Server. However, virtual servers require a special resource record treatment.

First, configure your virtual IIS servers as described in the online Windows NT Server Microsoft Internet Information Server Installation and Administration Guide. After you have done so, use DNS Manager to add new primary and secondary zones for the domain represented by the virtual server.

These primary and secondary zones must be configured on the DNS name servers identified in the InterNIC domain registration. After you have created the zones, map the IP address of the virtual server to the virtual domain name by using DNS Manager to add a new host A record. Add a second new host A record that maps the virtual server IP address to the host name of the computer on which the virtual server exists. Finally, if you want to use alias names, add new CNAME records that map aliases (such as WWW and FTP) to the host name (that is, the name of the computer on which the virtual server exists) and the virtual domain name.


Troubleshooting Microsoft DNS Server

Establishing a DNS name server and creating a database of resource records is not a trivial task. Errors are common; many of these errors are described in RFC 1912, "Common DNS Operational and Configuration Errors."

As previously discussed, DNS is used in TCP/IP networks. You can use the TCP/IP utilities provided with Microsoft Windows NT Server version 4.0 to troubleshoot problems you may encounter when using Microsoft DNS server. Most useful are the following TCP/IP utilities:

nslookup. A diagnostic tool for DNS servers.

ipconfig. A utility used to display information about the TCP/IP configuration of local and remote computers.

ping. A utility used to test network connectivity of local and remote hosts.

If you encounter problems with DNS servers, see the topic "TCP/IP Procedures Help" in Control Panel Help and the Windows NT Server Networking Guide. The remaining sections of this chapter provide additional information you can use to troubleshoot Microsoft DNS server.


Examining Microsoft DNS Files and Resource Records

RFC 1912 highly recommends verifying all data entered into DNS name server zone files. One common error with DNS name server data is incorrect formatting of DNS resource records. By using DNS Manager to automatically create and maintain resource records, potential resource record formatting errors are prevented.

Incorrect usage of resource records and entry of invalid data, however, is not precluded by using DNS Manager. Common data errors include inconsistent IP addresses in A and PTR records, alias names in PTR records, and invalid characters within host names. Common usage errors include invalid CNAME records, missing MX records, and incomplete or invalid zone delegation, also referred to as lame zone delegation.

It is not possible to address all possible data or usage errors in this chapter, but information is provided following to help you examine your Microsoft DNS server data files to identify data errors or incorrect usage of resource records for your own specific implementation of Microsoft DNS server.

The following database files are important in troubleshooting Microsoft DNS server. These files are located in the \Systemroot\System32\DNS\ directory.

Table 2.3 Microsoft DNS Server Database Files

Name of file | Description
Cache.dns | This file is essentially the same on all DNS name servers connected to the Internet and must be present. It contains the names and addresses for the top-level name servers.
Zonename.dns | This file contains the name-to-IP address mappings for a specific zone. A zone file is created for each zone managed by the local Microsoft DNS server.
NetworkID.in-addr.arpa.dns | This file contains the IP address-to-name mappings for a reverse lookup zone. The NetworkID portion of a reverse lookup zone name is the network and subnet numbers that InterNIC or your ISP has allocated to your enterprise and for which your server is therefore authoritative.


Cache File

When you install Microsoft DNS server, the cache file is automatically installed from the product disk. The data in this file contains name-to-IP address mappings for the InterNIC root domain name servers. Microsoft DNS server uses this information when name resolution queries must be resolved by getting information from name servers outside the local enterprise by contacting name servers on the Internet. You should not change this file unless the name-to-IP address mappings of the Internet root servers change.

If the computer on which you install Microsoft DNS server does not connect to the Internet, you should delete all the entries in this file and replace them with NS and A records for your intranet root name servers.


Zone File

The zone file is automatically created when you configure a zone on a computer running Microsoft DNS server. The zone file is named with the same name as the zone. Resource records are added to this file when you configure zone properties and add new records by using DNS Manager. If your computer running Microsoft DNS server is configured with multiple zones, you will have multiple zone files in the DNS directory on that computer.


Reverse Lookup File

A reverse lookup zone file is automatically created when you create a reverse lookup zone.


Format of Resource Records

As stated previously, when you use DNS Manager to create your zone files the data for each resource record is automatically formatted. In general, you do not need to worry about the format of resource records. However, if you manually examine the DNS data files, you must understand the record format.

The standard format of a resource record as specified by RFCs 1034 and 1035 is shown following:

<name> [<ttl>] [<class>] <type> <data>

The following table describes the fields in a resource record.

Table 2.4 Resource Record Format

Field | Description
Name | A host name.
TTL | The time-to-live (TTL) value is an optional entry. It is a 32-bit integer that represents, in seconds, the length of time the record is valid, after which it should be discarded.
Class | The class identifies the protocol and is generally IN, for Internet. Microsoft DNS server uses only IN class.
Type | The type specifies a resource record type. The most commonly used types are SOA, NS, A, CNAME, MX, and PTR.
Data | The data field is variable and is different for each record type. This field contains the information that is defined by the record type. The data in this field is specific to a particular host.

Most resource records are represented as single-line text entries. Records can use multiple lines by using a right parenthesis character at the end of the first line and a left parenthesis character at the end of the last line.

Under Microsoft DNS server, each resource record is entered into the zone file with preceding and following blank lines to improve readability. All blank and comment lines begin with a semicolon (;) and end with a carriage return. The semicolon character instructs Microsoft DNS server to ignore the line.

Consider the following example, which is taken from the sample DNS zone file place.dns, located in the \root\system32\dns\examples directory.

; START OF AUTHORITY

;

@ IN SOA nameserver.place.dom. postmaster.place.dom. (

1 ; serial number

36000 ; refresh [1h]

600 ; retry [10m]

86400 ; expire [1d]

3600 ) ; min TTL [1h]

;

; NAME SERVERS

;

;

place.dom

@ IN NS nameserver.place.dom.

@ IN NS nameserver2.place.dom.

nameserver IN A 192.5.29.7

nameserver2 IN A 192.5.29.8

;

; WINS LOOKUP

;

; The WINS LOOKUP is specific to the Microsoft DNS server
; implementation of DNS resource records and may be attached ONLY

; to the zone root. Presence of a WINS record at the zone root
; instructs the name server to use WINS to lookup any requests for A
; (address) records for names which are DIRECT children of zone root,
; and which do NOT have A records in the zone file.

;

@ IN WINS LOCAL 192.5.29.2 192.5.29.3

;

; E-MAIL SERVERS

;

@ IN MX 10 mailserver1

@ IN MX 15 mailserver2

mailserver1 IN A 192.5.29.17

192.5.29.19

;

; CNAME RECORDS

;

; The following records are sometimes called "aliases" but are

; technically referred to as "Canonical Names (CNAME)" entries.

; These records allow you to use more than one name to point to

; a single host.

;

; For example, the entries below mean that:

;

; ftp.place.dom. is really host.place.dom.

; www.place.dom. is really other-host.place.dom.

;

; By using CNAME records, you avoid typing duplicate information

; in your database files.

;

ftp IN CNAME host

www IN CNAME other-host

Note that some line entries contain the @ character in the name field (that is, the first field). When the @ character exists in a name field, Microsoft DNS server assumes the name value is the same as the name of the zone. When the name field is blank, Microsoft DNS server assumes the name value is the same as that for the preceding record.

The name field is followed by the optional TTL field. If this field is blank, Microsoft DNS server assumes that TTL value is the same as the TTL value that was specified in the SOA record by using DNS Manager to configure zone properties. The default TTL value is 60 minutes. You can change this default value by using DNS Manager to edit the SOA value.

Û To change the default TTL value

1. Start DNS Manager.

2. Right-click the folder for the zone whose default TTL value you want to change.

3. Click Properties.

4. Click the SOA Record tab.

5. Increase or decrease the value in the Minimum Default TTL box.

6. Increase by 1 the value in the Serial Number box. The serial number is the number used to identify the version of the file.

7. Click OK, then click OK again.


Configuring Dial-up Networking for ISP DNS

Dial-up networking enables you to connect to remote networks by using a modem or adapter such as an ISDN adapter. If you connect to an ISP by using dial-up networking and do not correctly configure TCP/IP or DNS name server information in dial-up networking, you can experience connectivity or name resolution errors.

To configure a computer with a dial-up network connection to an ISP, use the configuration procedure described in this section. Before you start, you must have completed the following:

You must have installed and configured your modem or adapter.

You must have installed TCP/IP on your computer.

You must have installed and configured Windows NT Server Remote Access Service (RAS), which provides the dial-up networking feature.

You will also need the following information before you start:

Your user name.

Your password.

Your ISP domain name.

Telephone number to dial up the ISP network.

Your default gateway address — the IP address of the ISP computer to which you connect.

The IP addresses of your DNS name server and the DNS name server used by your ISP. The installation by default configures dial-up networking to use the ISP DNS name server. However, if your ISP does not provide a DNS name server or if you to want to specify a combination of your intranet and the ISP DNS name servers, you must configure the IP addresses.

Any telephony options you must use, for example PBX or long-distance dialing.

Your logon procedure. Providing this information is necessary only if your ISP uses a special logon procedure.

Û To create a phone book entry for a dial-up connection to an ISP

1. Click the Start button, point to Programs, point to Accessories, and then click Dial-Up Networking.

If this is the first time dial-up networking is started, the Dial-Up Networking Wizard starts. If this happens, click OK. Otherwise, click New.

2. Type the name of your ISP in the Name the new phonebook entry box, and then click Next.

Select the check boxes for any options that apply, and click Next.

4. Point to the modem or adapter that you will use, and click Next.

5. Type the ISP telephone number in Phone Number, and click Next.

6. Click Finish.

Û To configure TCP/IP and DNS name server information for an ISP phone book

1. Start Dial-Up Networking, and in the Dial-Up Networking dialog box click More.

2. Click Edit entry and modem properties.

3. Click the Server tab.

4. Verify that the selected dial-up server type is PPP.

5. Under Network Protocols, clear the check boxes to disable IPX/SPX compatible and NetBEUI.

6. Click TCP/IP Settings.

7. Click Server assigned IP address.

– Or –

If the computer you are dialing from is your public Web, FTP, or Gopher server or the computer is assigned a static IP address for another reason, click Specify an IP address, and type the IP address in the IP address box.

– Or –

To configure name server information, click Specify name server addresses, type the IP address of your primary name server in the Primary DNS box, and type the IP address of your secondary name server in the Secondary DNS box.

8. Click OK, and close Dial-Up Networking.


Deleting Invalid Characters from a NetBIOS Computer Name

Name errors are common in the operation of DNS name servers. Name errors can occur because of the differences between what is acceptable in NetBIOS computer names and what is acceptable in DNS host names. NetBIOS computer names support a different character set than DNS host names, and by installation default, Windows NT Server and Windows NT Workstation are configured with a host name by using the NetBIOS computer name. In other words, the installation default for Windows NT Server and Windows NT Workstation is to configure the NetBIOS computer name as the DNS host name.

If the NetBIOS computer name contains invalid host name characters, Microsoft Windows NT Server and Windows NT Workstation attempt to correct the name by changing the invalid character in the host name to the - (hyphen) character. However, this change generates name resolution errors. For example, if your Web server NetBIOS computer name is Server#1, all attempts by remote TCP/IP network users to connect to the Web server by using the URL http://Server#1 will fail. They do so because the invalid # character is changed in the DNS host name to Server-1.

If computers in the zone managed by your Microsoft DNS server use NetBIOS names containing characters not supported in DNS host names, you must manually configure a valid host name on those computers.

Û To change a host name to a valid string of characters

1. Click the Start button, point to Settings, and click Control Panel.

2. Double-click the Network icon.

3. Click the Protocols tab.

4. In the Network Protocols list, click TCP/IP Protocol, and then click Properties.

5. Click the DNS tab.

6. In the Host Name box, type the corrected host name.

7. Click OK, click OK again, and then close Control Panel.

RFC 1912 defines the characters valid for DNS host names as: "Allowable characters in a label for a host name are only ASCII letters, digits, and the "-" character. Labels may not be all numbers, but may have a leading digit (e.g., 3com.com). Labels must end and begin only with a letter or digit. See RFC 1035 and RFC 1123.... The presence of underscores in a label is allowed in RFC 1033, except [RFC 1033] is informational only and was not defining a standard."

For more information about rules for creating valid host names, see RFC 1912, RFC 1035, and RFC 1123.


Enabling DNS to Correctly Locate Multihomed Computers

A multihomed computer is a single computer associated with multiple IP addresses. When a DNS name server is queried for a single host name-to-IP address mapping for a multihomed computer, it responds with a list of the host name-to-IP address mappings for that computer.

Because of the round-robin feature of Microsoft DNS server, described earlier in this chapter, the order of the listed mappings for a multihomed computer changes with each new name query. The round-robin feature enables DNS to respond with the list of mappings in a different order each time it receives a name query for the multihomed computer. This feature is used to balance the load of connections made to each IP address. If one or more of the listed mappings is incorrect, for example if there is an incorrect or nonexistent IP address, errors can occur as described following.

TCP/IP utility programs, NetBT programs, and Microsoft Internet Explorer all process the list of mappings for a multihomed computer differently.Some TCP/IP utility programs, such as FTP and Telnet, send a separate name resolution request to the DNS server each time an attempt is made to resolve a name to an IP address. These utilities use the first IP address in the list returned for each new request by the DNS server. If that first IP address is incorrect, the program fails to connect to the multihomed computer, even though it may have previously connected by using a previous name resolution query.

Programs that use NetBT to connect to remote computers process the list provided by the DNS server in a different manner. The first time a DNS client program using NetBT sends a name query to DNS server, it saves only the first mapping in the list in local cache on the DNS client computer. If the first mapping is incorrect, the program fails to connect to the multihomed computer.

The list is saved for a period of time defined as the CacheTimeout, which has a default value of 10 minutes. Any subsequent name resolution queries made within the CacheTimeout period are resolved by using the mapping saved in the local cache. Name queries made after the CacheTimeout period is expired require a new request for host name-to-IP address mapping. If the subsequent mapping is correct, the client program connects to the multihomed computer. If the subsequent mapping is incorrect, the client program fails to connect.

Microsoft Internet Explorer processes the list received from the DNS server differently than either the TCP/IP utilities or NetBT. Microsoft Internet Explorer tries to connect to the multihomed computer by using each name-to-IP address mapping until it succeeds or until all IP addresses in the list are attempted.

The responsibility of performing in this manner lies with the application. It is the responsibility of the resolver to return the addresses from DNS, not to define the manner in which the application uses the addresses.

Û To prevent failure to connect to a multihomed computer

Use DNS Manager to select the zone in which the multihomed computer exists and create A and PTR records for each IP address associated with multihomed computer.

Do not create A and PTR resource records for IP addresses that are nonexistent on the multihomed computer.

Use DNS Manager or a text editor to examine the data in the A and PTR records for the computer. Delete any A or PTR records that contain invalid IP address mappings.


Configuring to Avoid Error 2140 When Starting an Exchange Server

You might receive the following error message when starting the Internet Mail Connector service on the computer configured with Microsoft Exchange Server:

Stop "Could not start the Microsoft Exchange Internet Mail Connector

service on ..."

Error 2140: An internal Windows NT error occurred.

If so, the following event will be logged in the event viewer:

EventID 4058

Category: Initialization/Termination

This error occurs when the TCP/IP protocol properties for DNS name resolution are not properly configured, for example when there is a blank entry for the DNS domain name.

Û To configure a DNS domain name

1. Click the Start button, point to Settings, and then click Control Panel.

2. Double-click the Network icon, click the Protocols tab, in the Network Protocols list click TCP/IP Protocol, and then click Properties.

3. To display the DNS information configured on the computer, click the DNS tab.

4. In the Domain box, type the DNS domain name (that is, the name of the enterprise in which the Microsoft Exchange server exists).

5. Click OK, click OK again, and then close Control Panel.


Chapter 3 - Adding Bandwidth for Internet Connectivity

Bandwidth refers to the amount of data that is transferred and received within a given interval of time over a communication link between a computer and the network. When using the Internet as a wide area network (WAN) to connect remote users and computers, you need to understand your WAN bandwidth requirements. This need holds true whether you are the network administrator of a business running a private Transmission Control Protocol/Internet Protocol (TCP/IP) network (that is, an intranet), a small World Wide Web content provider, or an Internet service provider (ISP).

This chapter provides information about optimizing your bandwidth requirements using the telecommunication and networking features of Microsoft Windows NT Server and Internet Information Server (IIS). Specifically, this chapter provides information about the configuration options on a computer running Windows NT Server and Internet Information Server that support your choice of Internet telephony service. This chapter includes the following sections:

"What is the Bandwidth Problem?" This section presents information on the current U.S. and worldwide Internet infrastructure and describes the type of connectivity bandwidth problems that Internet site administrators usually face.

"Estimating Connectivity Bandwidth Requirements." This section provides information on methods to estimate connectivity bandwidth requirements for an Internet site running Windows NT Server and Internet Information Server.

"Evaluating the Bandwidth Capability of Connectivity Services." This section compares different types of telephone lines and data transmission technologies and provides information on evaluating your telecommunications hardware requirements.

"Troubleshooting Bandwidth for Internet Connections." This section provides information on resolving problems on your intranet connections to the Internet.


What Is the Bandwidth Problem?

The bandwidth of a telecommunications link is measured by the number of data bits per second (bps) that can be transferred on that link. Typically, the capacity of a telecommunications link is measured in kilobits per second (Kbps). One kilobit per second is equal to 1024 bits per second; one megabit per second (Mbps) is equal to 1024 kilobits per second.

Users require more from the Internet than they did previously. Users now transfer everything from formatted text to graphics to audio to full-motion video data content over the Internet. Such transfers require increasing amounts of bandwidth from the Internet telecommunications infrastructure and also increasing bandwidth from the computers and devices that connect to the Internet.


WAN Connections to the Internet

The number of options that can be used to connect to the Internet is rapidly changing. Satellite connections are a reality for some enterprises, although a large number of WANs still use public common-carrier telephone lines to provide connectivity to remote users. Because of their established availability for many users, WAN connections to the Internet over public common-carrier telephone lines are the focus of this chapter.

These public common-carrier telephone lines used by remote users for connection are also referred to as public switched telephone networks (PSTNs). PSTNs route users' connection requests to the desired Internet or private intranet server.

To provide access to your Internet Information Server (IIS), you need to provide a link to these telephone networks, by which remote users connect to your Internet Information Server site. This telephone link can terminate at a computer running Internet Information Server, at a computer configured with Windows NT Server and Remote Access Service (RAS) that routes remote clients to an Internet Information Server, or at some other network computer. A typical setup might include a firewall computer, a RAS server, and an Internet Information Server.


U.S. Internet Telecommunications Infrastructure

In 1995, the telecommunication infrastructure of the Internet in the United States changed from a publicly supported infrastructure to an evolving infrastructure of cooperating commercial enterprises. The infrastructure now consists of public telephone networks, network access points (NAPs), and Internet service providers (ISPs).

Figure 3.1 U.S. Network Access Points

The new commercial U.S. backbone infrastructure includes the NAPs shown in the preceding figure, which provide interconnection for commercial ISPs. It also includes a Routing Arbiter, which manages routing tables and databases that route the traffic between ISPs across the national backbone.

High-speed digital communications over the Internet infrastructure can provide transmission speeds between 45 and 155 megabits per second. Telecommunications at such speeds is referred to as midband telecommunications. National service providers (NSPs) provide backbone services for the Internet infrastructure using transmission technologies that range from midband telecommunications to fully switched broadband networks based on Asynchronous Transfer Mode (ATM) technology. ATM technology provides transmission speeds up to hundreds of megabits per second.

Demand exists for transmission technologies with even higher bandwidth on the Internet infrastructure. However, the bandwidth problem of primary concern to most administrators of Internet sites is the bandwidth from their sites to the Internet.

Connections to the Internet telecommunications infrastructure are often compared to a highway on-and-off ramp. The speed at which you enter and exit the highway (that is, the speed at which you send and receive data) depends on the road (the technology) that connects you to the Internet, rather than the maximum speed attained on the highway itself. In other words, the WAN bandwidth problems you can reasonably manage are most likely to occur over the connection between your server and your gateway to the Internet.


Using an Internet Service Provider

You connect to the Internet telecommunications infrastructure by using the services of an Internet service provider (ISP). ISPs can provide both dial-up connectivity for occasional connection to the Internet or dedicated digital lines for high-speed continuous 24-hour connectivity.

As discussed previously, there are a number of different types of organizations that make up the Internet telecommunications infrastructure. These range from telephone companies to specialized commercial enterprises. The Internet infrastructure is layered, with traffic from the ISPs in the lower layers funneled up to the national backbone service providers referred to as NSPs.

The separation between the backbone and regional network layers of the current infrastructure is blurring, as more regional areas connect directly to each other through the increasing number of ISPs in each region of the United States.


Connecting Directly to the Internet

Before the restructuring of the Internet telecommunications infrastructure in the United States during 1995, connecting directly to the Internet generally meant acquiring a dedicated, rather than dial-up, connection to the Internet. Today, this term may also refer to obtaining Internet connectivity services directly from an NSP at the backbone layer of the Internet telecommunications infrastructure.


Worldwide Internet Connectivity

There are also a number of backbone and midlevel networks in other countries. Most western European countries have national networks that are attached to Ebone, the European Internet backbone. The infrastructure is still inefficient in some places, and connections between countries are often slow or of low quality. It is common for Internet traffic between countries in Europe to be routed through the U.S. backbone.

The availability of full Internet service varies by location. In this chapter, discussion of WAN connectivity is limited to telecommunication services available in the United States. For example, Integrated Services Digital Network (ISDN) service, which is a preferred service for Internet connectivity for small to medium-sized enterprises connecting to the Internet in the United States, can be prohibitively expensive for sites in other parts of the world.

For information about worldwide Internet connectivity, available telecommunication services, and ISPs, search the International Telecommunications Union Web server at: http://www.itu.ch. You can also contact public telecommunication carriers in your area for additional information.


Estimating Connectivity Bandwidth Requirements

Before establishing an Internet site running Windows NT Server and Internet Information Server, be sure to evaluate your bandwidth requirements. Identifying bandwidth requirements helps you choose the telecommunication line service and related computer hardware configuration that best fit your needs.

First, identify the following information about the service you want to provide at your Internet Information Server site:

Type of programs and content — for example, static or dynamic hypertext markup language (HTML) pages

Desired response time — for example, 30 seconds or less to load an HTML page

Expected number of simultaneously connected users

The bandwidth requirements of an intranet, or Internet, Web server that may support 1 to 10 simultaneously connected users are much smaller than the bandwidth requirements of a large business that handles thousands of simultaneously connected users.

The type of programs and content usually provided by your Internet Information Server also affect bandwidth requirements. For example, an Internet Information Server should accommodate more users when they are running programs that are small in data content and non-CPU-intensive, such as electronic mail (e-mail), Telnet, and File Transfer Protocol (FTP). Processes that are CPU-intensive include Common Gateway Interface (CGI) scripts, database queries, downloading of HTML files, and video and audio programs.

Note

The number of simultaneously connected users should also be considered when selecting the computer on which to install Internet Information Server. For example, a Microsoft Web site that handles 3 million requests a day (an average of about 2,000 connections per minute) consists of two computers running Internet Information Server. Each computer has 66 megahertz Intel Pentium processors, 8 gigabytes of usable hard disk space, and 128 megabytes random access memory (RAM). One computer uses four Pentium processors; the other uses two.


Methods for Estimating Bandwidth Requirements

To help you identify your bandwidth requirements, two different methods are described in this section. For information on other methods, you can search Internet sites, as discussed later in this section.

The first method you can use to estimate bandwidth requirements is based on historical data from existing Internet sites. The number of bytes transferred is a commonly recorded statistic about Internet sites, and typical transfer statistics are available by searching the Internet. Many organizations publish statistics about data transferred and user connections on the World Wide Web, and the World Wide Web consortium at http://www.w3.org provides information about tools for gathering Web server statistics.

The following example illustrates this first estimation method. It calculates the kilobits per second (Kbps) of bandwidth required for a Web site that transfers approximately 250,000,000 bytes in an average 12-hour period:

250,000,000 ´ (8 bits data + 4 bits overhead) / ((12 hours ´ 60 minutes ´ 60 seconds) ´ 1024) = 67.8 Kbps

This example site requires a minimum of two 56 kilobits per second dedicated lines or one ISDN line.

When examining data from historical sites, remember to correctly convert different units of measure to bits (the unit of measurement for bandwidth). To obtain the number of bits contained in one transferred byte, multiply the number of bytes by 12; there are 8 bits per byte, plus 4 bits of overhead data. You also need to express the results in terms of seconds. If your data is recorded as bytes per hour, multiply the number of hours by 3,600 (60 minutes per hour ´ 60 seconds per minute).

The second method you can use to estimate bandwidth requirements is based on the estimated number of simultaneous user connections and the average size of documents transferred. The following example illustrates this method:

(Average connections per day / Number of seconds per day) ´ (Average document size in kilobytes ´ (8 bits data + 4 bits overhead))

Because there are 86,400 seconds in one day, 8 bits in a byte, and 4 bits overhead per byte of data, the formula can also be written as:

(Average connections per day / 86,400) ´ (Average document size in kilobytes ´ 12)

For example, if you predict 3,000 connections per day and the average file size accessed by remote users to be 85K, your bandwidth requirements can be estimated as follows:

(3,000 / 86,400) ´ (85 ´ 1,024 ´ (8+4)) = 36.3 Kbps

You can search sites on the Internet to find discussions of bandwidth estimation methods used, or recommended, by other users with experience in establishing Internet and Web server sites. Considerations other than those discussed previously might arise. For example, bandwidth requirements should also account for a minimum acceptable transfer rate per user, based on a projected load per remote user accessing the Internet Information Server. In other words, you should consider whether your server will be able to transfer data to all users at a rate that is acceptable to remote users.

To predict a peak load on your Internet Information Server, you need to estimate the number of users who will simultaneously connect to your server and consider the type of service they will access. If your users will primarily access your Web service for HTML documents with audio and graphics, you need a much higher bandwidth connection than if your users will primarily access the Web server to browse text documents.


Do You Need Additional Bandwidth?

Bandwidth requirements can change monthly, weekly, daily, and even hourly. Use the estimation methods described in the preceding section whether you are planning a future Internet Information Server site or evaluating the bandwidth requirements of an existing site. You can tune and adjust your bandwidth estimates if the number of remote users connecting to your site exceeds your estimates, if connection response time increases, or if the number of rejected connections increases.

If your bandwidth estimates exceed the bandwidth provided by your connection to the Internet, you can do any of the following:

Increase the connection bandwidth with improved line services from your ISP or telephone company.

Reduce the services provided by the Internet Information Server.

Reduce the number of remote clients that simultaneously connect to the Internet Information Server services, by modifying the value of the MaxConnections parameter as described in "Troubleshooting Bandwidth for Internet Connections," later in this chapter.

Reduce the amount of network bandwidth that the Internet Information Server can use, by modifying the value of the BandwidthLevel parameter as described in "Troubleshooting Bandwidth for Internet Connections," later in this chapter.

If your bandwidth estimates indicate that you have adequate bandwidth on your Internet connection, but remote users are experiencing connectivity problems, examine the configuration of your Internet Information Server. Connectivity problems can be caused by computer configuration problems including inadequate processor or memory capacity.

If you are experiencing connectivity problems, use Performance Monitor to identify the cause of the symptoms. For information about using Performance Monitor with Internet Information Server, see Chapter 7, "Monitoring Bandwidth and Network Capacity." See also "Troubleshooting Bandwidth for Internet Connections," later in this chapter.


Evaluating the Bandwidth Capability of Connectivity Services

As previously stated, this chapter focuses on Internet communications that use the PSTN networks to provide connectivity between remote users. PSTNs are based on circuit-switching with dedicated capacity to transfer and route traffic throughout the PSTN.

Data communication on the Internet, however, is based on packet switching, designed for high throughput of all communications, including data, audio, and video. Packet-switching networks provide the highest rates of data transfer available; however, the Internet relies on PSTNs to deploy the packet-switching technologies. You can select different PSTN line services that will support data communications on Internet, and to support WANs and local area networks (LANs).

The next two sections describe the transmission technologies and telephone connections that you can choose to connect to the Internet. After you select a telephone line service that provides the amount of bandwidth you need, use the Windows NT Hardware Compatibility List to identify the hardware devices that you can select that will support the line service you chose.


Dial-Up vs. Dedicated Leased Telephone Lines

The types of telephone lines you can choose from are described in the following table.

Table 3.1 Classification of Telephone Line Types

Line type | Description | When to use | Line speed
Public dial-up network lines | These are common telephone lines. They require users to manually make a connection for each communication session. | This connection type is slow and not totally reliable for transferring data. However, for some companies it may be practical to dial up a temporary link between sites daily to transfer files or update databases. | Carriers are continually improving their dial-up line service. Some digital lines claim data transmission speeds of up to 56 kilobits per second by using error correction, data compression, and synchronous modems.
Leased, or dedicated, lines | These provide full-time dedicated connections that do not use a series of switches to complete the connection. | The quality of the line is often higher than that of a line designed only for voice transmissions. | Lines typically range in speed from 56 kilobits per second to 45 megabits per second or more.

If your Internet Information Server is used infrequently by a small number of users, dial-up line connectivity that provides limited connection and access to the Internet may be appropriate. However, if your Internet Information Server is accessed by a large number of simultaneous users or provides 24-hour continuous availability, you should choose a dedicated connection and line technology that provides adequate bandwidth and availability.

Dial-up telephone lines, even with a fast modem and data compression, can create a large telephone bill for even a temporary connection. Leased lines, which offer more continuous connections, are in the long run more economical for companies that want to provide continuous availability to remote users.


Transmission Technologies

Dial-up and dedicated leased lines can be connected to a telephone network by using line services based on different transmission technologies. The following table describes these transmission technologies.

Table 3.2 Description of Transmission Technologies

Technology | Description
X.25 | X.25 is a set of protocols incorporated in a packet-switching network. An X.25 packet-switching network uses switches, circuits, and routes as available to provide the best routing and transmission of your data at any particular time.
Frame Relay | Frame Relay is a packet-switching technology that evolved from X.25. It performs much faster than X.25, due to reduced overhead. It requires a Frame Relay – capable router that can route and transfer data from your server to remote users.
Asynchronous Transfer Mode (ATM) | ATM is also an advanced form of packet-switching. It is a broadband method that transfers data in 53-byte cells rather than variable-length frames. It produces uniform frames that network equipment can switch, route, and move more quickly than frames of different sizes. ATM can be used with any media that include the necessary physical interfaces.
ISDN – Basic Rate Interface (BRI) | ISDN-BRI employs digital transmission that divides its available bandwidth into two 64-Kbps B channels and one 16-Kbps D channel, using existing regular telephone lines.
ISDN – Primary Rate Interface (PRI) | ISDN-PRI has a larger bandwidth capacity than ISDN-BRI. Primary Rate ISDN provides 23 64-Kbps B channels and one 64-Kbps D channel.
Fiber Distributed Data Interface (FDDI) | FDDI is a high-speed token-passing ring network that uses fiber-optic media and that was developed for high-end computers. It is used for environments that connect components such as mainframe and minicomputers in a traditional computer room, for backbone networks, for networks that require high data rates and fairly large bandwidth, and for high-speed office networks in general.
Synchronous optical network (SONET) | SONET is an emerging fiber-optic technology that can transfer data at more than one gigabit per second. Networks based on this technology are capable of delivering voice, data, and video.

Table 3.2 Description of Transmission Technologies (Continued)

Technology | Description
Switched Multimegabit Digital Service (SMDS) | SMDS is a switching service provided by some local exchange telephone networks. SMDS uses the same fixed-length cell relay technology as ATM and provides high-speed communication for multicast programs (that is, programs transmitted from one point to many simultaneous remote users, such as video broadcasts).
T1 | T1 is an AT&T term for a digital carrier facility used to transmit a Digital Service 1 (DS-1) formatted digital signal at 1.544 megabits per second.
T3 | T3 is a digital carrier facility used to transmit a Digital Service 3 (DS-3) formatted digital signal at 44.746 megabits per second.

The preceding table provides some information you can use to choose what technology best supports your Internet Information Server bandwidth requirements. In some cases, an enterprise might need to use a mix of available services. For example, the 1995 data communications WAN at Microsoft is a mix of services, primarily composed of point-to-point leased circuits of 64 - kilobit per second or higher bandwidths, with smaller sites using X.25 services, ISDN-BRI, or analog dial-up.

The following table compares a few of the transmission technologies, listing different technologies' connection options, send and receive speeds, and number of simultaneous connections.

Table 3.3 Comparison of Transmission Technologies

Transmission method | Continuous connection | Send speed | Receive speed | Readily available | Simultaneous users
Analog modem | No | Up to 28.8 Kbps | Up to 28.8 Kbps | Yes | 1 – 10
ISDN | No | 128 Kbps | 128 Kbps | Yes | 10 – 500
T1 and fractional T1 | Yes | 1.5 Mbps | 1.5 Mbps | Yes | 50 – 500
T3 | Yes | 24 – 43.5 Mbps | 24 – 43.5 Mbps | Yes | 5,000 +


Dial-Up Internet Accounts

A connection to the Internet using a telephone line and modem can serve up to 10 simultaneous users. Modem connections are often called slow links because data is transferred at the speed of the modem, typically from 9,600 to 28,800 bits per second.

Dial-up connections require the TCP/IP suite of protocols, as do all connections to the Internet. Specifically, dial-up connections require the Internet Protocol (IP). ISPs generally refer to dial-up connections as IP accounts. Variations of IP accounts are based on the TCP/IP line protocol used by the IP account. The following list describes the three variations of IP accounts:

PPP, which stands for Point - to -Point Protocol

SLIP, which stands for Serial Line Internet Protocol

CSLIP, which is a compressed version of SLIP

PPP is the current standard for encapsulating IP data and other network layer protocol information over point-to-point links. It also provides ways to test and configure lines and the upper level protocols of the Open Systems Interconnectivity (OSI) network architecture. PPP is an improvement over SLIP, which does not provide error correction.

To connect an Internet Information Server computer to the Internet, request a PPP account from your ISP. The PPP account is faster and more reliable than the other line protocols and is fully supported by the TCP/IP implementation under Windows NT Server and Windows NT Workstation.

Note

Point-to-Point Tunneling Protocol (PPTP), which is a feature provided by Windows NT Server and Windows NT Workstation version 4.0, essentially converts PPP information into point-to-point packets transmitted by TCP to provide a secure "tunnel" through the Internet. For more information, see the Windows NT Server Networking Supplement.


Dedicated Digital Lines

When you lease a dedicated line for Internet connectivity, a network cable to your site is installed by your ISP (or your local telephone company if the telephone company is your ISP). Dedicated digital lines can provide speeds in the United States ranging from 56 kilobits per second by using Frame Relay technology to 43.5 megabits per second by using T3 technology.


Telecommunications Hardware Requirements

The computer that is connected to a telephone network is physically connected by using a hardware device such as a network adapter (also known as a network interface card, or NIC), modem, or ISDN card attached to the computer and a telephone line. The hardware device and device driver that you install on the computer that is connecting to the Internet must support the type of telephone line service and ISP account provided by your telephone company and ISP.

The telephone line connection to the local telephone central office is sometimes referred to as the last mile, at the maximum 18,000 feet of wiring that physically connects a private enterprise telephone line to the public telephone network. The distance between your telephone connection to a PSTN central office can affect your ability to get the PSTN service you need to support your bandwidth requirements.

You may need additional hardware to support your choice of telephone line service. Dedicated digital lines require additional networking equipment to attach a server or workstation to the Internet. For example, some configurations require a Channel Service Unit/Data Service Unit (CSU/DSU) that takes the digital data from the telephone network and processes it for the computer that is connected to the Internet on the digital line.

The additional CSU/DSU networking hardware is installed to physically connect your computer and modem to a dedicated digital line, for example, as shown in the following figure.

Figure 3.2 Hardware needed for digital line connectivity

Because the Internet continues evolving, other possible configurations of hardware and software may replace the typical CSU/DSU unit illustrated in the preceding figure. You also need additional equipment on the computer that is connected to the digital line. For more information on this additional equipment, see Chapter 4, "Using ISDN."

The output from the CSU/DSU goes to a router located at your site. A cable is run from the router to the LAN adapter card on the computer that is connecting to the Internet. Before purchasing your CSU/DSU equipment, consider these factors:

CSU/DSU equipment bandwidth. Some CSU/DSU units operate at 56 kilobits per second, some work at T1 speeds, and some have a range of frequencies at which they operate.

Router bandwidth. Routers have similar bandwidth capabilities, and your router must match your CSU/DSU unit bandwidth.

ISP equipment compatibility. Your CSU/DSU and router must be compatible with the hardware used by your ISP.


Troubleshooting Bandwidth for Internet Connections

To prevent degraded or interrupted service to your Internet site running Windows NT Server and Internet Information Server, estimate your bandwidth requirements and acquire an Internet connection that provides adequate bandwidth with capacity for growth. You can also help prevent or troubleshoot performance and connectivity problems by using the information provided in Chapter 7, "Monitoring Bandwidth and Network Capacity."

Additionally, the following topics provide information about resolving specific problems that can occur when providing services with Internet Information Server to remote users on the Internet.


Changing IIS Parameters to Address Connection Problems

If your estimates indicate the bandwidth of your Internet connection is inadequate to service your remote users, you can change specific parameters in the Registry in response. Internet Information Server contains four Registry subkeys, one subkey for each IIS service. The IIS services are the following:

FTP

Gopher

WWW (World Wide Web)

Inetsrv (Internet Information Server)

The parameters for each service are located in the key:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\ServiceName
\Parameters

In the previous key, ServiceName refers to the name of the particular IIS service whose parameters you want to change.

The value of the Registry parameter MaxConnections specifies a maximum number of simultaneous connections with an installation default value of 1,000 simultaneous connections. One MaxConnections parameter is located under each ServiceName key. To optimize the available bandwidth on your Internet Information Server, you can change this parameter to allow more or fewer simultaneous connections.

The value of the Registry parameter BandwidthLevel specifies the amount of network bandwidth that can be used by IIS services. Internet Information Server includes an automatic bandwidth service that monitors client connections and adjusts up or down depending on the amount of network bandwidth the services use. Such adjustment prevents IIS services from overwhelming the network bandwidth.

By default, the BandwidthLevel parameter is not started. To start the bandwidth throttler, which BandwidthLevel controls, you must change the installation default behavior. This is done by changing the value of the BandwidthLevel parameter.

Use the Internet Service Manager to change the value of the BandwidthLevel parameter without having to stop and start the server. You can also use a Registry editor (Regedit or Regedt32) to manually change the value of this parameter. The server should be stopped and restarted if you use a Registry editor. For additional information, see Chapter 7, "Monitoring Bandwidth and Network Capacity," and the online Microsoft Windows NT Server Resource Kit: Windows NT Server Internet Guide.

Warning

To add or modify a Registry value entry, use admininstrative tools such as Control Panel or System Policy Editor whenever possible. Using a Registry editor (Regedit or Regedt32) to change a value can have unforeseen effects, including changes that can prevent you from starting your system.


Using the Idle Disconnect Feature

Idle disconnect reduces the cost of remote access carrier service and can be used to reduce the total capacity of dial-in communications links, based on the reduction of wasted remote connect time. This feature can be configured on remote clients that use Windows NT–based dial-up networking.

This new feature automatically terminates a RAS connection to your server after a certain period of time if there has been no activity over the remote dial-up communications link. The user or administrator can specify the amount of time before this feature is activated.


Troubleshooting Client Connections over Slow WAN Links

If remote clients that connect directly to your Internet Information Server over a slow dial-up connection experience connectivity problems, you can change specific Internet Information Server properties and Windows NT – based Registry parameters to resolve connection time-out problems. You can also change Registry parameters on remote Windows NT – based clients to adjust connection time-out problems.

You can change the behavior of TCP/IP, the protocol used for Internet communications, by changing the Registry parameters located in the following subkeys:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Tcpip
\Parameters

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\AdapterName
\Parameters
\Tcpip

In the previous subkey, AdapterName refers to the name of the network adapter to which TCP/IP is bound. Most adapters are named to indicate the name of the card. However, some are not. For example, a DEC adapter is named Lance1.


Changing TCP/IP Parameters on the Remote Client

As previously mentioned, TCP/IP is the protocol used on the Internet. You may consider changing the following TCP/IP Registry parameters if remote clients are experiencing connectivity problems.


TcpMaxConnectRetransmissions

The Registry parameter TcpMaxConnectRetransmissions determines the number of times TCP retransmits a connect request (a SYN) before aborting the attempt. The retransmission time-out is doubled with each successive retransmission in a given connect attempt. The initial time-out value is 3 seconds.

Increasing the default value may allow a client to connect over a slow WAN. However, the value should only be changed in very small increments because the time-out value doubles after each transmission retry. Too large a value could ensure that a connection attempt never times out.


TcpWindowSize

The Registry parameter TcpWindowSize determines the maximum TCP receive window size offered by the computer. The receive window specifies the number of bytes a sender can transmit without receiving an acknowledgment (an ACK); in other words, it indicates the amount of receive data (in bytes) that can be buffered at one time on a connection. The sending host can send only the amount of data indicated by the receive window before waiting for an acknowledgment and window update from the receiving host.

In general, larger receive windows improve performance over high delay, high bandwidth networks. For greatest efficiency, the receive window should be an even multiple of the TCP maximum segment size (MSS).

However, if your clients experience connectivity problems because they time out before data transmission reaches them, you can change the value of the TcpWindowSize parameter. Reducing the value of TcpWindowSize causes an acknowledgment for data received to be sent to the sender sooner. Earlier acknowledgment lowers the possibility that the sender will time out while waiting for an acknowledgment. However, it also increases the amount of network traffic and causes slower throughput.

The TCP/IP stack is designed to self-tune in most environments. Instead of using a hard-coded default receive window size, TCP adjusts the window size to even increments of the MSS negotiated during connection setup.

Matching the receive window to even increments of the MSS increases the percentage of full-sized TCP segments used during bulk data transmission. By default, TcpWindowSize is set to 8 kilobytes (K) rounded up to the nearest MSS increment for the connection. If that increment is not at least four times the MSS, then it is adjusted to four times the MSS, with a maximum size of 64K.

The maximum window size is 64K because the field in the TCP header is 16 bits in length. Request for Comments (RFC) 1323 describes a TCP window scale option that can be used to obtain larger receive windows; however, Windows NT – based TCP/IP does not yet implement that option.

For Ethernet, the receive window is usually set to 8760 bytes (that is, 8192 rounded up to six 1460-byte segments). For 16/4 Token Ring or FDDI, it is set to around 16K. These are default values, and it is not generally advisable to alter them. However, if necessary you can either change TcpWindowSize to globally change the setting for the computer, or use the setsockopt Windows Sockets call to change the setting on a per-socket basis. For more information on Windows Sockets, see the Windows Sockets Software Development Kit (SDK).


Chapter 4 - Using ISDN

Integrated Services Digital Network (ISDN) is a high-speed, fully digital telephone service that can be used over the existing analog telephone network. A standard analog telephone line and modem connection typically transfers data at a maximum of 28.8 kilobits per second. ISDN can dramatically speed up transfer of information over the Internet or over a remote wide area network (WAN) link, because ISDN transfers data at rates of 64 to 128 kilobits per second.

ISDN is a powerful and complex telecommunication service that can be used to support many different types of telecommunication needs. It can provide connections to the Internet that support World Wide Web browsing, multimedia, and video presentation applications.

This chapter is limited to information about using ISDN to connect to the Internet with a computer running Windows NT Server version 4.0 with Internet Information Server. The information in this chapter is intended for network administrators and support personnel who need information about ISDN and how ISDN can be used to connect to the Internet. This chapter includes the following sections:

"Introduction to ISDN." This section covers ISDN basics, including its data transfer rate, channel configuration, availability, and quality of connection. The section discusses two ISDN services, Basic Rate Interface and Primary Rate Interface, and describes hardware required for ISDN. It also briefly describes Microsoft support for ordering ISDN.

"Windows NT Architecture Supporting ISDN." This section describes the Windows NT services and the application programming interfaces that support ISDN. It also discusses the Point-to-Point Protocol (PPP), Remote Access Service, and PPP Multilink as they relate to ISDN.

"Configuring Windows NT Server for ISDN." This section tells you how to configure your Windows NT Server to work with ISDN and describes equipment and protocols required.

"Alternatives to ISDN." This section briefly discusses some alternatives to ISDN.


Introduction to ISDN

ISDN is an international digital telephony standard defined by the International Telecommunications Union, formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). ISDN protocols are mapped to Open Systems Interconnectivity (OSI) standards: to OSI layer 2 for call setup, maintenance, and disconnect and to OSI layer 3 for basic call control.

The ISDN standards provide an open architecture for digital telephony, enabling manufacturers to design and produce networking devices that can operate over any ISDN telephone line, regardless of the local telephone network.

ISDN provides end-to-end digital connectivity between a remote computer and another computer by using a local telephone line for network connection. Prior to ISDN, digital data communications were available only on proprietary networks, and Internet connections over telephone networks had to convert from digital to analog transmission. This conversion reduces quality of service, speed of transmission, and available bandwidth.

ISDN is typically supplied by the same company that supplies analog service, also referred to as plain old telephone (POTS) service. However, ISDN differs from analog telephone service in several ways, including:

Data transfer rate

Available channels per call

Availability of service

Cost of service

Quality of connection


Data Transfer Rate

ISDN can provide data transfer rates of up to 128 kilobits per second. These speeds are slower than those of local area networks (LANs) supported by high-speed data communications technology. However, they are faster than those of analog telephone lines, which provide transfer rates of up to 28.8 kilobits per second.

In addition to the difference in data transfer rates, ISDN calls can be set up much faster than analog phone calls. While an analog modem can take up to a minute to set up a connection, you usually can start transmitting data in about two seconds with ISDN. Because ISDN is fully digital, the lengthy handshaking process of analog modems (those piercing, screeching noises) is not required.


Channels

POTS service provides a single channel, which can carry voice or digital communications but not both at the same time. ISDN service is available in several configurations of multiple channels that provide simultaneous voice and digital communications. In addition to increasing data throughput, multiple channels eliminate the need for separate voice and data phone lines.


Availability

POTS service is generally available throughout the United States. Although increasing in availability, ISDN service is not as widely available as POTS service.


Cost

The cost of ISDN hardware and service fees is generally higher than POTS modems and service fees.


Connection Quality

ISDN transmits data digitally and, as a result, is less susceptible to static and noise than analog transmissions are. Analog modem connections must dedicate some bandwidth to error correction and retransmission. This overhead reduces the actual throughput. In contrast, an ISDN line can dedicate all its bandwidth to data transmission.

Because ISDN is a digital service, it is sensitive to outside interference, and certain factors affect the quality of ISDN connections to the telephone network and the Internet. The computer connecting to the ISDN line must be within a given distance of the telephone company's central office equipment that serves the computer for the ISDN connection to work. The maximum distance allowed between the computer and the central telephone office is typically 18,000 feet. Additionally, ISDN connections can be adversely affected by telephone lines that are not wired using twisted-pair wiring.

Two types of ISDN service are currently available:

Basic Rate Interface (BRI)

Primary Rate Interface (PRI)

The most appropriate type of service for small Internet Information Server sites is ISDN-BRI. The most appropriate type of service for medium to large Internet Information Server sites is ISDN-PRI. The next two sections describe the two types of service in further detail.


ISDN - Basic Rate Interface

ISDN-BRI divides the telephone line into three digital channels: two bearer channels, commonly referred to as B channels, and one D channel. All three channels can be used simultaneously.

The B channels can be used to send voice, circuit-switched data, or packet-switched data at rates of 56 to 64 kilobits per second. The maximum available transfer rate is determined by your local telephone company. The B channels function independently of one another. They can be used simultaneously for separate calls or combined to provide a total bandwidth of 128 kilobits per second.

The D channel can transfer data at 16 kilobits per second and is used for signaling and control information sent between the computer and the telephone office. D channel signaling provides functions such as call setup, call monitoring, call termination, and enhanced telephony features.

When using ISDN-BRI, it is possible to perform several types of connections. For example, it is possible to have a voice conversation on one B channel, a circuit-switched data call on the second B channel, and a packet-switched data call on the D channel. The D channel can simultaneously complete all necessary signaling and call control functions.


ISDN - Primary Rate Interface

The U.S. standard for ISDN-PRI consists of 24 digital channels: 23 B channels and 1 D channel, commonly referred to as a 23B+D connection. ISDN-PRI provides a total bandwidth of 1.544 megabits per second and is designed for transmission over a North American - standard T1 line connection. The European standard for ISDN-PRI provides a total of 31 or 32 digital channels. Each of these channels is a 64 – kilobit per second B channel, except one that is the D channel for the entire group. In Europe, ISDN-PRI is designed for transmission over a European-standard E1 line connection. A PRI D channel can be used to control one or multiple T1 or E1 lines.

The following figure illustrates the main difference between BRI and PRI, which is the greater number of channels that allows PRI to provide higher bandwidth than the BRI service.

MHMiriam HarlineFigure 4.1 Comparison of ISDN-BRI to ISDN-PRI


ISDN Hardware

The ISDN user - to - network interface standard defines the hardware components needed for ISDN communication and these components' interfaces to other hardware components. ISDN provides standards for the following components and interfaces:

Terminal Equipment 1 (TE1). This equipment is workstation equipment, such as the ISDN telephone or ISDN-enabled computer.

Network Termination 1 (NT1). A device that connects the U interface (the telephone wall jack) to the interior phone circuit on the user premises. The NT1 device converts the two-wire circuit of the U interface to four-wire circuits that allow multiple terminal devices to access ISDN B channels. Typically, the NT1 device provides the Subscriber/Termination interface for ISDN-BRI service.

Network Termination 2 (NT2). An intelligent device such as a ISDN router that exists between the NT1 and TE1 devices. The NT2 device provides services that map to the Data Link and Network layers of the OSI mode.

Subscriber/Termination (S/T) Interface. The ISDN standard for the S/T Interface defines the conversion of two-pair to four-pair circuits and also defines distance limitations. The maximum allowable distance between the NT1 device on the user premises and a user computer is approximately 3,500 cable feet.

U Interface. The telephone wall jack on the user premises. The ISDN standard for the U interface defines the maximum allowable distance between the telephone company's central office equipment and the U interface, which is approximately 18,000 cable feet.

These hardware and interface components are described in the following sections.


Workstation Hardware

There are two types of ISDN hardware devices that you can use to connect your computer to an ISDN line. Internal ISDN devices are adapter cards that you put inside your computer. External ISDN devices are adapters that you connect to an external port on the back of your computer.

Internal vs. External ISDN Adapters

Internal ISDN cards can take the fullest advantage of your ISDN line. However, internal adapters require you to open your computer to install the card. In addition, in order to install an internal adapter, you need a slot free in your computer that supports the same type of bus (for example, ISA, EISA, or PCI) as the card you want to install.

External ISDN adapters are easy to install and do not require any special software, but they do not provide the same level of performance that internal adapters do. External ISDN adapters are similar to a modem, and the computer communications program attempts to control the external ISDN adapter just as it controls an analog modem, typically with AT commands.

An external ISDN adapter plugs into a computer's serial or parallel port. These ports impose certain limitations. Most computer serial ports do not transmit information faster than 115 kilobits per second, which is less than ISDN's maximum data speed of 128 kilobits per second. These serial ports also impose overhead on the transfer of information between the computer and the external adapter, further slowing data speeds.

An external adapter can also adversely affect the performance of your computer, because an external adapter places heavy requirements on the CPU. To use an external ISDN adapter, it is recommended you use a computer with a 486/33 or faster processor.

Also, interoperability issues can potentially arise with external adapters, because higher-level protocols such as Point-to-Point Protocol (PPP) or authentication are implemented in the modem itself. These protocols are evolving quickly and can be difficult to update in an external adapter.

Adapters and the U and S/T Interfaces

The U Interface carries ISDN signals over a single pair of wires between your computer and the telephone central office. This interface is designed to carry ISDN signals over long distances. The S/T Interface uses two pairs of wires to deliver the signal from the wall jack to the ISDN adapter in a computer or other ISDN equipment.

If your ISDN adapter supports the S/T Interface, you need to get a device known as a Network Termination 1 (NT1) that converts traffic between the U Interface and the S/T Interface. The NT1 supplies a jack for the U Interface coming from the wall and one or more jacks for the S/T Interface connection to the computer and other ISDN or analog devices, in addition to a connection to an external power supply.

Some ISDN adapters sold in North America connect directly to a U Interface. If a single computer is the only equipment to be connected to an ISDN line, this type of adapter is the easiest to install. Manufacturers may describe such an adapter as having built-in NT1 or simply as a U Interface ISDN adapter.


Wiring

ISDN uses unshielded twisted-pair cable instead of more costly coaxial cable. ISDN lines can be run on existing category 3 wiring to a computer as long as distance limitations are not exceeded. Repeaters can be used when distance limitations are exceeded.

ISDN service from the phone company officially ends at what is called the demarcation point, generally referred to as the demarc. The demarc is usually inside the wall of the customer's office or home. You, the customer, are responsible for the inside wiring from the demarc to your ISDN equipment, including the wall jacks. The telephone company or an electrical contractor can install and maintain the inside wiring for an additional charge.

If you are connecting just one computer to an ISDN line, the wiring requirements can be very simple. Most offices are wired with extra sets of telephone wires, and one of those sets can be used for your ISDN line. However, a number of possible wiring pitfalls exist:

Your "extra" wires might already be in use for an analog line or lines.

Your extra wires might be used to power lighted phone buttons.

Your extra wires might not be connected directly to the demarc.

The wiring between the ISDN wall jack and the demarc might be "daisy-chain" rather than direct wiring.

Direct wiring between the ISDN wall jack and the demarc, also known as a home run, is recommended. For more information on wiring issues, consult your telephone company or an electrical contractor.


Phone Jacks

The following two types of phone jacks can be used with ISDN telephone lines:

RJ11, the standard analog phone jack. The RJ11 has four wires. The wire from the wall to the NT1 usually has RJ11 jacks.

RJ45, a jack slightly wider than the RJ11 that has six wires. The wire from the NT1 to the ISDN adapter usually has RJ45 jacks.

The following figure puts together ISDN hardware and interfaces to illustrate the relationships described in this "ISDN Hardware" section.

MHMiriam HarlineFigure 4.2 ISDN hardware and interfaces


Connecting Multiple Devices to an ISDN Line

Instead of connecting the ISDN line to a single computer, you can also connect an ISDN line to a LAN so all the computers on the LAN share the ISDN line. Doing so requires an ISDN network bridge or router.

You can connect up to eight devices to a single ISDN line. These devices can include network routers and bridges, Group 4 ISDN fax machines, computers, and ISDN telephones, in addition to traditional analog telephone devices.

For example, you might want to have an ISDN adapter in your computer, an ISDN telephone to make voice calls, and a Group 4 ISDN fax machine all connected to the same ISDN line. In such a scenario, incoming data calls go to the computer, voice calls to the telephone, and fax calls to the fax machine.

To support this configuration, you need an NT1 that supports multiple S/T Interface connections. Each device on the ISDN line is connected to the NT1. Each device needs its own Service Profile Identifier (SPID) to ensure the telephone company can route calls to the appropriate device. An example configuration is illustrated in the following figure.

MHMiriam HarlineFigure 4.3 Using multiple ISDN devices


Ordering ISDN Service

ISDN is a powerful but complex service and is not yet available throughout the United States. For this reason, getting ISDN can sometimes be confusing or frustrating. Microsoft provides an online service that can guide you through the ordering process. This service and useful information is available for computers running Windows-based operating systems. This service can simplify and streamline the process of getting ISDN for your Windows-based computer, by helping you:

Identify which telephone companies offer ISDN. Most but not all telephone companies offer this service.

Check whether the necessary ISDN equipment is installed in your area.

Learn about the ISDN service options and pricing in your area.

Send an electronic order for ISDN to your telephone company.

Automatically tell the phone company how to configure your ISDN line.

To use this online service, connect to the Microsoft World Wide Web site at: http://www.microsoft.com/windows/getisdn.

Note

Even if the right equipment is installed in your area, ISDN may not be available. To determine whether your particular wiring supports ISDN, your telephone company must perform what is known as a line qualification.


Windows NT Architecture Supporting ISDN

Support for ISDN is a built-in feature of Windows NT Server. ISDN requires Transmission Control Protocol/Internet Protocol (TCP/IP) and Point-to-Point Protocol (PPP), which Windows NT Server fully supports. PPP is an industry standard that enables Windows NT – based computers to support remote access networking in multivendor networks.

In addition to providing support for TCP/IP and the TCP/IP-based PPP protocols, Windows NT server architecture supports ISDN by using the services and application programming interfaces (APIs) illustrated in the following figure.

Figure 4.4 ISDN support in the Windows NT server remote access architecture

In the preceding figure, Win32 RAS API stands for the Win32® application programming interface (API) implementation of Remote Access Service. WinSockets stands for the Windows Sockets API; TAPI stands for telephony API; and IPX stands for Internetwork Packet Exchange, a transport protocol.

This architecture is important because, as previously described, internal and external ISDN adapters are differently configured and used by the Windows NT Server operating system. Internal ISDN device drivers provide network driver interface specification (NDIS) and WAN miniport device drivers. These drivers are installed when you configure the ISDN adapter by using the Adapter tab in the Network program in Control Panel.

However, external ISDN adapters are attached to the computer by using the serial (COM) port. Because of this, Windows NT Server processes an external ISDN device as a modem and as a result integrates an external ISDN device differently than an internal ISDN device.

Note

Vendors of ISDN hardware devices can obtain information about developing NDIS and WAN miniport drivers for their ISDN hardware device drivers by connecting to: http://www.microsoft.com/hwdev/devdes/isdnwin.html


Point-to-Point Protocol

The Point-to-Point Protocol (PPP) provides a standard method for transporting multiprotocol datagrams over point-to-point links. PPP does so by establishing and configuring different link and network-layer protocols to carry traffic from point to point. Control and data flow modules make up the PPP control protocols as illustrated in the following figure.

MHMiriam HarlineFigure 4.5 Microsoft PPP control modules

The preceding art shows Password Authentication Protocol (PAP), Challenge Handshake Authentication (CHAP), and Shiva Password Authentication Protocol (SPAP), which perform password authentication of RAS clients. Compression Control Protocol (CCP) is used to negotiate encryption with RAS clients. IPCP, IPXCP, NBFCP, and Other are the Internet Protocol (IP), NetWare IPX, NetBIOS Extended User Interface (NetBEUI), and Other protocol modules, which control RAS client sessions. HDLC stands for the High-level Data Link Control protocol.

PPP running under Windows NT Server supports external and internal ISDN adapters. The key difference for PPP between an external ISDN adapter and an internal ISDN adapter is that the external device sends byte-level PPP (also known as asynchronous PPP). The internal ISDN device, which uses an NDIS and WAN miniport driver, sends bit-level PPP (also known as synchronous PPP).

For compatibility with Windows NT Server, Microsoft recommends that external ISDN devices provide an asynchronous-to-synchronous PPP conversion feature. For information about external ISDN devices that can be used on a computer running Windows NT Server, see the Windows NT Hardware Compatibility List.


Using Remote Access Service with ISDN

A computer running Windows NT Server with RAS can be used to connect an intranet and remote users to the Internet. The connection to the RAS server computer over the telephone line provides a virtual WAN. Using this connection, local and remote users can access network resources, such as a computer running Internet Information Server.

Because Windows NT Server supports ISDN, you can configure RAS with ISDN connections to the Internet and to remote users. You can optimize the ISDN configuration to allow the RAS server to support the maximum number of remote client connections (256) or to provide the best possible bandwidth for a smaller number of connections.

By using multiple B channels for each Internet or remote client connection, you can maximize the available bandwidth for the connections. However, maximizing the bandwidth by this method reduces the total number of connections that can be supported. You can maximize bandwidth by using PPP Multilink, described in the following section.


Using PPP Multilink with ISDN

The PPP Multilink implementation under Windows NT Server is compliant with the Internet Engineering Task Force (IETF) PPP Multilink standard defined by Request for Comment (RFC) 1717. PPP Multilink protocol provides an inexpensive method that you can use to increase the bandwidth on your existing ISDN and analog telephone lines.

Multilink protocol enables you to combine the bandwidth capabilities of a communication device and telephone line into a single logical pipe. You can use Multilink protocol with analog modems, ISDN, PPTP, or X.25 communication links.

Windows NT Server 4.0 includes RFC-compliant support for the Multilink protocol as part of the Windows NT Server RAS service. Any remote clients that connect to the RAS server must also support a PPP Multilink implementation compliant with RFC 1717.

You can use the Multilink protocol feature only when your computer is configured with multiple WAN adapter devices that can be combined to form the logical PPP pipe over the communication link. The most common use for Multilink is to combine ISDN channels; however, you can also use it to bundle two or more analog modems, or an analog modem and an ISDN line.

For example, you can provide up to 128 – kilobit per second wire speeds on a single ISDN-BRI line by combining the two B channels. Each B channel provides a 64 – kilobit per second link, and the two combined achieve speeds of up to 128 kilobits per second. You can also combine an analog line with an ISDN line to increase bandwidth.

Note

When you combine both B channels under ISDN, you cannot use your second channel for other applications, such as fax or voice calls.

If you use PPP Multilink with ISDN, you must configure your network so that Windows NT – based remote clients connecting to the intranet or the Internet do so by connecting to a server that also supports PPP Multilink, such as a server running Windows NT Server with RAS server.

When using a pool of servers to support remote clients using PPP Multilink, you must also ensure the remote clients connect to the same server for each Multilink session. In other words, if the remote client connects to different servers during an attempted Multilink session, the separate B channel lines cannot be combined across servers. To combine B channels for increased bandwidth, a client's session must occur on one server.


Configuring Windows NT Server for ISDN

Windows NT Server 4.0 and 3.5x provide built-in support for ISDN. To connect to the Internet by using ISDN, you need to install and configure the Dial-Up Networking feature in Windows NT Server.

Before configuring ISDN on a computer running Windows NT Server, you need the following:

Installed internal or external ISDN adapter

ISDN telephone line service at the location where you will use dial-up networking to connect to the Internet

ISDN telephone line service at the remote location to which you want to connect, usually either your Internet service provider (ISP) or a RAS server

In general, it is recommended that you also use PPP with ISDN for connections to the Internet. This protocol is the one typically used to access the Internet over dial-up connections. To use PPP, you must have a PPP account with your ISP. If you currently have a Serial Line Internet Protocol (SLIP) account, you should request your ISP to change the account to PPP.

After you have installed your ISDN adapter and received notice from your telephone company your ISDN service is installed, you can configure Windows NT Server for your ISDN service.

Û To configure your ISDN device for ISDN-BRI Service

1. Click the Start button, point to Settings, and then click Control Panel.

2. Double-click the Network icon.

3. Click the Adapters tab.

4. In the Network Adapters list, click your ISDN device, and then click Properties.

5. Verify that the values selected in the I/O Port Base Address and Interrupt Number boxes are the values supplied by your ISDN device vendor. If not, click the correct values.

6. In the Page list, click SPID Settings.

In the Number of Terminals box, click the terminal number provided by your telephone company. For ISDN-BRI service, this number will be either 1 or 2. For more information, click the Help button.

8. In the SPID 1 box, type the value provided by your telephone company, and click OK.

– Or –

In the SPID 2 box, type the value provided by your telephone company, and click OK. If the value selected in the Number of Terminals box does not equal 2, the SPID 2 box is unavailable.

9. Click OK, and close the Control Panel.

After you have configured ISDN on your computer, you can enable PPP Multilink protocol by using the following procedure.

Û To enable Multilink on a RAS server

1. In Control Panel, double-click the Network icon.

2. Click the Services tab.

3. In the Network Services list, click Remote Access Service, and then click Properties.

4. In the Remote Access Setup dialog box, click Network.

5. In the Network Configuration dialog box, select the Enable Multilink check box, and then click OK.


Alternatives to ISDN

Large companies that connect to the Internet to provide services to a large number of remote users might consider alternative transmission technologies, such as Asynchronous Transfer Mode (ATM), dedicated Frame Relay, or T3 Internet connections. In the near future, new technologies will provide additional options for connecting to the Internet. These technologies include ones such as Asymmetric Digital Subscriber Line (ADSL), which can operate over existing telephone wires, and cable modems that operate over coaxial cable television wiring.

The following table illustrates when ISDN technology can provide adequate bandwidth, based on minimum bandwidth requirements of different application types, and when alternatives to ISDN should be considered.

Table 4.1 Alternatives to ISDN

Application type | Minimum bandwidth required | Acceptable transmission technology
Audio (FM mono quality) | 28.8 kilobits per second (Kbps) | Analog
Audio (FM stereo quality) | 144 Kbps | ISDN-BRI
Audio (CD quality) | 1.544 – 2.048 megabits per second (Mbps) for ISDN-PRI, T1 or E1;622 Mbps for ATM | ISDN-PRI, T1 or E1; ATM
Data communications | 9.6 Kbps – 28.8 Kbps for analog; 144 Kbps for ISDN-BRI | Analog; ISDN-BRI
Video (low end) | 144 Kbps | ISDN-BRI
Video conferencing | 1.544 – 2.048 Mbps for ISDN-PRI, T1 or E1; 622 Mbps for ATM | ISDN-PRI, T1 or E1; ATM
Video (broadcast quality) | 6 Mbps for ISDN-PRI; 622 Mbps for ATM | Dedicated leased lines; ATM
Virtual reality programs | 6 Mbps for ISDN-PRI; 622 Mbps for ATM | Dedicated leased lines; ATM

For more information about alternatives to ISDN, see Chapter 3, "Adding Bandwidth for Internet Connectivity."


MS Windows NT Resource Kit - Supplement 1

This book is dedicated to all who use and support Windows NT Server version 4.0.

Contributors to this book include the following:

Documentation Manager

Ken Western

Writing Manager

Peggy Etchevers

Technical Writers

June Blender Cahn, Maureen Carmichael, Peter Costantini, Jeff Howard, Jan Jolan James, Mitch Kief, Edward Lafferty, Cary Reinstein, Kate Robinson, Maureen Sullivan

Managing Editor

Sonia Marie Moore

Editing Lead

Shelly Hawkins

Technical Editors

Stephanie Briner, Miriam Harline, Kate Robinson, Sharon Schenck

Production Manager

Karye Cattrell

Production Lead

Nikole Faith

Production Team

Jay French, Cathy Pfarr, Jane Dow

Lead Graphic Designer

Chris Blanton

Design Support Team

Gabriel Varela, Sue Wyble, Jan Yeager

Software Program Manager

Ryan Marshall

Lead Software Developer

Martin Holladay

Software Tester

Cliff Hudson

Product Support Liaison

Todd Hafer

Technical Consultants

Reza Baghai, Bill Blomgren, Carl Calvello, Arren Conner, Lance Craig, Denise Y. Deng, Jerry Gallagher, James Gilroy, Scott Harrison, Chris Hawkins, Vic Horne, Joseph Hughes, Neel Jain, Murali Krishnan, Stuart Kwan, Edward Lafferty, Richard Lerz, David MacDonald, Rachid Ouchou, Cary Reinstein, Bob Ripley, Christophe Roberts, Bart Robertson, Craig Robicheaux, Rodger Seabourne, Nk Srinivas, Scott Suhy, David Treadwell, Brad Waters, Lester Waters, David Wohlferd, and numerous other hardworking Windows NT Developers, Program Managers, and Product Support Specialists

© 1996 Microsoft Corporation. All rights reserved.

Microsoft, MS, MS-DOS, XENIX, CodeView, and QuickC are registered trademarks of Microsoft Corporation in the USA and other countries.

Microsoft may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft.

IBM is a registered trademark of International Business Machines Corporation.

Intel is a registered trademark of Intel Corporation.

Lotus is a registered trademark of Lotus Development Corporation.

Tandy is a registered trademark of Tandy Corporation.

Document No. xxxx
12345-6

Printed in the United States of America.


Chapter 5 - Monitoring Virtual Memory

The Internet Information Server (IIS) runs as a Windows NT service and takes advantage of the full capability of the Windows NT virtual memory system. Virtual memory uses space on disk to extend the server's physical memory.

This chapter discusses how virtual memory is used on a Windows NT 4.0 server running Internet Information Server 2.0 (IIS). This chapter presents several approaches you can use to monitor and improve memory use. The material is intended as a technical guide for network administrators, but should also be useful for anyone running Internet Information Server—from a single source World Wide Web page publisher to the administrator of a large corporate network for an Internet service provider.

This chapter suggests some tools and techniques for monitoring virtual memory on servers running Internet Information Server. It covers the following topics:

"Virtual Memory on an IIS Server"

"Monitoring Server Memory"

"Monitoring the Working Set of the IIS process"

"Monitoring the IIS Object Cache"

"Monitoring the File System Cache"

"Suggestions for Optimizing Memory on an IIS Server"

Warning

To add or modify a Registry value entry, use administrative tools such as Control Panel or System Policy Editor whenever possible. Using a Registry editor (Regedit or Regedt32) to change a value can have unforeseen effects, including changes that can prevent you from starting your system.


Virtual Memory on an IIS Server

The Windows NT virtual memory system extends the server's physical memory by using space on disk. The virtual memory system reserves physical memory for items that are used frequently or are costly to retrieve, and moves unreferenced items to disk. If a process or service needs code or data on disk, the system retrieves the requested pages and delivers them to the process' working set in physical memory — all without intervention from the process. The system will also retrieve contiguous pages, if there is enough physical memory to hold them.

The challenge of a virtual memory system is to minimize disk I/O, which is slow, mechanical, and laborious compared to the speed at which items are written to and retrieved from physical memory. Minimizing disk I/O requires that the system keep as many items as possible in physical memory.


Physical Memory on an IIS Server

A server running Internet Information Server should have sufficient physical memory to keep the following items in physical memory:

Program code for IIS services. This code occupies only 400K even with HTTP, FTP, and Gopher running simultaneously. This code is part of the working set of the Internet Information Server process, Inetinfo.exe, and can be paged to disk.

Frequently accessed Web page files. The number and size of these files varies widely with the installation. These files are stored in the file system cache, an area of physical memory reserved for frequently and repeatedly used pages. The remaining files are stored on disk until needed.

Frequently used objects. These are objects that are costly to retrieve and are frequently reused by the service, such as file handles, file directory listings, and parsed Internet Database Connector queries and their results. These objects are stored in the IIS Object Cache, a cache maintained by the IIS service. The IIS Object Cache is also part of the working set of the Internet Information Server process, Inetinfo.exe, and can be paged to disk.

IIS Log buffers. When IIS Logging is enabled, Internet Information Server maintains two buffers in which it accumulates log data in ANSI characters before it writes the data to disk. By default, each buffer is 64K. These buffers are part of the working set of the Internet Information Server process. Logged data also appears in the file system cache because data is cached when the buffer contents are written to disk.

TCB Table. TCP maintains a hash table of transmission control blocks (TCBs) to store data for each TCP connection. A control block is attached to the table for each active connection. The control block is deleted shortly after the connection is closed. The TCB table is part of the operating system's nonpaged memory pool. As such, the TCB table must remain in physical memory; it cannot be paged to disk.

HTTP Connection data structures. HTTP maintains pageable data structures to track its active connections. When these data structures are in physical memory, they are counted as part of the working set of the Internet Information Server process.

Pool threads. The threads that execute the code for the services are stored in the nonpaged pool in physical memory, along with other objects used by the operating system to support Internet Information Server and for other uses. Threads must remain in physical memory; they cannot be paged to disk.

You can measure your server's physical memory and measure the proportion of physical memory used directly or indirectly by Internet Information Server. You can also log the data over time to identify patterns of memory use.


Monitoring Server Memory

Monitoring the physical memory of a server running Internet Information Server involves measuring the size of the areas in physical memory used by IIS and assuring that enough space is available to contain the elements Internet Information Server needs to store. The space should be sufficient for normal operation and for sporadic peaks in demand.

The Windows NT virtual memory system is designed to be self-tuning. The Virtual Memory Manager and Cache Manager adjust the size of the file system cache, the working sets of processes, the paged and nonpaged memory pools, and the paging files on disk to produce the most efficient use of available physical memory. Similarly, the IIS service regulates the size of the IIS Object Cache. Therefore, the primary purpose of monitoring memory in a Windows NT server running Internet Information Server is to make sure that the server has enough physical memory, not to adjust the size of each memory component as might be the case with other operating systems.


How to Monitor Overall Server Memory

Internet Information Server and its component services, HTTP Service (WWW), the File Transfer Protocol (FTP) Service, and Gopher Service, run jointly in a user-mode process called Inetinfo.exe. Like most well-designed user-mode processes, the IIS services derive much of their benefits from the Windows NT operating system architecture, including the Windows NT Security model, RPC communication, messaging, the file systems, and other operating system services. Thus, monitoring memory for Internet Information Server begins with monitoring overall server memory, even on a multipurpose server.


Methods of Monitoring Server Memory

This section is a brief review of the most important memory monitoring techniques. Windows NT Workstation Resource Guide includes a detailed discussion of some basic techniques for monitoring memory in Chapter 12, "Detecting Memory Bottlenecks," and Chapter 15, "Detecting Cache Bottlenecks." For more information on the tools discussed in this section, see Chapter 10, "About Performance Monitor," and Chapter 11, "Performance Monitoring Tools" in the Windows NT Workstation Resource Guide. Programmers can find additional memory optimizing techniques in the Win32 Software Development Kit.

Many performance monitoring tools measure system-wide and per-process memory use. These tools include Task Manager, Process Monitor (Pmon.exe), Process Viewer (Pviewer.exe), Process Explode (Pview.exe), PerfLog (Pdlcnfig.exe and Pdlsvc.exe), and Performance Monitor. PerfLog and Performance Monitor can measure memory use over time.

Here are a few guidelines for using Performance Monitor and PerfLog to monitor overall server memory use:

Monitor available memory. The server must maintain enough available memory to support the operating system and all applications and services it runs. Compare the total physical memory available to Windows NT to the available memory remaining when you are running all server services. To gather more reliable data, log this value over time, making certain to include periods of peak activity. The system attempts to keep available bytes at 4MB or more, but it is prudent to keep at least 5 percent of memory available for peak use.

To determine the physical memory available to Windows NT, double-click My Computer, and then click About Windows NT from the Help menu. Memory Available to Windows NT is displayed above the OK button. Total physical memory is also listed on the Performance tab in Task Manager. To start Task Manager, press ctrl+shift+esc.

To track available memory, use Performance Monitor or PerfLog to log the Memory: Available Bytes counter.

Monitor paging. Continuous high rates of paging indicate a memory shortage. Paging occurs when code or data requested by an application or service is not found in physical memory and must be retrieved from disk. The more memory the server has, the more data the system can store in memory and the more likely it is that the code or data requested is stored in memory. If required data is stored in memory, it does not need to be paged in from disk.

Paging is measured in several ways:

Numbers of page faults. Page faults occur when the system cannot find a requested page in the working set of the process that requested the page. The system also counts a page fault on file accesses if the requested page is not found in the file system cache.

To measure page faults on working sets and on the file system cache, use Performance Monitor or PerfLog to log the Memory: Page Faults/sec and Memory: Cache Faults/sec counters.

Disk reads due to page faults. All page faults interrupt the processor. Only hard faults, those that require reading from disk, delay system response. Monitor hard faults and compare the rate of hard faults to all page faults. In general, a sustained rate of more than five hard faults per second indicates a memory shortage.

To measure hard faults, use Performance Monitor or PerfLog to log the Memory: Page Reads/sec counter. Use the Memory: Page Faults/sec counter as an indicator of all page faults.

Monitor the file system cache. The file system cache is the working set of the file system. This cache is a reserved area in physical memory where the file system stores its recently used and frequently used data. By default, the system reserves about 50 percent of physical memory for the file system cache, but the system trims the cache if it is running out of memory. A large and effective file system cache is vital to IIS servers, which function like specialized file servers. This topic is discussed in more detail in "Monitoring the File System Cache" later in this chapter.

Monitor the size of the paging files. The paging files on disk back up committed physical memory. The larger the paging file, the more memory the system can commit. Windows NT creates a paging file on the system disk. You can create a paging file on each logical disk, and enlarge existing files.

To monitor the paging files, use Performance Monitor or PerfLog to log Process: Page File Bytes: Total.

Monitor the size of the paged and nonpaged memory pools. The system's memory pools hold objects created and used by applications and the operating system. The paged pool holds items that can be paged to disk. Items in the non-paged pool must remain in physical memory. The contents of the memory pools are accessible only in privileged mode. On servers running Internet Information Server, the IIS threads that service connections are stored in the nonpaged pool, along with other objects used by the service, such as file handles.

To monitor the pool space for all processes on the server, use Performance Monitor or PerfLog to log the Memory: Pool Paged Bytes and Memory: Pool Nonpaged Bytes counters. To monitor the pool space used directly by Internet Information Server, log the Process: Pool Paged Bytes: Inetinfo and Process: Pool Nonpaged Bytes: Inetinfo counters for the Inetinfo process.

These general monitoring techniques are useful for any Windows NT Workstation or Server. The following sections discuss techniques for monitoring components specific to the IIS service.


Monitoring the Working Set of the IIS Process

A server running Internet Information Server must have enough physical memory to support the Internet Information Server process. The physical memory visible to a process is called its working set. If the working set of the Internet Information Server process is not large enough, IIS is not able to store its code and frequently used data in physical memory. Therefore, the IIS services are delayed by having to retrieve code and data from disk.

The system continually adjusts the size of the working set of a process as the process runs. The amount of space the system provides to the working set depends on the amount of memory available to the system and the needs of the process.

This section describes the working set of the process in which Internet Information Server runs. The section suggests methods for monitoring the size of the Internet Information Server working set over time and explains how to determine whether the working set of the Internet Information Server process is large enough to enable IIS to run efficiently.


About the Inetinfo Working Set

Internet Information Server runs in a pageable user-mode process called Inetinfo.exe. The HTTP, FTP, and Gopher services run in the Inetinfo process and share the threads of the process. The working set of the Inetinfo process is the space in physical memory visible to the Inetinfo process.

Internet Information Server stores its code and frequently used data in the Inetinfo working set. For Internet Information Server to run efficiently, it must be able to maintain all of its code and the most frequently used files in its working set. In addition, the working set of the Inetinfo process should be large enough to contain the IIS Object Cache, data buffers for IIS Logging, and the data structures HTTP uses to track its active connections.

There is no fixed optimal size for the Inetinfo working set. The requirements of the working set vary depending upon the number of connections maintained, the number and size of files, and the use of other supporting services, such as security features and logging.

You can monitor the Internet Information Server process as it runs on your server to determine whether its working set is large enough to support the IIS services.


Monitoring the Inetinfo Working Set

You can monitor the size and effectiveness of a working set of the Inetinfo process by using several tools that monitor processes, such as:

Process Viewer (Pviewer.exe)

Process Explode (Pview.exe)

Process Monitor (Pmon.exe)

Performance Data Log Service (PerfLog) (Pdlcnfig.exe and Pdlsvc.exe)

Performance Monitor (Perfmon.exe)

These tools are described in detail in the Windows NT Workstation Resource Guide, Chapter 10, "About Performance Monitor," and Chapter 11, "Performance Monitoring Tools."


Using Performance Monitor to Monitor the IIS Working Set

You can use the following Performance Monitor counters to monitor the working set of Inetinfo.exe. Internet Information Server and its component services run in the context of the Inetinfo process. (You can monitor the IIS Object Cache separately. For more information, see "Monitoring the IIS Object Cache" later in this chapter.)

Table 5.1 Performance Monitor Counters for the IIS Working Set

Counter

Indicates

Memory: Available Bytes

The amount of physical memory remaining and available for use, in bytes. This counter displays the amount of memory not currently used by the system or by running processes. This counter displays the last observed value, not an average.

The operating system attempts to prevent this value from falling below 4MB. The system often trims the working sets of processes to maintain the 4MB minimum available memory.

Process: Working Set: Inetinfo

Size of the working set of the process, in bytes. This counter displays the last observed value, not an average over time.

The working set is the space in physical memory available to the process. The working set contains recently used code and data. The working set of Inetinfo also contains the IIS Object Cache, buffers for IIS Log data, and the data structures HTTP uses to track connections.

Process: Page Faults/sec: Inetinfo

Hard and soft faults in the working set of the process.

Memory: Page Faults/sec

Hard and soft faults for all working sets running on the system.

Memory: Page Reads/sec

Hard page faults. This counter displays the number of times the disk is read to satisfy page faults. This counter displays the number of read operations, regardless of the number of pages read in each operation.

A sustained rate of 5 reads/sec or more might indicate a memory shortage.

Memory: Pages Input/sec

One measure of the cost of page faults. This counter displays the number of pages read to satisfy page faults. One page is faulted at a time, but the system can read multiple pages to prevent further faults.

The counters in the preceding table are included in IISMem.pmw, a Performance Monitor workspace settings file on the Supplement 1 CD.

You should log this data for several days. You can use Bookmark in the Performance Monitor log to identify times of unusually high and low server activity.


Analyzing the Working Set Data

The working set of Inetinfo should be large enough to contain the Internet Information Server code and the data IIS references. The Inetinfo working set includes its code, objects in the IIS Object Cache, data structures for tracking connections, buffers for holding IIS Log data, and other data it uses. If the Inetinfo working set is not large enough to contain its code and data, the system must read and write the code and data from disk. Increased disk activity can seriously degrade server performance, particularly if code must be read from disk.

The following sections describe how to use data about the Inetinfo working set to determine if the server has enough memory to support Internet Information Server efficiently.


Available Bytes and the Inetinfo Working Set

If the system has sufficient memory, it can maintain enough space in the Inetinfo working set so that Internet Information Server rarely needs to perform disk operations. One indicator of memory sufficiency is how much the size of the Inetinfo process working set varies in response to general memory availability on the server.

You can use the Memory: Available Bytes counter as an indicator of memory availability and the Process: Working Set: Inetinfo counter as an indicator of the size of the working set of the Internet Information Server process. Be sure to examine data collected over time because these counters display the last value observed, not an average.

Tip

To determine whether a counter reports instantaneous or averaged data, look at its counter type. The counter type determines how the data Performance Monitor collects from internal counters is calculated and averaged.

For example, the counter type of Memory: Available Bytes, is Perf_Counter_Rawcount. Counters of this type report only the last value observed in each sample interval.

Counters.hlp, a help file for the Performance Monitor counters, lists the counter type of each counter. Counters.hlp also includes a detailed description of each counter type. You can find the most current version of Counters.hlp on the Supplement 1 CD.

Note how the size of the Inetinfo working set changes in response to changes in available bytes. In general, when available bytes fall, the system attempts to provide more available bytes. To do so, the system recovers bytes by taking bytes from the working sets of processes. This strategy provides more available bytes to the system, but it is likely to increase the rate of page faults for the process because the process must now retrieve data from disk that was once in its working set. When the rate of page faults rises, the system attempts to expand the working set to lower the page fault rate and the size of the working sets fluctuate accordingly.

After you have reviewed data on the varying size of the Inetinfo working set, you can use its page fault rate to determine how large the working set should be to operate efficiently.


Page Faults and the Inetinfo Working Set

There is no recommended value for the number of available bytes or for the size of the Inetinfo working set. The requirements vary widely with each system configuration and the services each system runs. You can determine whether your system has enough available bytes and a large enough Inetinfo working set by monitoring page faults.

The page fault counters for a process are incremented when the process requests code or data that is not found in its working set. The data might be found elsewhere in memory, such as in the file system cache, in the working set of another process, or in transition to disk. The system might also have to read the data from disk.

A sustained high rate of page faults for a process usually indicates that its working set is not large enough to support the process efficiently. If the system doesn't have enough available memory to enlarge the working set, it cannot lower the page fault rate.

Compare your data on the size of the Inetinfo working set to the rate of page faults attributed to the working set. Use the Process: Working Set: Inetinfo counter as an indicator of the size of the working set. Use the Process: Page Faults/sec: Inetinfo counter to indicate the rate of page faults for the Internet Information Server process.

There are two kinds of page faults. The page faults that affect performance significantly are hard faults, page faults that require reading from disk to retrieve a referenced page. Soft faults, page faults resolved when the page is found elsewhere in physical memory, interrupt the processor but do not affect performance significantly.

A sustained high fault rate of hard faults generally indicates a memory shortage. When the server does not have enough memory to support a sufficiently large working set for the process, the server is not able to lower the page fault rate to an acceptable level and performance is degraded.

Unfortunately, the Process: Page Faults/sec counter includes both hard and soft faults. There are no counters for measuring the hard faults attributable to each process separately. However, Memory: Page Reads/sec and Memory: Pages Input/sec are good indicators of hard faults for the whole system. If the system is incurring large numbers of hard page faults, it is likely that you have a memory bottleneck. Adding memory is likely to improve performance. For more information on memory bottlenecks, see Chapter 6, "Preventing Processor Bottlenecks."


Monitoring the IIS Object Cache

The IIS service maintains the IIS Object Cache, a cache of objects that the HTTP, FTP, and Gopher services use frequently. The Object Cache is also used for objects that are hard to retrieve. The IIS Object Cache is designed to improve the performance of Internet Information Server by keeping these objects readily available to the process. The primary components of the IIS Object Cache are open file object handles and directory listings, but the cache also stores parsed Internet Database Connector queries and their responses, as well as other service-specific objects.

This section describes the IIS Object Cache and suggest methods of monitoring its size and efficiency.


About the IIS Object Cache

The IIS Object Cache is part of the working set of the Internet Information Server process in physical memory. The objects stored in the Object Cache are related to objects in the operating system's nonpaged memory pool. The Object Cache can be paged to disk if memory is not sufficient to support a large enough working set for the Internet Information Server process. It is important to provide enough physical memory to maintain the Object Cache in the working set.

As you might expect, the size of the IIS Object Cache affects its performance. If the cache is not large enough, the system will have to retrieve the objects from disk. If the cache is too large, it will waste space in memory. By default, Internet Information Server allocates 10 percent of physical memory to the IIS Object Cache. This is an optimal size for most configurations. You can change the amount of physical memory allocated to the IIS Object Cache by entering a new value in the MemoryCacheSize value entry in the Registry.

For more information on changing the MemoryCacheSize value entry, see Regentry.hlp, a Registry help file on the Supplement 1 CD. MemoryCacheSize is also described in the online Windows NT Server Microsoft Internet Information Server Installation and Administration Guide.

You can measure the size and effectiveness of the IIS Object Cache by using Performance Monitor.


Using Performance Monitor to Monitor the IIS Object Cache

Performance Monitor includes a set of extensible counters you can use to monitor the IIS services. These counters are installed in Performance Monitor when you run Internet Information Server Setup.

For descriptions of the Internet Information Server counters, in the Performance Monitor Add to Chart dialog box, select the counter name, then click the Explain button. You can also use Counters.hlp, a help file for the Performance Monitor counters. The most recent version of Counters.hlp is included on the Supplement 1 CD. Previous versions of Counters.hlp did not include descriptions of the Internet Information Server counters.

Many of the Internet Information Server counters display the last observed value or a cumulative count, not an average value or rate. To determine what a Performance Monitor counter displays, view its counter type in Counters.hlp. The counter type determines how the data Performance Monitor collects from internal counters is calculated and averaged. Counters.hlp lists the counter type of each counter and a description of the Performance Monitor counter types.

Performance Monitor includes four performance objects for measuring Internet Information Server performance:

HTTP Service

FTP Server

Gopher Service

Internet Information Services Global

The Internet Information Services Global performance object contains counters used by all three services. The counters that monitor the IIS Object Cache, which is shared by the services, are part of this performance object.

The following table lists the counters recommended for monitoring the IIS Object Cache. You should log the counters over time to record trends in the size, content, and effectiveness of the IIS Object Cache.

Table 5.2 Performance Monitor Counters for the IIS Object Cache

Counter

Indicates

Internet Information Services Global:
Cache Size

Maximum amount of space allocated for the IIS Object Cache, in bytes. This counter does not indicate how much of the space is occupied.

The default is 10% of physical memory.

(To change the size of the cache, edit the HKEY_LOCAL_MACHINE\System\
CurrentControlSet
\Services
\Inetinfo
\Parameters
\MemoryCacheSize

value entry in the Registry).

Internet Information Services Global:
Cache Used

Space in the IIS Object Cache that is currently being used to store objects, in bytes.

Compare Internet Information Services Global: Cache Used to Internet Information Server: Cache Size.

Internet Information Services Global:
Cache Hits

Internet Information Services Global:
Cache Misses

Internet Information Services Global:
Cache Hits %

A measure of the efficiency of the IIS Object Cache. Internet Information Services Global: Cache Hits and Internet Information Services Global: Cache Hits % (Internet Information Services Global: Cache Hits/
(Internet Information Services Global: Cache Hits + Internet Information Services Global: Cache Misses)) demonstrate how often data sought in the IIS Object Cache is found. Internet Information Services Global: Cache Misses indicates how often the system must search elsewhere in memory or on disk to satisfy a request.

Internet Information Services Global: Cache Hits and Internet Information Services Global: Cache Misses display the total number of hits and misses since the service started. These values always remain the same or increase over time.

Internet Information Services Global: Cache Hits % displays an instantaneous value, not an average over time.

Table 5.2 Performance Monitor Counters for the IIS Object Cache (Continued)

Counter | Indicates
Internet Information Services Global: Cache Flushes | How many times an object was deleted from the IIS Object Cache, either because it timed out, or because the object changed.
Internet Information Services Global: Objects Internet Information Services Global: Cached File Handles Internet Information Services Global: Directory Listings | The number of objects currently stored in the IIS Object Cache. Internet Information Services Global: Objects = Internet Information Services Global: Cached File Handles + Internet Information Services Global: Directory Listings + other objects, such as IDC queries and responses.

These counters are included in IISCache.pmw, a Performance Monitor workspace settings file on the Supplement 1 CD. The workspace sets up a chart and a report of the counters.


Troubleshooting the Internet Information Services Counters

When you are monitoring a server remotely, the Internet Information Services Global, HTTP Service, FTP Server, and Gopher Service performance objects and counters appear in Performance Monitor only when the related IIS service is running on the computer being monitored. If you do not see these objects in the Add to Chart dialog box, close Performance Monitor on your computer, start the IIS service on the computer being monitored, and then start Performance Monitor again.

If the objects and counters still do not appear in the Add to Chart dialog box, or if they appear intermittently, make certain that no one else is using Performance Monitor to monitor the remote computer. All remote users must restart Performance Monitor after the IIS service is started for any of them to see the Internet Information Server counters. Also, check the Event Viewer application event log for errors. Errors in the service or in loading the counters can also prevent Performance Monitor from displaying the counters.

For more information on troubleshooting extensible Performance Monitor counters, see "Troubleshooting Features" in Windows NT Workstation Resource Guide, Chapter 10, "About Performance Monitor."


Analyzing the IIS Object Cache Data

The Performance Monitor counters for Internet Information Server monitor three different aspects of the IIS Object Cache: its contents, its size, and its performance. This section explains how to interpret the data you collect by using the Performance Monitor Internet Information Server counters.


Analyzing IIS Object Cache Contents

You can use the Performance Monitor counters to reveal the contents of the IIS Object Cache. The Internet Information Services Global: Objects counter counts all objects. The Internet Information Services Global: Cached File Handles and Internet Information Services Global: Directory Listings counters are subsets of the Internet Information Services Global: Objects counter. At any given time, the difference between the total number of objects and the sum of Internet Information Services Global: Cached File Handles and Internet Information Services Global: Directory Listings is equal to the number of other objects stored in the cache. Internet Information Services Global: Directory Listings are most important to servers running FTP service.

When interpreting the counters, remember that they show the most recently observed value, not an average.

The primary reason to count cache contents is to relate the contents to the size of the cache.


Analyzing the Size of the IIS Object Cache

The size of the IIS Object Cache is not a common problem, but it is worth monitoring because the cache is not efficient if it is too small.

Compare Internet Information Services Global: Cache Used to Internet Information Services Global: Cache Size over time. These are instantaneous values, not averages, so it is important to use a large data sample. If the Internet Information Services Global: Cache Used to Internet Information Services Global: Cache Size ratio is more than .9, and you have sufficient available memory (which you can determine by using Memory: Available Bytes), you might consider increasing the maximum size of the cache to 5MB. Alternatively, if the ratio of Internet Information Services Global: Cache Used to Internet Information Services Global: Cache Size remains less than .2 over time, consider reducing the cache size.

To change the size of the cache, use the MemoryCacheSize value entry in the Registry. It is located in:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Inetinfo
\Parameters.

After changing the value, restart the service, log the IIS Object Cache counters again, and watch for changes in performance.


Analyzing the Performance of the IIS Object Cache

Cache performance is judged by how often objects sought in the cache are found there. Frequent cache misses harm performance if they result in disk I/O. There are no fixed standards for cache performance, although a value of 80 to 90 percent for Internet Information Services Global: Cache Hits % is considered to be excellent for sites with many static files. If Internet Information Services Global: Cache Hits and Internet Information Services Global: Cache Hits % are very low or Internet Information Services Global: Cache Misses is quite high, the cache might be too small to function effectively. Adding memory increases the cache size and should improve its performance.

Cache flushes can also affect the performance of the IIS Object Cache. Cache flushes are regulated, in part, by an internal timer. The timer activates the object-cache scavenger which deletes expired objects. Objects are flushed from the cache if they change or if they time out before they are reused. If the timer is too quick, objects can be flushed from the cache too frequently. If the timer is too slow, objects can be wasting precious physical memory space.

To measure cache flushes, compare the number of cache flushes over time to the number of cache misses and to the rate of page faults of the IIS process (as indicated by the Process: Page Faults/sec: Inetinfo counter. It is important to observe these values over time. Like the other Internet Information Server counters, Internet Information Services Global: Cache Flushes displays an instantaneous value, not an average. If a high rate of cache flushes is associated with elevated cache misses and page faults, the cache might be flushed too frequently.

If you suspect that cache flushes are occurring too rapidly or too infrequently, you might want to change the rate at which unreferenced objects are flushed from the Internet Information Server cache. Make sure you have ample memory before increasing the time between flushes. To change the flush rate, use the ObjectCacheTTL value entry in the Registry. It is located in:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Inetinfo
\Parameters.

For more information about ObjectCacheTTL, see Regentry.hlp, the Registry help file, on the Supplement 1 CD.


Monitoring the File System Cache

The file system cache is an area of physical memory reserved for frequently and repeatedly used file system data (it does not store code pages). This cache is maintained by the Windows NT Cache Manager for use by all processes. Processes map or copy files into the cache, depending on how they will use the files. If a process finds a page it needs in the cache, it can avoid costly disk I/O.

Servers running Internet Information Server are well suited to take advantage of the performance gains provided by the cache. Therefore, it is important that you provide enough physical memory to the server to allow the operating system to maintain the cache at an optimal size.

This section explains how Internet Information Server uses the file system cache, how to monitor the size and efficiency of the cache, and how to interpret the data you collect.


How IIS Uses the File System Cache

The IIS services rely on the operating system to store and retrieve frequently used Web pages and other files from the file system cache. The file system cache is particularly useful for servers of static Web pages. Web pages tend to be used in repeated, predictable patterns. Files read repeatedly are more likely to be found in the cache.

Also, Internet Information Server always reads sequentially. Sequential reading takes advantage of a Windows NT Cache Manager feature called a read ahead. A read ahead occurs when the Cache Manager's predictive algorithms detect sequential reading and begin to read larger blocks of data in each read operation. Read aheads can provide a significant performance boost to the process.

The IIS services use the file system cache and the IIS Object Cache. Sometimes, the caches are used together. When a thread of an IIS service needs to open a file, the thread requests a file handle from the operating system. When the thread receives the handle, the thread uses the handle to open the file. Then, if space permits, the thread stores the handle in the IIS Object Cache and the system stores the file data in the file system cache. Later, if that thread, or any other thread, needs the file, the file handle can be retrieved from the IIS Object Cache and the file contents can be retrieved from the file system cache.

The performance of IIS servers can benefit substantially from the file system cache, but only when the cache is large enough to hold all of the files the server needs. You can measure the size and effectiveness of the file system cache by using Performance Monitor.


Using Performance Monitor to Monitor the File System Cache

Performance Monitor includes several counters in the Memory and Cache performance objects that monitor the size and effectiveness of the file system cache. The following table lists these counters.

Table 5.3 Performance Monitor Counters for the File System Cache

Counter

Indicates

Memory: Cache bytes

The size of the cache, in bytes. This counter displays the last observed value; it is not an average.

Memory: Cache faults/sec

How often data sought in the file system cache is not found there. The count includes faults for data found elsewhere in memory, as well as faults that require disk operations to retrieve the requested data.

This counter displays the number of faults, without regard for the number of pages retrieved in response to the fault.

Cache: MDL Reads/sec

How often the system attempts to read large blocks of data from the cache.

Memory Descriptor List (MDL) Reads are read operations in which the system uses a list of the physical address of each page to help it find the page.

MDL reads are often used to retrieve cached Web pages and FTP files.

Table 5.3 Performance Monitor Counters for the File System Cache (Continued)

Counter | Indicates
Cache: MDL Read Hits % | How often attempts to find large sections of data in the cache are successful. You can use the Cache: MDL Read Hits % counter to calculate the percentage of MDL misses. Misses are likely to result in disk I/O.
Cache: Data Maps/sec | How often pages are mapped into the cache from elsewhere in physical memory or from disk. To measure the percentage of data maps from elsewhere in physical memory, use Cache: Data Map Hits %. The inverse of Cache: Data Map Hits % indicates data maps from disk.
Cache: Read Aheads/sec | A measure of sequential reading from the cache. When the system detects sequential reading, it anticipates future reads and reads in larger blocks of data. The read ahead counters are a useful measure of how effectively an application uses the cache.
Memory: Page Faults/sec | Hard and soft faults in the working set of the process. This counter displays the number of faults, without regard for the number of pages retrieved in response to the fault.
Memory: Page Reads/sec | Hard faults in the working sets of processes and in the file system cache.

These counters are included in IISMem.pmw, a Performance Monitor workspace settings file on the Supplement 1 CD. You should log this data for several days. You can use bookmarks in Performance Monitor to note times of unusually high and low server activity.


Analyzing the File System Cache Data

You can use the data you collect in Performance Monitor to evaluate whether your server has enough memory to support an effective file system cache. This evaluation consists of the following three steps:

Determine how the size of your server's file system cache varies over time.

Determine the extent to which the performance of your server's cache varies with the size of the cache.

Verify that the server has enough memory to support an effective cache even when the server is most active.

The following sections provide information to help you with this evaluation.


Analyzing Cache Size Data

The Windows NT Cache Manager adjusts the size of the file system cache based on whether a computer is a workstation or a server, the amount of physical memory in the computer, and the applications and services the computer is supporting. In general, it is counterproductive to override the Cache Manager and manipulate the cache size directly. If the cache is too small to be effective, it is best to increase the amount of physical memory on the computer, or to redistribute memory-intensive applications to other servers.

The Performance Monitor Memory: Cache Size counter is a useful indicator of the size of the file system cache. Task Manager also displays the size of the file system cache in the File Cache field of its Performance tab.

You can use also use Performance Monitor or PerfLog to log the Memory: Cache Size counter. A log of cache size reveals how the size of the file system cache changes over time. Compare this data to a measure of general memory availability, such as data from the Memory: Available Bytes counter. In general, when memory is scarce, the system trims the cache and when memory is ample, the system enlarges the cache.

Note the points in the log when the cache is smallest. Keep track of how small the cache gets and how often the cache is small. Also, note how much system memory is available when the cache size is reduced. This data is useful when associating the size of the cache to its performance.


Analyzing Cache Performance Data

You can use the Performance Monitor data to evaluate the performance of the file system cache on your server. The file system cache is judged based on how often files sought in the cache are found there. A hit is recorded when requested files are found in the cache. A miss or fault is recorded when requested files are not found. Misses and faults indicate how often the system needs to do extra work to retrieve files from somewhere other than the cache.

To evaluate the performance of your server's file system cache, chart a Performance Monitor log of Cache: MDL Read Hits %. The file system cache is performing well when this value is highest. Values near 100 percent are not uncommon on IIS servers with ample memory. Subtract the percentage of hits from 100 percent to determine the number of misses. Misses on MDL reads usually require disk operations to find the requested data.

MDL Reads are the most common type of read used for retrieving many contiguous pages. Typically, MDL Reads are the most common read operation on servers running Internet Information Server. To determine which type of cache read is most common on your server, create a Performance Monitor report of the rates of different types of cache reads. Include the Cache: Copy Reads/sec, Cache: Data Maps/sec, Cache: Fast Reads/sec, Cache: MDL Reads/sec, and Cache: Pin Reads/sec.

You can also use the Memory: Cache Faults/sec counter to indicate how often data sought in the file system cache is not found there. This value should be as small as possible. The Memory: Page Faults/sec and Memory: Page Reads/sec counters are included to help you relate the fault rate of the cache to the fault rate in the system as a whole. Memory: Cache Faults/sec is a component of Memory: Page Faults/sec. The ratio of Memory: Cache Faults/sec to Memory: Page Faults/sec indicates the proportion of faults occurring in the cache as opposed to the working sets of processes.

A high rate of cache faults can indicate a memory shortage. But it can also indicate a less than optimal organization of data on disk. If the files used in sequence are stored on the same logical partitions of the same disk, they are more likely to benefit from the Windows NT Cache Manager's optimizing strategies, such as read aheads. The Memory: Read Aheads/sec counter displays the rate of sequential reading from the cache.


Comparing Cache Size and Performance Data

You can determine the extent to which the performance of the file system cache varies with the size of the cache. Compare the size of the cache over time to the rate at which data sought in the cache is found there.

Use the Memory: Cache Bytes counter as an indicator of the size of the cache. Use Memory: Cache Faults/sec as an indicator of the rate of cache misses, and Cache: MDL Read Hits % as an indicator of the rate of cache hits.

If Memory: Cache Faults/sec rises and Cache: MDL Read Hits % falls when the file system cache is smaller, the cache might be too small to be of much benefit to the server. A less effective file system cache is likely to degrade the performance of an IIS server significantly, especially if the size of the cache is often reduced due to a general memory shortage.

If cache performance is poor when the cache is small, use the data you have collected to infer why the cache size is reduced. Choose a period when the cache is small and note the available memory on the server and the processes and services running on the server, including the number of simultaneous connections supported.

When you add physical memory to your server, the system allocates more space to the file system cache. A larger cache is almost always more efficient. In addition, defragmenting your disks makes it more likely that related pages are copied into the cache together and this improves the hit rate of the cache. Finally, consider reducing the workload on the server by moving some of the load to another server.


Suggestions for Optimizing Memory on an IIS Server

Servers running Internet Information Server, like all high-performance file servers, benefit from ample physical memory. Generally, the more memory you add, the more the servers use and the better they perform. Most IIS servers perform acceptably with 32MB of memory. However, if you are running memory-intensive applications, like Common Gateway Interface (CGI) applications, you might need up to five times more memory to prevent a memory bottleneck.

Here are a few suggestions for optimizing memory performance without adding memory:

Improve data organization. Keep related Web files on the same logical partitions of a disk. Keeping files together improves the performance of the file system cache and reduces the size of the process's working set. Also, defragment your disks. Even well organized files can take more time to retrieve if they are fragmented.

Try disk mirroring or striping. The optimum configuration is to have enough physical memory to hold all static Web pages. However, if pages must be retrieved from disk, use mirroring or striping to make reading from disk sets faster.

Replace or convert CGI applications. CGI applications use three to five times more processor time and memory space than equivalent ISAPI extensions. If you cannot or choose not to replace your CGI applications or to convert them to ISAPI extensions, you might need to add additional processors and memory. For more information on CGI and ISAPI applications, see Chapter 9, "Monitoring Dynamic Page Generation."

Enlarge paging files. Add paging files and/or increase the size of your paging files. Windows NT creates one paging file on the system disk, but you can create a paging file on each logical partition of each disk.

Resize the IIS Object Cache. If the system has enough memory, and most of the IIS Object Cache is used, consider increasing the size of the IIS Object Cache (MemoryCacheSize) or lengthening the period that an unused object can remain in the cache (ObjectCacheTTL). Alternatively, if memory is scarce and the contents of the object cache are volatile, consider reducing the size of the object cache or increasing the rate at which the cache is flushed.

Change the balance of the cache to working set. By default, Windows NT servers are configured to give preference to the file system cache over the working sets of processes when allocating memory space. Although IIS servers benefit from a large file system cache, the Maximize Throughput for File Sharing option often causes the Internet Information Server pageable code to be written to disk, which results in lengthy processing delays. To avoid these processing delays, set Server properties to the Maximize Throughput for Network Applications option.

Û To change Server properties:

1. Double-click the Network icon in Control Panel.

2. Click the Services tab.

3. Click Server to select it, and then click the Properties button.

4. Click Maximize Throughput for Network Applications, and then click OK.

5. Restart the computer.

Limit connections. If your server is running out of memory, limiting the number of connections on the server might help because some physical memory is consumed by the data structures the system uses to keep track of connections.

Administrators can use the Internet Service Manager to limit the number of connections. On the property page for each service, click the Service tab, then change the value in the Maximum Connections field. The following table shows the default values for maximum connections by service.

Table 5.4 Default Values for Maximum Connections

Service | Default Maximum Connections
FTP | 1,000
Gopher | 1,000
WWW (HTTP) | 100,000


Chapter 6 - Preventing Processor Bottlenecks

Chapter 6 - Preventing Processor
Bottlenecks

Servers running Internet Information Server (IIS) rely on the speed and efficiency of their processors. The Internet Information Server code is multithreaded for efficient scaling on single-processor and multiprocessor computers and is largely self-tuning. Nonetheless, processor bottlenecks are a potential problem on very active servers running Internet Information Server, even on servers with multiple processors.

A processor bottleneck occurs when one or more processes occupy nearly all of the processor time of all processors on the computer. In a bottleneck, the ready threads of processes must wait in a queue for processor time. All other activity comes to a halt until the queue is cleared. Processor bottlenecks can occur on multiprocessor computers when only a single processor is exhausted, if the work in the queue cannot be or is not distributed to the other processors. By definition, adding or improving other components of the computer, such as memory, disks, or network connections, does not overcome the performance problem.

This chapter discusses strategies for long-term monitoring of processor activity and processor queues. The chapter describes how Internet Information Server uses server processors, and how you can monitor and measure processor activity. The chapter concludes with suggestions for preventing processor bottlenecks.

The sections in this chapter are as follows:

"Monitoring Server Processors"

"Monitoring Connections"

"Monitoring Threads"

"Monitoring Interrupts and DPCs"

"Suggestions for Improving Processor Performance on an IIS Server"

This chapter focuses on issues specific to Windows NT 4.0 Servers running IIS services. For more general information on monitoring and tuning processors, see Microsoft Windows NT Workstation Resource Kit, Chapter 13, "Detecting Processor Bottlenecks" and Chapter 16, "Monitoring Multiple Processor Computers." For a detailed discussion of the challenges involved in monitoring volatile processes and threads, see the section "Monitoring Processes and Threads," in Chapter 10, "About Performance Monitor," in the Windows NT Workstation Resource Kit.

Warning

To add or modify a Registry value entry, use administrative tools such as Control Panel or System Policy Editor whenever possible. Using a Registry editor (Regedit or Regedt32) to change a value can have unforeseen effects, including changes that can prevent you from starting your system.


Monitoring Server Processors

The processors in a server running Internet Information Server must support the operating system and processes unrelated to Internet services, as well as IIS processes. The processors must also support applications related to Internet services, such as those that assemble data from SQL Server databases or generate dynamic Web pages.

You have a choice of several tools you can use to monitor processor performance. Task Manager, Microsoft Web Capacity Analysis Tool (WCAT), PerfLog, and Performance Monitor are commonly used to monitor processors on Windows NT servers. Also, Pentium counters, extensible counters that monitor the inner workings of Intel Pentium (P5) and Pentium Pro (P6) processors, are available on the Windows NT Workstation Resource Kit and Windows NT Server Resource Kit CDs. Remember that all tools use system resources. Monitor the processor use of the process in which the tool runs. Then, before you analyze your data, subtract the processor time of the tool process from the data.


Using Performance Monitor to Monitor Processor Activity

You can use PerfLog to log data from the following counters automatically on a regular or periodic basis, or use Performance Monitor to log the System and Processor objects.

Table 6.1 Performance Monitor Counters for Processor Activity

Counter | Indicates
System: Processor Queue Length | Threads waiting for processor time. If this value exceeds 2 for a sustained period of time, the processor may be a bottleneck.
System: % Total Processor Time | The sum of processor use on each processor divided by the number of processors.
Processor: % Processor Time | Processor use on each processor. This counter reveals unequal distribution of processor load.
Processor: % Privileged Time | Proportion of the processor's time spent in privileged mode. In Windows NT, only privileged mode code has direct access to hardware and to all memory in the system. The Windows NT Executive runs in privileged mode. Application threads can be switched to privileged mode to run operating system services.
Processor: % User Time | Proportion of the processor's time spent in user mode. User mode is the processor mode in which applications, like the IIS services, run.
Process: % Processor Time | The processor use attributable to each processor.

You can use the preceding Performance Monitor counters to monitor general processor performance. These counters are included in IISProc.pmw, a Performance Monitor workspace settings file on the Windows NT Server Resource Kit Supplement 1 CD.


Paging and Processor Bottlenecks

The most common cause of an apparent processor bottleneck is a memory bottleneck. If the system does not have enough physical memory to store the code and data programs need, the processor spends substantial time paging. Before adding or upgrading processors or disks, you should monitor the memory in your server. For more information about monitoring memory, see Chapter 5, "Monitoring Virtual Memory."


Analyzing Processor Activity Data

Of the counters listed, the System: Processor Queue Length counter is the most important counter for analyzing processor activity data. The System: Processor Queue Length counter displays the number of ready threads in the single queue shared by all processors. Sustained high rates of processor activity, which leave little excess capacity to handle peak loads, are often associated with processor bottlenecks. Processor activity, by itself, indicates only that the resource is used, not that maximum use of the resourcerrich is a problem. However, a long, sustained queue indicates that ready threads are being kept waiting because a processor cannot handle the load.

A sustained processor queue length of 2 or more threads (as indicated by the System: Processor Queue Length Counter) typically indicates a processor bottleneck. You might consider setting a Performance Monitor alert to notify the Administrators when the processor queue length reaches an unacceptable value.

The Processor: % Processor Time counter is most often used as a general measure of processor activity on both single-processor and multiprocessor computers. System: % Total Processor Time is included for monitoring system-wide processor use on multiprocessor computers. On single-processor computers, System: % Total Processor Time always equals Processor: % Processor Time. On multiprocessor computers, System: % Total Processor Time represents the active time of all processors divided by the number of processors.

If the server workload is shared equally among all processors, System: % Total Processor time is an excellent measure of processor activity. However, this counter hides bottlenecks resulting from unequal processor loads. (If one processor is 100% busy and three other processors are idle, the % Total Processor Time is 25%.)

Windows NT is designed for efficient scaling and includes several strategies for balancing processor load. Applications can create an imbalance by setting a processor affinity, which binds a process to a single processor. For detailed processor monitoring, you need to chart Processor: % Processor Time for each processor on the computer.

You might encounter the following challenges in analyzing your processor data:

A large processor queue when all processors are busy. Create a histogram of Process: % Processor Time for each process. The histogram shows the processor time consumed by each process.

A single bar rises above all of the others. The process represented by the bar might be consuming a disproportionate share of processor time and causing a bottleneck. Consider replacing the application running in the process, or moving the process to another server.

The processors are being shared equally by several processes. Consider upgrading or adding processors. Multithreaded processes benefit most from additional processors.

For more information on processor use by applications related to Internet Information Server, see Chapter 9, "Monitoring Dynamic Page Generation."


Monitoring Connections

Internet Information Server is designed to support millions of connections. In fact, the internal default for the maximum number of simultaneous connections is 2 million connections. (This default is overriden by the Internet Service Manager, but administrators can change it.) Nonetheless, large numbers of simultaneous connections can overload the processors.

It is important to monitor connections on your Internet Information Server. In particular, it is important to determine how your server responds when it is managing different numbers of connections. When you have collected data on connection trends, you can associate data about general server performance with the number of connections being served.

This section discusses why connections have performance overhead, how you can use Performance Monitor and other tools to measure the overhead, and how to interpret the data you gather.


The Performance Overhead of Connections

Each connection that an IIS service establishes consumes some processor time. The network adapter card interrupts the processor to signal that a client has requested a connection. Further processing is required to establish and maintain the connection, to fulfill client requests sent on the connection and, when the connection is closed, processing is required to delete the structures that serviced the connection. Each time a connection is established, the load on the server increases.

One aspect of connection overhead is the time it takes to search the Transmission Control Block (TCB) table. TCP creates and maintains transmission control blocks (TCBs) to store data about connections. This might include data about the precedence of the connection and its local and remote socket numbers. The TCBs are stored in a hash table for efficient control. The hash table is stored in the operating system's nonpaged memory pool.

Internet Information Server 2.0 includes several features to optimize its handling of connections. Among these features are HTTP keep-alives.

HTTP keep-alives maintain a connection even after the connection's initial request is complete. This feature keeps the connection active and available for subsequent requests. Keep-alives are implemented to avoid the substantial cost of establishing and terminating connections. Both the client and the server must support keep-alives. Keep-alives are supported by Internet Information Server version 1.0 and later and Internet Explorer version 2.0 and later.

HTTP keep-alives are different from and independent of Transmission Control Protocol/Internet Protocol (TCP/IP) keep-alives. TCP/IP keep-alives are messages sent to determine whether an idle connection is still active.

HTTP keep-alives are enabled in Internet Information Server by default. Although keep-alives significantly improve bandwidth performance on most servers, you can modify or eliminate them if they are not needed. You can also measure their effect on the performance of your system. To test their effect on the server, you can disable them, but it is recommended that you reenable them when the test is concluded to maintain the performance of the server.

You can disable keep-alives by adding the AllowKeepAlives value entry to the Registry and setting its value to 0. To reenable keep-alives, delete the AllowKeepAlives value entry, or set it to 1. You must place AllowKeepAlives in:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\W3SVC
\Parameters


Using IIS Logging to Monitor Connections

You can use the Internet Information Server Logging to monitor the number of connections your server handles and to track patterns of client demand for your server. For more information about configuring and interpreting Internet Information Server logs, see the online Windows NT Server Microsoft Internet Information Server Installation and Administration Guide.


Using Performance Monitor to Monitor Connections

Performance Monitor can monitor the number of simultaneous connections to the IIS services and the processor use of the process in which the IIS services run. The following table lists the Performance Monitor counters that monitor connections to Internet Information Server. rrich

Table 6.2 Performance Monitor Counters for IIS Service Connections

Counter | Indicates
HTTP Service: Current Connections FTP Server: Current Connections Gopher Service: Current Connections | The number of connections maintained by the service during the most recent sample interval.
HTTP Service: Maximum Connections FTP Server: Maximum Connections Gopher Service: Maximum Connections | The largest number of connections maintained simultaneously since the server was started.

These Performance Monitor counters are included in IISProc.pmw. Because these counters display the last value they observe, and not an average, you must log these values over time to collect reliable data.

Also, these counters are likely to exaggerate the number of simultaneous connections because some some entries might not yet be deleted even though the connection is closed.

Note

The HTTP Service, FTP Serverrrich, and Gopher Service counters collect data at the OSI Application Layer. Counts of TCP/IP connections might not equal HTTP, FTP, and Gopher connections if the connection was blocked, rejected, or reset between the Transport and Application Layers. For details on monitoring connections at lower layers, see Chapter 7, "Monitoring Bandwidth and Network Capacity."


Analyzing Connection Data

By monitoring numbers of connections you can identify patterns of client demand for your server. Classify the data in your Performance Monitor logs into intervals by the numbers of connections served during the interval. Observe the length of the processor queue and the processor use on each processor during periods of small, moderate, and large numbers of connections. This data shows how your configuration responds to each load level.

You can identify a processor bottleneck at each interval by:

A long, sustained processor queue (more than two threads).

High use rates on one or more processors.

A curve in the graph of the Current Connections counter on any IIS service performance object that reaches a high value and then forms a plateau. This pattern often indicates that additional connections are being blocked or rejected.

To prevent processor bottlenecks, make certain that a lengthy processor queue isn't forming when you serve large numbers of connections. Typically, you can avoid a bottleneck during peak time by setting the connection limit to twice the average value of Current Connections. If the processor regularly becomes a bottleneck when servicing large numbers of connections, you might consider upgrading or adding processors, or limiting the maximum number of connections on the server. Limiting connections might cause the server to block or reject connections, but it helps to ensure that accepted connections are processed promptly.

The maximum number of connections is set separately for each service. Adminstrators can use the Internet Service Manager to limit the number of connections. On the property page for each service, click the Service tab, then change the value in the Maximum Connections field. The following table shows the default values for maximum connections by service.

Table 6.3 Default Values for Maximum Connections

Service | Default Maximum Connections
FTP | 1,000
Gopher | 1,000
WWW (HTTP) | 100,000


Monitoring Threads

Internet Information Server runs in a multithreaded process designed for efficient scaling on single-processor and multiprocessor systems. Threads are the objects in each process that run the process code on the processor. On single processor systems, the threads of the Internet Information Server process are switched on and off of the processor in order of priority. On multiprocessor systems, Internet Information Server can run more than one thread simultaneously.

In the Internet Information Server process, there is no simple association between threads and connections or threads and requests. Nor is there an easily quantified relationship between the optimum number of threads in the process and the number of files served, the number of requests filled, or the number of connections maintained.

The relationship between threads, connections, and requests is more complex with Internet Information Server because IIS uses the worker thread model, rather than the simpler, but less efficient, thread per client model. Instead of dedicating a thread to each connection or request, Internet Information Server dedicates one thread, the worker thread, to the task of accepting and monitoring all connections. This frees other threads to do the remaining work of the application, such as authenticating users; parsing client requests; locating, opening, and transmitting files; and managing internal data structures. As a result, several threads can service a single connection and each request from a connection might be serviced by different threads.

Even though you cannot associate individual threads and connections or requests, you can:

Count the number of threads in the Internet Information Server process.

Measure the amount of processor time each thread gets.

Associate the number of threads (and processor activity) with the number of current connections, number of files served, and other measures of server activity and performance.

Several tools monitor the threads in a process, including Process Viewer, Process Explode, PerfLog, and Performance Monitor. Individual threads are difficult to monitor, especially if they frequently start and stop. Threads are also costly to measure. Be sure to monitor the overhead (by using Process: % Processor Time) of the process in which your tool runs and subtract it from the data you collect. For a detailed discussion of this issue, see the Windows NT Workstation Resource Guide, Chapter 10, "About Performance Monitor," "Monitoring Processes and Threads."


Using Performance Monitor to Monitor IIS Threads

You can use Performance Monitor to monitor the threads in the Internet Information Server process. The following table lists the Performance Monitor counters that monitor threads. These counters are included in IISProc.pmw. You can add to this list any counters you will use to associate numbers of threads with performance, such as HTTP Service: Current Connections, HTTP Service: Bytes/sec, or Server: Logon/sec.

Table 6.4 Performance Monitor Counters for Monitoring IIS Threads

Counter | Indicates
Process: Thread Count: Inetinfo | The number of threads created by the process. This counter does not indicate which threads are busy and which are idle. This counter displays the last observed value, not an average.
Thread: % Processor Time: Inetinfo => Thread # | How much processor time each thread of the Inetinfo process is using. If a log of this counter over time shows that threads are consistently idle, it may be prudent to reduce the number of threads per processor.
Thread: Context Switches/sec: Inetinfo => Thread # | How many times the threads of the IIS service are switched on to and off of a processor. This counter is an indicator of the activity of the threads of the IIS service process.


Analyzing the IIS Thread Data

You can chart the Process: Thread Count: Inetinfo value over time to see how many threads the Inetinfo process creates and how the numbers of threads vary. Then, observe the processor time for each thread in the process (Thread: % Processor Time: Inetinfo => Thread #) during periods of high, medium, and low server activity (as indicated by the other performance measures).

You should also observe the patterns of context switches over time. Context switches indicate that the microkernel has switched the processor from one thread to another. A context switch occurs each time a new thread runs, and each time one thread takes over from another. A large number of threads is likely to increase the number of context switches. Context switches allow multiple threads to share the processor, but they also interrupt the processor and might interfere with processor performance, especially on multiprocessor computers.


Optimizing Thread Values

By default, the Internet Information Server process creates up to 10 threads per processor. Internet Information Server continually adjusts the number of threads in its process in response to server activity. For most systems, this tuning is sufficient to maintain the optimum number of threads, but you can change the maximum number of threads per processor, if your system requires it.

If the threads in the Internet Information Server process appear to be overworked or underutilized, consider these tuning strategies:

If nearly all of the threads of the Internet Information Server process are busy nearly all of the time, and the processors are at or near their maximum capacity, consider distributing the workload among more servers.

You can also add processors, but do so cautiously. Unnecessary or underused processors will degrade performance, not improve it.

If nearly all threads appear busy, but the processors are not always active, consider increasing the maximum number of threads per processor. Increasing the number of threads is typically an interim solution used while a bottleneck in another subsystem is being resolved.

Do not increase the maximum number of threads unless you have processors with excess capacity. More threads on the same number of processors cause more interrupts and context switches, and result in less processor time per thread.

If many threads are continuously idle, you might save processor time and memory by reducing the number of threads in the process.

To adjust the maximum number of threads in the IIS service process, use a Registry editor to add the MaxPoolThreads value entry to the Registry. MaxPoolThreads does not appear in the Registry unless it is added. It must be added to the following:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Inetinfo
\Parameters

MaxPoolThreads is calculated in units of threads-per-processor. If this value entry does not appear in the Registry, Internet Information Server allocates a maximum of 10 threads per processor. Do not set this value below 5 or above 20. For more information on MaxPoolThreads, see Regentry.hlp on the Windows NT Workstation Resource Guide 4.0 CD.

Continue monitoring the system carefully to make sure that changing the numbers of threads achieves the desired effect.


Monitoring Interrupts and DPCs

One of the processor's tasks is to service interrupts and DPCs from all of the computer's subsystems. On a busy server running Internet Information Server, much of the processor's time can be spent servicing interrupts and DPCs, especially from the disk subsystem and the network adapter cards.

This section describes some methods of measuring how much time your server's processors are spending handling interrupts and DPCs from the network adapter cards. It discusses how network card interrupts and DPCs are distributed among processors in multiprocessor computers, and suggests some methods of tuning DPC distribution to improve processor performance.


Describing Interrupts and DPCs

Interrupts are very high-priority signals that halt the processor's activity and prepare the processor for a new activity, if only very briefly. Interrupts consume processor time and disrupt the processor's work, but they are essential to a preemptive multitasking system.

Client connections involve many interrupts. The network adapter card generates an interrupt when it receives a new packet or completes a transmission. The system collects some very basic information and then adds one or more deferred procedure calls (DPCs) to the queue to handle the next steps in the process.

DPCs are similar to interrupts except that they have a lower Interrupt Request Level (IRQL). (IRQL is the priority scale used for objects like interrupts. It is different from the priority scale that the microkernel uses to schedule processes and threads.) Unlike interrupts, DPCs can be delayed, allowing the processor to complete higher priority work. When the DPC gets processor time, the work of establishing the connection can proceed.


Interrupts and Processor Performance

Commonly used server processors, such as Intel 486, Intel Pentium and Pentium Pro, and RISC processors, can handle thousands of interrupts and DPCs without being consumed by the task. However, each interrupt takes time away from the other work of the processor. An active server running Internet Information Server at high bandwidth can interrupt the processor enough to impede performance.

To help improve processor performance, some newer network card drivers provide an advanced feature known as interrupt moderation. When the driver detects a high rate of interrupts from the network adapter card, the interrupt moderation code disables interrupts and accumulates the interrupts in a buffer instead of sending them to the processor. When the processor has completed its work, the interrupts are reenabled.

Monitoring interrupts and DPCs is an important part of monitoring processor performance (and network adapter card performance) on a server running Internet Information Server. On a single processor system, a very high level of interrupts might indicate an errant network card or disk adapter, as well as an overworked processor. On a multiprocessor system, data about interrupts and DPCs might also reveal a poor distribution of workload among processors.


Using Performance Monitor to Monitor Interrupts and DPCs

You can use Performance Monitor to monitor the interrupts and DPCs in the Internet Information Server process. The following table lists the Performance Monitor counters that monitor interrupts and DPCs. These counters are included in IISProc.pmw.

When monitoring, chart these counters along with standard measures of processor time, such as System: Processor Queue Length and Process: % Processor Time: Inetinfo. If you are monitoring a multiprocessor computer, be sure to include Processor: % Processor Time. This counter displays the processor use of each processor over time. You might also include Processor: % Privileged Time because interrupts and DPCs are processed in privileged mode.

Table 6.5 Performance Monitor Counters for Interrupt and DPC Monitoring

Counter

Indicates

Processor: % Interrupt Time

How much time the processor is spending processing interrupts. Interrupts are generated when a client requests a connection or sends data.

If processor time is more than 90% and this value is greater than 15%, the processor is probably overburdened with interrupts.

Processor: Interrupts/sec

The rate at which the processor is handling interrupts.

Processor: % DPC Time

How much time the processor is spending processing deferred procedure calls (DPCs). DPCs originate when the processor performs tasks requiring immediate attention, and then defers the remainder of the task to be handled at lower priority. DPCs represent further processing of client requests.

Processor: DPCs queued/sec

The rate at which DPCs are added to the processor's queue. (This counter does not measure the number of DPCs in the queue.)

Pentium: Interrupts/sec (Pentium, but not Pentium Pro, processors)

Only taken INTR and NMI hardware interrupts.rrich

Pentium: Hardware interrupts received/sec
(Pentium Pro processors only)

The rate at which hardware interrupts are detected by the processor's internal counters.

Note

The Pentium performance object includes counters that display data on interrupts and DPCs. Pentium counters are extensible Performance Monitor counters designed to monitor Pentium processors. The counters are included on the Windows NT Workstation Resource Kit CD in the Performance Tools group. You must install the Pentium counters before you can use them. For detailed instructions, see P5Perf.txt on the Windows NT Workstation Resource Kit CD.


Analyzing Data on Interrupts and DPCs

When you have collected data on interrupts and DPCs that is representative of the general activity on your server, you can use the guidelines in this section to help you interpret the data.


Analyzing Interrupt and DPC Rates

You can observe the rates of interrupts and DPCs during periods of high, medium, and low server activity. Note the rate of interrupts and DPCs when processor use is very high, especially when a processor queue is developing.

A very high rate of interrupts can indicate a problem with a component that generates interrupts, such as the disk subsystem or a network adapter card. Test your components and rule out a hardware problem before proceeding.


Analyzing Processor Time

You should observe the proportion of the processor's time that is spent servicing interrupts and DPCs. Compare the values of the Processor: % Interrupt Time and Processor: % DPC Time counters to Processor: % Processor Time.

If a busy processor is spending the majority of its time servicing interrupts and DPCs, the processor probably cannot function effectively and a processor bottleneck is likely to develop. Consider upgrading or adding processors to handle the workload.

Alternatively, if the processor has some excess capacity (if Processor: % Processor Time < 85%), or if it is spending a relatively small amount of its time (if Processor: % Interrupt Time and Processor: % DPC Time < 20%) servicing interrupts and DPCs, you probably do not have a problem with interrupts and DPCs.


Analyzing the Distribution of Interrupts and DPCs on Multiprocessor Computers

The most common interrupt-related problem on multiprocessor computers is not the rate of interrupts and DPCs, but their distribution among processors. To determine whether you have a distribution problem:

Observe the proportion of time each processor is spending servicing interrupts and DPCs.

Observe the rate of interrupts and DPCs for each processor.

Note whether interrupts and DPCs are distributed equally among all processors or whether one or more processors are servicing all of the interrupts or DPCs.

A busy processor that is servicing all of the system's interrupts or DPCs is likely to become a bottleneck. The source of the problem is not the number of interrupts or DPCs but the way that interrupts and DPCs are distributed among the processors.

The following sections describe common strategies for distributing interrupts and DPCs on Windows NT servers.

Interrupt Distribution

Different processor platforms use different methods to distribute interrupts. The distribution of interrupts from network adapter cards is controlled by the Hardware Abstraction Layer (HAL) for each processor platform. The interrupt scheme implemented by the HAL depends on the capability of the processor. Some processors include interrupt control hardware, such as the Advanced Programmable Interrupt Controller (APIC) on newer Pentium and Pentium Pro processors. The APIC allows processors to route interrupts to other processors on the computer.

You cannot control or modify the distribution of network card interrupts on your computer. The information in this section is included to help you interpret the interrupt data you collect and, in particular, to explain one of the reasons why one processor might be busier than the others. Monitoring the processor that services the majority of interrupts can help you anticipate or prevent a bottleneck.

There are many different strategies for distributing interrupts on multiprocessor computers. Common strategies are:

No distribution. The traditional method for managing interrupts is to send all interrupts from all network cards to a single processor, usually the first (lowest-numbered) processor. If your data shows that all interrupts are being serviced by a single processor, your system might use this method.

Static distribution. Some systems distribute network card interrupts among processors statically, that is, the distribution doesn't change. These systems associate each network adapter card with a processor. The interrupts generated by the network card are always sent to the network card's associated processor, regardless of whether the processor is busy or idle.

Typically, these systems associate the first (lowest-numbered) network card with the first (lowest-numbered) processor and each subsequent network card with each subsequent processor. If there are more network cards than processors, the system begins its assignments again with the first processor.

If your data shows that interrupts are distributed rather evenly among processors, you might have a system that provides static distribution. However, if one of the network cards is idle or not used, static distribution results in unequal distribution of interrupts.

Dynamic distribution. Some systems distribute interrupts to processors dynamically based on one or more elements of system data, such as processor activity. The interrupts generated by a network card can be sent to any one of the processors.

If your data shows that interrupts are almost always distributed evenly, you might have a system that provides dynamic distribution.

Distribution of interrupts to all processors, whether statically or dynamically, is commonly known as symmetric interrupt distribution. Symmetric interrupt distribution is designed to improve scaling and to prevent a single processor from becoming a bottleneck while other processors have excess capacity. It is available on the Microsoft Windows NT 4.0 HAL for Pentium and Pentium Pro processors. For specific information on the distribution method used for your processor platform, consult your system vendor.

Strategies for producing the most efficient interrupt distribution systems are evolving. You cannot change the interrupt distribution scheme on your computer, but you can coordinate the distribution of DPCs with the distribution of interrupts.

DPC Distribution

The distribution of DPCs generated by network cards is a function of Ndis.sys, the Windows NT implementation of the Network Driver Interface Specification (NDIS). Ndis.sys is a wrapper that shields the details of the network adapter card from the rest of the operating system. Ndis.sys controls DPC distribution on all network cards that use miniport drivers, which is nearly all of them.

Ndis.sys attempts to balance the processor workload generated by interrupts. By default, Ndis.sys associates each network card with a processor and directs all DPCs from a network card to the processor associated with that network card. Ndis.sys attempts to compensate for the burden placed on the lowest-numbered processor by associating the first network card with the highest-numbered processor. Each subsequent network card is associated with the next processor in descending order of processor number.rrich

On many systems, this strategy balances the load. If a server that does not distribute interrupts has two processors and one network card, Processor 0 services the interrupts and Processor 1 services the DPCs.

Unfortunately, this distribution strategy doesn't always work as planned:

DPCs evolve from interrupts. When a DPC is generated from an interrupt, the DPC must be switched to another processor. The switch requires an interprocessor interrupt from the sending processor to the receiving processor. These very high priority interprocessor interrupts consume additional processor time.

Information gathered when the interrupt is processed is stored in the processor cache. When the DPC generated from the interrupt is switched to another processor, the data in the cache of the sending processor is flushed and must be collected anew by the receiving processor.

On many platforms, interrupts are distributed among all processors. Leaving the DPC on the processor that handled the interrupt reduces the number of interprocessor interrupts and allows the DPC to use data stored in the processor cache when the interrupt was serviced.

Fortunately, if DPC distribution is a problem in your system, you can improve system performance by optimizing DPC distribution.

Optimizing DPC Distribution

The solutions to poor DPC distribution differ depending on whether the system distributes interrupts symmetrically:

No distribution. If you are administering a multiprocessor server that does not distribute interrupts symmetrically, monitor the highest-numbered processor carefully. If the processor frequently operates at capacity (if Processor: % Processor Time = 100%) and more than half of its time is spent servicing DPCs (if Processor: % DPC Time > 50%), you can improve the performance of your system by one or more of the following methods:

Upgrading to a system that distributes interrupts.

Adding network adapter cards so that you have one network adapter card for each processor. Ndis.sys then distributes DPCs to all processors. Generally, you should only add a network adapter card if you also need the bandwidth because each additional network card has some intrinsic overhead.

Adjusting the NDIS Processor Affinity Mask to allow or prevent certain processors from servicing DPCs. This is not recommended unless you are very familiar with this process. A less-than-optimal mask can degrade processor performance. You can change the Processor Affinity Mask by editing the ProcessorAffinityMask value entry in the Registry.

Symmetric distribution. If you are administering a multiprocessor server that distributes interrupts to all processors, whether statically or dynamically, you can improve performance by setting the value of the ProcessorAffinityMask value entry in the Registry to zero. If the value of ProcessorAffinityMask is zero, network cards are not associated with processors, and DPCs remain on the processor that handled the interrupt. ProcessorAffinityMask is located in:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\NDIS
\Parameters

ProcessorAffinityMask is described in the Regentry.hlp file on the Supplement 1 CD. (It is not included in previous versions of Regentry.hlp.)


Suggestions for Improving Processor Performance on an IIS Server

The IIS services run in a multithreaded process designed to operate efficiently on single-processor and multiprocessor computers. An Intel 486, Intel Pentium or Pentium Pro, or RISC processor should be sufficient to handle more than a thousand simultaneous connections. Servers with more activity benefit from multiple processors.

If your data on processor performance indicates that processor queues are developing regularly or while servicing large numbers of connections, monitor the memory of your server. Rule out a memory bottleneck or add more memory before (or in addition to) adding or upgrading processors.

In addition, consider the following suggestions for improving processor performance:

Redistribute the workload. If nearly all of the threads of the Internet Information Server process are busy nearly all of the time, and the processors are at or near their maximum capacity, consider distributing the workload among more servers, or redistributing tasks among servers. You can also add processors, but do so cautiously. Unnecessary or underused processors will degrade performance, not improve it.

Add processors. If the workload is distributed evenly, and all threads in the Internet Information Server process continue to be busy nearly all of the time, or if a processor queue forms when the number of connections rises, add and/or upgrade processors. You can avoid a processor bottleneck during peak use by calculating the processor use on your system when the number of current connections is at its average, and allowing enough processing power to handle twice the average number of connections.

Upgrade the L2 cache. When adding or upgrading processors, choose processors with a large secondary (L2) cache. File server applications, such as Internet Information Server, benefit from a large processor cache because their instruction paths involve many different components. A large processor cache (2MB) is recommended to improve performance on active servers running Internet Information Server.

Improve DPC handling. Platforms that distribute interrupts to all processors do not benefit from the Windows NT default DPC affinity. If you are administering a multiprocessor computer that distributes interrupts symmetrically, such as an Intel Pentium or Pentium Pro (P6) system for Windows NT 4.0, set the value of the ProcessorAffinityMask value entry in the Registry to zero. DPCs will be handled by the same processor that handled the interrupt from which the DPC evolved.

Add network adapter cards. If you are administering a multiprocessor system that does not distribute interrupts symmetrically, you can improve the distribution of the processor workload by adding network cards so that there is one network card for every processor. Generally, you only add network cards when you need to improve the throughput of your system. Network cards, like any additional hardware, have some intrinsic overhead. However, if one of the processors is nearly always active (if Processor: % Processor Time = 100%) and more than half of its time is spent servicing DPCs (if Processor: % DPC Time > 50%), then adding a network card is likely to improve system performance.

Upgrade Network Adapter Cards. If you are adding or upgrading network adapter cards, choose cards with drivers that support interrupt moderation. Interrupt moderation prevents the processor from being overwhelmed by bursts of interrupts. Consult the driver manufacturer for details.

Limit Connections. If you cannot upgrade or add processors, consider reducing the maximum number of connections that each IIS service accepts. Limiting connections might result in connections being blocked or rejected, but it helps ensure that accepted connections are processed promptly.

To change the number of connections, use the Internet Service Manager Properties page for each service. Reduce the number in the Maximum Connections field until the server can handle twice the average number of connections without developing a long processor queue.

Redesign the Web site. You can improve performance and reduce the processor workload by substituting static web pages for dynamic pages and eliminating large bitmapped images.

Adjust the Maximum Number of Threads. Internet Information Server tunes the number of threads in its process dynamically. The dynamic values are usually optimal. In extreme cases of very active or underused processors, you might want to adjust the maximum number of threads in the Inetinfo process. If you change the maximum number of threads, continue careful testing to make sure that the change has improved performance. The difference is usually quite subtle.

On a large network of Intranet and Internet servers, the processors in each server are vital components. However, they work with memory, disks, and the network as an integrated unit. For more detailed information on monitoring and tuning techniques, see Chapter 7, "Monitoring Bandwidth and Network Capacity."


Chapter 7 - Monitoring Bandwidth and Network Capacity

The primary functions of an Internet Information Server are to establish connections for its clients, to receive and interpret requests, and to deliver files, all as quickly as possible. The pace at which these vital functions are performed depends, in large part, on two factors: the effective bandwidth of the link between the server and the network and on the capacity of this link and the server to support network resources.

This chapter examines bandwidth and network capacity on an Internet Information Server and suggests methods you can use to measure and improve transmission rates and connection handling on your server. This chapter is not intended as a comprehensive guide to network monitoring. Instead, it is a limited presentation of the network-related issues that are important on servers running Internet Information Server (IIS).

This chapter includes the following sections:

"Defining Bandwidth and Network Capacity." This section defines the terms bandwidth and network capacity.

"Monitoring Transmission Rates." This section describes the Performance Monitor counters available for measuring transmission rates. Transmission rates are a primary measure of bandwidth on an Internet Information Server.

"Monitoring File Transfers." This section describes the Performance Monitor counters that display the number of files and directory listings sent and received by each IIS service. These counters can be used to determine the level of a particular service's network activity or the effect of file activity on server components.

"Monitoring TCP Connections." This section describes the Performance Monitor counters on the TCP object that monitor the rate at which Transmission Control Protocol (TCP) connections are established, failed, and reset. The ability to establish and maintain connections is a primary indicator of the effective network capacity of a server.

"Using Network Monitor to Monitor Bandwidth." Network Monitor enables you to examine the packets sent and received by the local computer. It is an optional tool included with Windows NT Server. This section suggests some Network Monitor fields to watch when measuring bandwidth.

"Limiting Bandwidth." On multipurpose servers, you might want to limit the proportion of the server's bandwidth used by IIS services. Doing so prevents Internet Information Server from consuming network capacity required by other services. This section explains how to limit the share of the network used by the Internet Information Server, and how to monitor the results.

"Suggestions for Maximizing Bandwidth." This section provides some suggestions for improving the performance of your server with its current equipment.


Defining Bandwidth and Network Capacity

Bandwidth and network capacity are measures of the effective performance of the communication links that connect the server computer to the network. Effective performance refers to performance judged by actual, observed values, as opposed to theoretical values that might be achieved in an ideal environment. A server's effective performance is determined by the individual capacity of each network segment and by the ability of the server to respond to requests.

Bandwidth refers to the rate at which data is transmitted and received over a communication link between a computer and the network. Bandwidth is measured in several different ways:

The rate at which bytes are transferred to and from the server.

The rate at which data packages are sent by the server. Data packages include frames, packets, segments, and datagrams.

The rate at which files are sent and received by the server.

Effective bandwidth varies widely depending upon the transmission capacity of the link, the server configuration, and the server workload. The values for a single server also change as it operates, in response to demand and to competition for shared network resources.

Network capacity is a broader term that refers to the ability of the server and the communication link to carry network traffic and support multiple resources. Network capacity is measured, in part, by the number of connections established and maintained by the server.

The following sections describe in more detail the methods you can use to measure bandwidth and network capacity on your server.


Monitoring Transmission Rates

The simplest measure of the effective bandwidth of a server is the rate at which the server sends and receives data. Performance Monitor displays counts of data transmissions that are collected by many components of the server computer. The components that collect data each reside in different Open Systems Interconnectivity (OSI) layers:

Counters on the HTTP Service, FTP Server, and Gopher Service performance objects measure data transmitted at the OSI Application Layer. (HTTP stands for hypertext transfer protocol; FTP stands for File Transfer Protocol.)

Counters on the TCP object measure data transmitted at the Transport Layer.

Counters on the IP object measure data at the Network Layer. (IP stands for Internet Protocol.)

Counters on the Network Interface object measure data at the Data Link Layer.

As a result of their different positions in the OSI stack, the counters display different data. For example, the counters at the Application Layer count the bytes sent before the data is divided into packets and prefixed with protocol headers and control packets. Counters at the Application Layer measure data in this way because the data is in this form when the application sends it. Counts at the Application Layer also do not include retransmitted data.

In addition, the counters display the data in units native to the component measured. For example, the HTTP Service object displays data in bytes, and the TCP object displays data in segments.

The next section lists and describes the Performance Monitor counters you can use to measure data sent and received by your server. The following section also offers help in interpreting the data you collect.


Using Performance Monitor to Monitor Transmission Rates

The following tables list and describe some of the Performance Monitor counters that can be used for measuring transmission rates. The counters in this table display the transmission rate observed during the last sample interval. They do not display a rolling or cumulative average of the rate. Also, the counters that represent sums of other counters, such as IP: Datagrams/sec, are simple sums of the other counters' values. They are not weighted sums.

For more information about how counter values are calculated, check the counter type of the counter. A counter type determines how Performance Monitor calculates and displays that particular counter. Counters.hlp, a Help file for the Performance Monitor counters, lists and describes the counter type of each counter. Counters.hlp is included on the Microsoft Windows NT Server Resource Kit Supplement 1 CD.

Note

You must install Simple Network Management Protocol (SNMP) to activate the counters on the TCP, IP, and Network Interface performance objects in Performance Monitor.

The following table lists and describes counters at the Application Layer.

Table 7.1 Performance Monitor Counters for Measuring Transmission Rates at the Application Layer

Counter | Indicates
HTTP Service: Bytes Sent/sec | The rate at which the HTTP server application is sending data, in bytes.
HTTP Service: Bytes Received/sec | The rate at which the HTTP server application is receiving data, in bytes.
HTTP Service: Bytes Total/sec | The rate at which the HTTP server application is sending and receiving data, in bytes. HTTP Service: Bytes Total/sec is the sum of HTTP Service: Bytes Sent/sec and HTTP Service: Bytes Received/sec.
FTP Server: Bytes Sent/sec | The rate at which the FTP server application is sending data, in bytes.
FTP Server: Bytes Received/sec | The rate at which the FTP server application is receiving data, in bytes.
FTP Server: Bytes Total/sec | The rate at which the FTP server application is sending and receiving data, in bytes. FTP Server: Bytes Total/sec is the sum of FTP Server: Bytes Sent/sec and FTP Server: Bytes Received/sec.
Gopher Service: Bytes Sent/sec | The rate at which the Gopher server application is sending data, in bytes.
Gopher Service: Bytes Received/sec | The rate at which the Gopher server application is receiving data, in bytes.
Gopher Service: Bytes Total/sec | The rate at which the Gopher server application is sending and receiving data, in bytes. Gopher Service: Bytes Total/sec is the sum of Gopher Service: Bytes Sent/sec and Gopher Service: Bytes Received/sec.

The following table lists and describes counters on the TCP object.

Table 7.2 Performance Monitor Counters for Measuring Transmission Rates at the Transport Layer

Counter | Indicates
TCP: Segments Sent/sec | The rate at which TCP segments are sent by using the TCP protocol.
TCP: Segments Received/sec | The rate at which TCP segments are received by using the TCP protocol.
TCP: Segments/sec | The sum of Segments Sent/sec and Segments Received/sec.
TCP: Segments Retransmitted/sec | The rate at which segments are transmitted that contain one or more bytes TCP recognizes as having been transmitted before.

Segments Retransmitted/sec is a proper subset of Segments Sent/sec and Segments/sec. To determine the proportion of transmissions caused by failed transmission attempts, divide Segments Retransmitted/sec by Segments Sent/sec.

The following table lists and describes counters on the IP object.

Table 7.3 Performance Monitor Counters for Measuring Transmission Rates at the Network Layer

Counter | Indicates
IP: Datagrams Sent/sec | The rate at which IP datagrams are sent by using the IP protocol. This counter does not include datagrams forwarded to another server.
IP: Datagrams Received/sec | The rate at which IP datagrams are received from IP by using IP protocol. This counter does not include datagrams forwarded to another server.
IP: Datagrams/sec | The sum of IP: Datagrams Sent/sec and IP: Datagrams Received/sec.
IP: Datagrams Forwarded/sec | The rate at which IP datagrams are forwarded to their final destination by the server.

The sum of IP: Datagrams/sec and IP: Datagrams Forwarded/sec represents the rate at which all IP datagrams are handled by the server.

The following table lists and describes counters on the Network Interface performance object.

Table 7.4 Performance Monitor Counters for Measuring Transmission Rates at the Data Link Layer

Counter | Indicates
Network Interface: Bytes Sent/sec: NIC# | The rate at which bytes are sent over each network adapter (that is, over each network interface card, or NIC). The counted bytes include framing characters.
Network Interface: Bytes Received/sec: NIC# | The rate at which bytes are received over each network adapter. The counted bytes include framing characters.
Network Interface: Bytes Total/sec: NIC# | The sum of Network Interface: Bytes Sent/Sec and Network Interface: Bytes Received/sec.

The Network Interface counters display data about the network adapters on the server computer. The first instance of the Network Interface object (Instance 1) that you see in Performance Monitor represents the loopback. The loopback is a local path through the protocol driver and the network adapter. All other instances represent installed network adapters.

These counters are included in IISNet.pmw, a Performance Monitor workspace settings file on the Supplement 1 CD.


Analyzing Transmission Rate Data

The data provided by these counters is collected by different methods, is displayed in different units, and represents the view of different system objects. Some guidelines for interpreting the data follow:

The IIS service counters display the number of bytes transmitted on behalf of each service that server provides. To calculate the total number of bytes sent or received by all IIS services, sum the values for each service. You can determine the proportion of bytes transmitted by each service by computing the ratio of bytes for one service to the sum of bytes for all services, or for the network.

Data collected by the IIS service counters underestimates the total number of bytes actually being transmitted to the network by the IIS services. These values are collected at the Application Layer, so they measure data only. They do not measure protocol headers, control packets, or retransmitted bytes.

In general, the bytes counted by the services represent approximately 60 to 70 percent of the total number of bytes transmitted by the services on the network. If the sum of bytes for all services accounts for two-thirds or more of total network bandwidth, you can assume your network is running at or near the total capacity of its communications link.

Counters on the TCP and IP performance objects display the rate at which data is sent and received on a Transmission Control Protocol/Internet Protocol (TCP/IP) connection at the Transport and Network layers, but they do not count in bytes. Counters on the IP performance object display data in datagrams, and counters on the TCP performance object display data in segments. It is difficult to convert segments to bytes because the bytes per segment can vary from 8K to 64K; the number of bytes per segment depends upon the size of the TCP/IP receive window and the maximum segment size negotiated when each connection is established.

Counters on the Network Interface performance object display the rate at which bytes are transmitted over a TCP/IP connection by monitoring the counters on the network adapter at the Data Link Layer. The values of these Network Interface counters include all prepended frame header bytes and bytes retransmitted. These values provide a relatively accurate estimate of the numbers of bytes transmitted over the network, but they do not relate the bytes transmitted to a specific IIS service.

Despite the difficulty of comparing these counters to each other, they can all be related to other performance measures, such as the total number of connections served at a given bandwidth, or processor use at different throughput rates.


Monitoring File Transfers

Each World Wide Web page sent by Internet Information Server results in the transfer of at least one file. Most static Web pages include multiple files, such as a file of text and one or more files of graphics.

Performance Monitor includes counters for each IIS service. These counters display the number of files sent and received by the HTTP service and the FTP server, and the number of files and directory listings sent by the Gopher service. The file counters are listed and described in the following table.

Table 7.5 Performance Monitor Counters for IIS File Transfers

Counter | Indicates
HTTP Service: Files Sent FTP Server: Files Sent Gopher Service: Files Sent | The number of files sent by the service since the service was started.
HTTP Service: Files Received FTP Server: Files Received | The number of files received by the service since the service was started.
Counter | Indicates
HTTP Service: Files Total FTP Server: Files Total | The number of files sent and received by the service since the service was started. Files Total is the unweighted sum of Files Sent and Files Received.
Gopher Service: Directory Listings Sent | The number of directory listings sent by the Gopher service since the service was started.

The file counters for a particular service can be used as indicators of the network activity of that service. They can also be associated with other performance measures to determine the effect of high and low rates of file activity on server components.

Note, however, that the file counters for an IIS service display cumulative totals on all traffic since the service was started, regardless of when Performance Monitor was started. The counters do not display current values or the rate at which files are transmitted.

To calculate file transmission rates, you can use Performance Data Log Service (PerfLog) to log the file counters. PerfLog automatically logs the time at which measurement is taken. After you have generated a PerfLog log, you can use the PerfLog output files as input to a spreadsheet that associates the time of the measurement and the file count to derive the transmission rates. For more information on PerfLog, see Chapter 11, "Performance Monitoring Tools," in Microsoft Windows NT Workstation Resource Kit: Windows NT Workstation Resource Guide and the Help file Pdlcnfig.hlp on the Windows NT Server Resource Kit CD.


Monitoring TCP Connections

If the bandwidth of your server is insufficient to handle its workload, it is likely that clients will be aware of it before the server is. Client requests to the server will be rejected or will time out, or response will be delayed. On the server side, the indicators are less clear. The server will continue to establish connections, receive requests, and transmit data.

Bandwidth shortages are not uncommon. They have even been observed on dedicated Internet Information Servers with dedicated T1 lines. Traffic generated by an Internet Information Server alone can easily saturate a 1.5 – megabytes per second T1 line.

You can detect a bandwidth shortage on your server (perhaps even before clients do) by monitoring the success and failure of connections established and rejected by TCP. When the bandwidth is ample, the server can establish and serve connections before they time out. If bandwidth is not sufficient, the connections fail.

The following section describes the Performance Monitor counters recommended for monitoring the success and failure of connections on your server.


Using Performance Monitor to Monitor TCP Connections

Performance Monitor includes many counters that monitor connections. The counters on the TCP object are the best indicators of the success of connection requests.

The counters on the HTTP Service, FTP Server, and Gopher Service performance objects monitor connections maintained by each IIS service. The counters on these objects display only successful connection requests. They do not display failed attempts to connect to these IIS services. Like all counters at the Application Layer, they do not have information about connections until the connections are established. Performance Monitor counters that display the number of simultaneous connections maintained by Internet Information Server are discussed in Chapter 6, "Preventing Processor Bottlenecks."

The following table lists and describes the Performance Monitor counters that monitor the success and failure of connections to TCP.

Table 7.6 Performance Monitor Counters for Monitoring TCP Connection Successes and Failures

Counter

Indicates

TCP: Connections Established

The number of simultaneous connections supported by TCP (at last observation). This counter displays the number of connections last observed to be in the ESTABLISHED or CLOSE-WAIT state. It displays the last observed value only; its value is not an average.

TCP: Connection Failures

The number of connections that have failed since the service was started (regardless of when Performance Monitor was started). TCP counts a connection as having failed when it goes directly from sending (SYNC-SENT) or receiving (SYNC-RCVD) to CLOSED or from receiving (SYNC-RCVD) to listening (LISTEN).

TCP: Connections Reset

The number of connections reset since the service was started (regardless of when Performance Monitor was started).

TCP counts a connection as having been reset when it goes directly from ESTABLISHED or CLOSE-WAIT to CLOSED.

These counters are included in IISNet.pmw, a Performance Monitor workspace file on the Supplement 1 CD.


Analyzing TCP Connection Data

At the TCP level, you should monitor the TCP: Connections Established counter regularly. You might notice a pattern in which the counter value often reaches, but rarely exceeds, a maximum (that is, the graphed line rises and then plateaus at a peak). If so, the peak value is likely to indicate the maximum number of connections that can be established with the current bandwidth and application workload. If you observe such a pattern, the server probably cannot support any greater demand.

Failure to support current or increasing demand also might be evident from the number of connection failures and resets. The counters that monitor failures and resets show cumulative values, but you can set Performance Monitor alerts on the values or use PerfLog to log values over time. You can then use a spreadsheet to calculate the rates at which connections are rejected and reset. An increasing number of failures and resets or a consistently increasing rate of failures and resets might indicate a bandwidth shortage.

Be cautious when interpreting the number of reset connections shown by the TCP: Connections Reset counter. Resets do not always indicate dropped or failed connections. Many browsers try to minimize connection overhead by routinely closing connections by sending a TCP reset (RST) packet, rather than by closing the connection with a normal close operation. The TCP: Connections Reset counter does not distinguish between connections reset because they are dropped and those reset to close connections abruptly.


Using Network Monitor to Monitor Bandwidth

Network Monitor is a tool that lets you monitor the data sent and received by the local computer. It provides many capabilities, including enabling users to:

Capture or trace data and filter it based on different attributes.

Monitor throughput based on bytes or frames.

Monitor bandwidth based on the percentage of the network used.

Monitor errors, a possible consequence of an overloaded network.

The Windows NT Server CD includes Network Monitor as an optional Windows NT tool.

Û To install Network Monitor

1. Double-click the Network icon in Control Panel.

2. Click the Services tab, and then click Add.

3. In the Network Service box, double-click Network Monitor Tools and Agent.

Network Monitor comes with a Help file (Netmon.hlp) and a glossary (Nmgloss.hlp). It is also documented in detail in Chapter 10, "Monitoring Your Network," in Microsoft Windows NT Server Concepts and Planning.

For an overall view of bandwidth, use the Network Monitor Frames Per Second and Bytes Per Second status bars. Use the % Network Utilization status bar to view monitor network capacity used. The # Frames Dropped field indicates the number of frames that are not processed because the buffers on the network adapters are full. Frame-dropping occurs when the processor cannot handle the traffic generated by the network.


Limiting Bandwidth

If the bandwidth on your server is not sufficient to handle the load imposed by Internet Information Server, you can limit the amount of bandwidth Internet Information Server uses. Limiting bandwidth guarantees that some proportion of the server's bandwidth remains available to other server services. This Internet Information Server feature is intended for servers that handle electronic mail or are domain or file servers, in addition to running Internet Information Server.

The following sections explain how to limit the bandwidth used by IIS services, how to monitor the effect of the limitation, and how to interpret the monitoring data you collect.


Enabling the Bandwidth Throttler

Use the Bandwidth Throttler in Internet Server Manager to limit the bandwidth available to Internet Information Server. You can enable the Bandwidth Throttler from the property page for any of the three IIS services. The limit you set applies to the combined bandwidth used by all three IIS services, regardless of which property page you set it from.

Û To enable the Bandwidth Throttler

1. On the WWW Service Properties, FTP Service Properties, or Gopher Service Properties page, click the Advanced tab, then click Limit Network Use by all Internet Services on this computer.

2. In the Maximum Network use box, type the maximum amount of bandwidth you want the combined IIS services to use, in kilobytes per second.

You do not need to restart the server or the service to activate the Bandwidth Throttler. The Bandwidth Throttler is enabled dynamically. Because you do not need to restart the server, you can enable and disable the Bandwidth Throttler or change the value of Maximum Network use as needed. For example, you can restrict use of bandwidth by Internet Information Server during peak morning hours to make more bandwidth available for electronic mail.

Note

The value that you enter in the Maximum Network use box is stored in the BandwidthLevel value entry in the Registry. BandwidthLevel does not appear in the Registry until you enable the Bandwidth Throttler. If you later disable the Bandwidth Throttler, the value of BandwidthLevel is set to 0xFFFFFFFF.

You can enable the Bandwidth Throttler by adding the BandwidthLevel value entry to the Registry and setting BandwidthLevel to a value lower than 0xFFFFFFFF. However, if you edit the Registry, you must stop and restart the server to make the change effective.

For more information on BandwidthLevel, see Regentry.hlp, the Registry Help file, on the Supplement 1 CD.

Warning

To add or modify a Registry value entry, use administrative tools such as Control Panel or System Policy Editor whenever possible. Using a Registry editor (Regedit or Regedt32) to change a value can have unforeseen effects, including changes that can prevent you from starting your system.


Setting Maximum Network Use

The value you set for Maximum Network use depends upon the following factors:

The total capacity of the communication link between the server and the network. For example, a 10 Base T Ethernet cable has a maximum capacity of 10 megabytes per second.

The average and maximum transmission rates to and from the server. Use the information in the "Monitoring Transmission Rates" section of this chapter to determine the rates for your server.

The average and maximum numbers of connections maintained by the server. Use the information in the "Monitoring TCP Connections" section of this chapter to determine the rates for your server.

The requirements of the applications and services that share the communication link with Internet Information Server. You can use Performance Monitor, PerfLog, Task Manager, and Network Monitor to monitor the transmission rates and connections maintained by other services.

When calculating a value for the Maximum Network use box, remember that the Bandwidth Throttler is calibrated in numbers of kilobytes per second. If you wish to limit the bandwidth used by Internet Information Server to a fixed proportion of the link, you must convert the desired value from megabits per second to kilobytes per second.

Also, the Bandwidth Throttler is part of the Internet Information Server. As such, it counts bytes at the OSI Application Layer. It does not have information on the bytes generated at lower levels, such as those for protocol headers, control packets, or retransmissions. When selecting a value for the Maximum Network use box, remember that for every byte sent by Internet Information Server, at least 1.5 bytes (8 bits + 4 control bits) are transmitted across the network. If the network frequently retransmits data because of errors, the actual number of bytes transmitted for each byte sent by Internet Information Server is even more than 1.5 bytes. Be sure to factor this difference into your calculation of the desired bandwidth for IIS services.

For example, you might limit the bandwidth Internet Information Server uses to half of the capacity of a 1.544 – megabit per second T1 line. First, convert megabits per second to kilobytes per second:

(1.544 Megabits per second * 1024) / (8 bits per byte) = 197.6 KB/sec

Next, divide by two to determine a value equal to half of the transmission capacity of the line:

197.6 KB/sec / 2 = 98.8 KB/sec

Then account for the extra bytes generated by protocol headers and control packets:

98.8 KB/sec / 1.5 bytes transmitted for every IIS byte sent = 65.9 KB/sec.

However, limiting bandwidth can result in connections being blocked or rejected. You can use Performance Monitor to monitor the effect of limiting bandwidth.


Monitoring the Bandwidth Throttler

When you enable the Bandwidth Throttler, Internet Information Server activates a set of Performance Monitor counters to monitor the behavior of the Bandwidth Throttler. You can identify these counters by the presence of the phrase "Async I/O" in the counter name. These counters are active only when the Bandwidth Throttler is enabled. If the Bandwidth Throttler is not enabled, the counters appear in Performance Monitor, but they always have a value of zero.

The bandwidth set in the Bandwidth Throttler applies to the combined bandwidth used by all three IIS services. As such, the Async I/O counters are part of the Internet Information Services Global performance object. They represent totals for all of the IIS services. Bandwidth is not measured for each service.

The following table lists and describes the Async I/O counters.

Table 7.7 Performance Monitor Counters for Monitoring the Bandwidth Throttler

Counter | Indicates
Internet Information Services Global: Current Blocked Async I/O Requests | The number of requests blocked (that is, held in a buffer until the bandwidth clears) by the Bandwidth Throttler as reported during the most recent observation.
Internet Information Services Global: Total Allowed Async I/O Requests | The number of requests allowed by the Bandwidth Throttler since the service was last started.
Internet Information Services Global: Total Blocked Async I/O Requests | The number of requests blocked (that is, held in a buffer until the bandwidth clears) by the Bandwidth Throttler since the service was last started.
Internet Information Services Global: Total Rejected Async I/O Requests | The number of requests rejected by the Bandwidth Throttler since the service was last started.
Internet Information Services Global: Measured Async I/O Bandwidth Usage/Minute | The number of bytes sent per minute as indicated by a sample taken by the Bandwidth Throttler.


Analyzing Data About the Bandwidth Throttler

The Bandwidth Throttler determines whether to accept or reject a request based on the periodic samples of the rate at which bytes are sent on the server.

If the bandwidth used (as indicated by the sample) approaches the maximum set by the user, the Bandwidth Throttler blocks read requests but allows write requests and transmission requests. Read requests are blocked first because they are likely to result in further requests.

If the bandwidth used exceeds the maximum set by the user, the Bandwidth Throttler rejects read requests, blocks large write requests and transmission requests, and allows small write requests and transmission requests.

To determine how many requests are being blocked and rejected, monitor the Async I/O counters. These counters display cumulative totals, so it's best to use PerfLog to log the counter values. Alternatively, you can use a spreadsheet to calculate the rate over time. You can also set a Performance Monitor alert to notify administrators when the number of blocked or rejected requests exceeds a threshold.

No rule exists that sets a threshold or appropriate number of blocked and rejected requests. Tolerance for client delays and rejections is a business rule, not a performance measure. However, you can use the Async I/O counters to enforce your business's standards.


Suggestions for Maximizing Bandwidth

If the bandwidth on your server is not sufficient to support demand, you can solve the problem by increasing overall server bandwidth. For information on how this can be done, see Chapter 3, "Adding Bandwidth for Internet Connectivity."

You can also solve the problem by increasing the effective bandwidth of existing communication links. Some suggestions on how to do so follow. Many involve tuning parameters that can only be modified by editing the Registry. For more information about editing Registry entries, see Regentry.hlp, a Registry Help file on the Supplement 1 CD. This newest version of Regentry.hlp includes an updated list of the Registry entries for Internet Information Server.


Adjusting the Length of the Connection Queues

You might effectively increase existing bandwidth by increasing the length of the connection queues. Requests for connections to the IIS services are held in queues until the service is available to respond to the request. A separate queue exists for each of the IIS services, but all queues have the same maximum size. By default, each queue can hold up to 15 connection requests. If the queue to a service is full, any new connection requests are rejected.

The default queue length of 15 connection requests is sufficient for most servers. However, if your server is rejecting many requests when the services are most active, you can increase the maximum number of items in the queue. If you change the queue length, be sure to monitor server processor use, server memory use, and the connection counters to avoid creating a system bottleneck.

To change the maximum number of connection requests in the queue for each IIS service, add the ListenBackLog value entry to the Registry. Set the value of ListenBackLog to the maximum number of connection requests you want the server to maintain. You must place ListenBackLog in the Registry at:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Inetinfo
\Parameters

Although there are separate queues for each IIS service, the maximum length for all three of the queues is identical and is determined by this value entry.


Using HTTP Keep-Alives

To ensure optimal bandwidth, you can also verify that HTTP keep-alives are enabled. HTTP keep-alives are an optimizing feature that maintain a connection even after its initial request is complete. HTTP keep-alives are enabled by default but can be disabled by adding the AllowKeepAlives value entry to the Registry and setting its value to 0.

Keep-alives are enabled if AllowKeepAlives does not appear in the Registry or if it appears and is set to 1. The only reason to disable keep-alives is for testing or debugging, or if the vast majority of connections involve only one data request.

AllowKeepAlives is an optional entry that appears in the Registry only if it is added. If it has been added, it is located in:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Inetinfo
\Parameters


Working with Black Hole Routers

Another way to add effective bandwidth is by detecting and properly responding to black hole routers. Black hole routers are a common cause of frequent connection resets.

Black hole routers are routers that do not send an "ICMP Destination Unreachable" message when they cannot forward an IP datagram. Instead, they ignore the datagram. Doing so causes the connection to be reset. Typically, the reason an IP datagram cannot be forwarded is because the datagram's maximum segment size is too large for the receiving server and the Don't-Fragment bit is set.

To respond effectively to black hole routers, you can enable the Path MTUBH Detect feature of TCP/IP. Path MTUBH Detect recognizes repeated unacknowledged transmission and responds by turning off the Don't-Fragment bit. After the datagram in question is transmitted successfully, it reduces the maximum segment size and turns the Don't-Fragment bit on again.

Path MTUBH Detect is disabled by default, but you can enable it by adding the EnablePMTUBHDetect value entry to the Registry and setting its value to 1. EnablePMTUBHDetect is an optional entry that does not appear in the Registry unless you add it. You must place it in:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\Tcpip
\Parameters

You can disable Path MTUBH Detect by deleting EnablePMTUBHDetect from the Registry or by setting its value to 0.


Optimizing Graphics File Sizes

Graphics can consume significant bandwidth and result in noticeable network delay. You can increase effective bandwidth by changing your graphics format to reduce the size of graphics files. Different graphics formats use different methods of encoding the data. Try different formats for your graphics, and choose the format that produces the smallest file size.

For example, the Joint Photographic Experts Group (JPEG) format usually produces the smallest file for a photograph. Graphic Interchange Format (GIF) usually produces the smallest file for a computer-generated graphic.

In summary, maintaining adequate bandwidth is a primary concern on Internet Information Server. You can use Performance Monitor and Network Monitor to monitor different aspects of bandwidth. If your data analysis reveals that bandwidth is insufficient, you can increase the bandwidth available to the server or tune some of the parameters that affect bandwidth and network capacity. Also, if you are administering a multipurpose server, consider limiting the bandwidth available to the IIS services to maintain a minimum bandwidth for other services.


Chapter 8 - Effects of IIS Security Features on Performance

Performance is not usually a primary consideration when designing a security strategy for servers running Internet Information Server (IIS), and it should not be. The intrinsic benefits of protecting your installation and its code and data from unwarranted access override performance concerns. Nonetheless, effective security features have performance overhead — sometimes quite significant overhead — so it is important to measure the overhead and provide enough excess capacity to accommodate it.

This chapter describes some techniques for measuring the effects on server performance of security strategies commonly used on Windows NT Internet servers. These techniques include controlling access by IP Address, basic client authentication, Windows NT Challenge/Response client authentication, and Secure Sockets Layer (SSL) protocol. The following topics are covered in this chapter:

"The Challenge of Measuring Security Overhead."

"Using Microsoft Web Capacity Analysis Tool (WCAT) to Measure Security Overhead."

"Using Performance Monitor to Track Anonymous and Non-Anonymous Connections."

"Using Performance Monitor to Count Not-Found Errors."

"Capacity Planning to Support Security Features."


The Challenge of Measuring Security Overhead

Measuring the performance overhead of a security strategy is not simply a matter of monitoring a separate process or threads. The features of the Windows NT Security Model and other Internet Information Server security services run in the context of the IIS process and are integrated into several different operating system services. You cannot monitor security features separately from other aspects of the services.

Instead, the most common method of measuring security overhead is to run tests comparing the server performance with and without the security feature. The tests should be run with fixed workloads and a fixed server configuration so that the security feature is the only variable. During the tests, you probably want to measure:

Processor activity and the processor queue. Authentication, IP address checking, SSL protocol, and encryption schemes are security features that require significant processing. You are likely to see increased processor activity, both in privileged and user mode, and an increase in the rate of context switches and interrupts. If the processors in the server are not sufficient to handle the increased load, queues are likely to develop.

Physical memory used. Security requires that the system store and retrieve more user information. Also, the SSL protocol uses long keys — 40 bits to 1024 bits long — for encyrpting and decrypting the messages.

Network activity. The most obvious performance degradation resulting from complex security features like SSL is increased latency. Latency is a measure of the time required to complete a task. Downloading files on servers using the SSL protocol can be 10 to 100 times slower than on servers that are not using SSL.

You are also likely to see an increase in traffic between the IIS server and the domain controller used for authenticating logons and verifying IP addresses. If a server is used both for running Internet Information Server and used as a domain controller, the proportion of processor use, memory, and network and disk activity consumed by domain services is likely to increase significantly. The increased activity can be enough to prevent the IIS services from running efficiently.

You can run a test that monitors processor, memory, and network activity by using the Microsoft Web Capacity Analysis Toolkit (WCAT). You can run WCAT alone or in conjunction with other tools, such as Performance Monitor and Microsoft Internet Information Service Logging.


Using WCAT to Measure Security Overhead

WCAT is a script-driven, command-line – based application that tests your server configuration using a variety of predetermined, unvarying workloads. You can use WCAT to test how your server responds to different workloads or test the same workload on varying configurations of the server.

The WCAT toolkit includes a folder of prepared test workloads. You can also use WCAT to create your own workloads. WCAT also includes a special option, ssl.testname, that adds SSL protocol settings to any workload test.

WCAT is included on the Windows NT Server Resource Kit Supplement 1 CD. Detailed instructions for using WCAT are in the WCAT folder accessible from Rktools.hlp.


Components of a WCAT Test

A WCAT test simulates clients and servers communicating over a network. WCAT requires at least three computers for each test:

One computer simulating a client which runs one or more virtual clients

One computer simulating a server

One computer, called a connector, which initiates and monitors the test

To produce a realistic test, it is best to associate four or more client machines, each running several virtual clients, with each server.

The processors in the client computers should be at least as fast as the processors in the server computer. If the client processors are not as fast as the server processors, more client computers should be associated with each server computer. WCAT works best if the network that connects the computers has little or no traffic that is not related to the test. It is preferable to use a link dedicated only to the test. A 100MB network is recommended.


Designing a WCAT Test of Security Features

To test a security feature, first run a WCAT test with the feature, then run the same test without the feature. It is important to run the "with feature" and "without feature" versions of the test on varying workloads. WCAT includes prepared workloads ranging from 12 files to 1600 files (211MB). You can create additional tests of workloads with 2000 or more files.

WCAT has many options for collecting data on the tests:

You can use WCAT's log of performance data. The WCAT log can be used as input to spreadsheet and charting applications. The WCAT user guide explains how to interpret a WCAT log.

You can run Internet Information Server Logging in conjunction with WCAT to count logons and file accesses.

You can run Performance Monitor with WCAT. The WCAT run command includes a -p switch that activates Performance Monitor. You can select Performance Monitor counters by entering the names of counters in a script file. WCAT even includes a sample Performance Monitor counter file, Server.pfc.

WCAT enables you to view test results in several formats. You can view the test results in a spreadsheet or charting program, or in Performance Monitor. You can use the same method to analyze the data of a WCAT test as you use to analyze other Performance Monitor data on processors, memory, disks, network, and applications. You should repeat each test several times and average the results to eliminate unintended variations of the test conditions. Then, compare the results of the "with feature" and "without feature" tests.

Consistent differences in the results of the tests are likely to indicate the overhead associated with the security feature. You can use these results to plan configuration changes to handle the security overhead.

WCAT is the primary tool used for monitoring security overhead. Performance Monitor also includes a set of counters you can use to monitor one specific aspect of security: authenticating users.


Using Performance Monitor to Track Anonymous and Non-Anonymous Connections

Performance Monitor includes counters that display the number of anonymous and non-anonymous connections to each IIS service. These counters are included in the HTTP Service, FTP Server, and Gopher Service performance objects. The term non-anonymous is used instead of authenticated to account for custom authentication schemes that require data from the client other than, or in addition to, the user name and password.

By themselves, these Performance Monitor counters help you determine the number and proportion of each type of connection. You can also use the counter values to project the estimated effect of changing how you handle anonymous and non-anonymous users. For example, if the vast majority of connections are anonymous, prohibiting anonymous connections has a more significant impact than if most connections are non-anonymous.

Combining data from these counters with general measures of server performance, such as data on processor time, the processor queue, memory, disk reads and writes, and throughput, is even more useful. Using the combined data, you can associate varying numbers and proportions of anonymous and non-anonymous users with their effect on the performance of system components.


Anonymous and Non-Anonymous Connection Counters

The Performance Monitor counters that display the numbers of anonymous and non-anonymous connections are called Current Anonymous Users and Current Non-anonymous Users. These counters display connections, not users. Users who connect more than once are counted once for each time they connect.

The following table lists the Performance Monitor counters for anonymous and non-anonymous connections. These counters are part of the HTTP Service, FTP Server, and Gopher Service performance objects.

Table 8.1 Performance Monitor Counters for Anonymous and Non-Anonymous Connections

Counter | Indicates
HTTP Service: Current Anonymous Users Gopher Service: Current Anonymous Users FTP Server: Current Anonymous Users HTTP Service: Current NonAnonymous Users Gopher Service: Current NonAnonymous Users FTP Server: Current NonAnonymous Users | How many anonymous and non-anonymous users are currently connected to the IIS service.
HTTP Service: Maximum Anonymous Users Gopher Service: Maximum Anonymous Users FTP Server: Maximum Anonymous Users HTTP Service: Maximum NonAnonymous Users Gopher Service: Maximum NonAnonymous Users FTP Server: Maximum NonAnonymous Users | The maximum number of anonymous and non-anonymous users that have been connected simultaneously to the IIS service since the service was last started.

Table 8.1 Performance Monitor Counters for Anonymous and Non-Anonymous Connections (Continued)

Counter

Indicates

HTTP Service:
Total Anonymous Users

Gopher Service:
Total Anonymous Users

FTP Server:
Total Anonymous Users

HTTP Service:
Total NonAnonymous Users

Gopher Service:
Total NonAnonymous Users

FTP Server:
Total NonAnonymous Users

A running total of anonymous and non-anonymous connections to the IIS service since the service was last started.

The anonymous and non-anonymous user counters display the number of anonymous and non-anonymous connections to the IIS service when the values were last observed. They do not report averages or rates. These counters might exaggerate the number of connections because closed connections might not yet be deleted when the counter is displayed.

The Current Anonymous Users and Current Non-anonymous Users counters operate based on the following definitions:

The anonymous user counters display the number of connections whose requests either did not contain a user name and password or whose user name and password were ignored because authentication is not permitted on the server. If anonymous connections are not permitted on the server, the value of all anonymous user counters is always zero.

The non-anonymous user counters display the number of connections whose requests contained a valid user name and password, or whatever authentication is required by a custom authentication scheme. If authentication is not enabled on the server, and none of the applications that run on the server request or require authentication, then the value of all non-anonymous user counters is always zero.

The anonymous user and non-anonymous user counters count successful connections only. If a client request for an anonymous connection is rejected and the client responds with valid authenticating data, the connection is counted as non-anonymous.


Using Performance Monitor to Count Not-Found Errors

The HTTP Service performance object in Performance Monitor includes a counter that displays not-found errors. Not-found errors are client requests that could not be satisfied because they included a reference to a Web page or a file that did not exist.

Many not-found errors occur because Web pages and files are deleted or moved to another location. However, some might result from user attempts to access documents that they are not authorized to have.

You can use the HTTP Service: Not Found Errors counter to track the number of not-found errors on your server. You can also set a Performance Monitor alert to notify the Administrator when the number of not-found errors exceeds a threshold.

Following is a brief description of the HTTP Service: Not Found Errors counter.

Table 8.2 Performance Monitor Counter for Not-Found Errors

Counter | Indicates
HTTP Service: Not Found Errors | The number of client read requests that could not be satisfied because the URL did not point to a valid file. Increases in not-found errors might indicate that a file has been moved without its link being updated. However, it might also indicate failed attempts to access protected documents, such as user lists and file directories.


Chapter 9 - Monitoring Dynamic Page Generation

One of the most exciting recent developments in Web page technology is the ability to develop dynamic pages — Web pages that are not assembled until the client requests them. Dynamic pages can display the most current data available and can be tailored to clients' preferences. The power of dynamic pages is likely to increase their use on intranets and on the Internet.

Recent experience has shown that applications written for the Common Gateway Interface (CGI), the most popular dynamic Web page interface, severely degrade performance on Windows NT servers. The performance overhead of some CGI applications can cause both memory and processor bottlenecks. These bottlenecks are far less likely on applications written for the Internet Server Application Programming Interface (ISAPI). Therefore, it is important to understand how CGI and ISAPI applications generate dynamic pages, and how to measure and minimize their overhead.

This chapter covers the following sections:

"CGI and ISAPI Interfaces." An overview of the supported interfaces for generating dynamic pages on Windows NT. This section explains how CGI and ISAPI run on Windows NT and why they perform differently.

"Monitoring Client Requests for Dynamic Pages." Guidelines for using Performance Monitor to monitor client requests for pages generated by CGI and ISAPI. Requests are the primary measure of activity of applications that generate dynamic pages.

"Monitoring Servers Running CGI and ISAPI Applications." Suggests methods of monitoring the overall performance of servers running CGI and ISAPI applications using Performance Monitor and Microsoft Web Capacity Analysis Tool (WCAT).

"Tracking CGI Processes." Guidelines for using Process Monitor and the Processes Tab in Task Manager to track CGI request processes.

"Capacity Planning to Support CGI Applications." Suggests additions to an Internet Information Server (IIS) server configuration to enable you to support CGI applications and minimize their performance overhead.

These topics build on information presented in Chapter 5, "Monitoring Virtual Memory" and Chapter 6, "Preventing Processor Bottlenecks." For more information about CGI and ISAPI interfaces, see the online Windows NT Microsoft Internet Information Server Installation and Administration Guide.


CGI and ISAPI Interfaces

The supported interfaces for dynamic page generation on Windows NT are:

Common Gateway Interface (CGI). An accepted standard for sharing data between browsers and servers. CGI allows interactive applications, such as database query applications, to be run over the Internet. The primary advantage of CGI is that it is common. CGI applications can be run on all popular Web servers and can be written in all common scripting languages, such as Perl and the Visual Basic® programming system.

Microsoft Internet Server Application Programming Interface (ISAPI). The newcomer to the field of dynamic interfaces. This API is designed to optimize the performance of applications that generate dynamic pages on intranet and Internet servers. ISAPI can be run on Windows NT 3.51 and later.

CGI and ISAPI have similar functions, and the technique for coding scripts and applications for CGI and ISAPI is also quite similar. However, CGI and ISAPI applications run very differently on Windows NT.


How CGI Applications Operate

CGI applications are compiled as stand-alone executables. When these executables run, Windows NT creates a new, separate process for every client request handled by the application, even if a single client submits more than one request. At any given time, the server is supporting a separate process for every ongoing request. When a request is complete, the server must perform a series of steps to delete the process.

CGI was created for a UNIX environment where processes are the basic unit of operation and have less overhead than processes in Windows NT. In Windows NT, where threads are the basic unit of operation, processes have substantial overhead. Each process receives a private physical memory allocation, is granted space in the paged and nonpaged memory pools, and is protected by the features of the Windows NT security model. In fact, every attribute that makes processes in Windows NT robust also makes them costly. Because CGI requests each executable to run in a separate process, CGI applications have much higher overhead than the alternative, ISAPI extensions.


How ISAPI Extensions Operate

ISAPI applications are compiled as dynamic link libraries (DLLs) that are loaded into the HTTP service when the service starts. ISAPI applications are actually extensions of the HTTP service. ISAPI applications remain in physical memory; run as threads within the IIS service process, Inetinfo.exe; and share the Inetinfo.exe memory space. When a client requests a page generated by an ISAPI extension, a waiting thread processes the request. When the request is complete, the thread returns to the thread pool until another request arrives. No further processing time or memory is required.


CGI and ISAPI Overhead

The effect of running requests as processes rather than as shared threads is significant. CGI applications have been demonstrated to use three to five times more processor time and memory space. CGI applications have also been demonstrated to be three to five times slower than equivalent ISAPI DLLs on the same server and network.

If you run CGI or ISAPI applications, or plan to, you need to know how to monitor their overhead. You must also build in sufficient excess capacity to accommodate their use. The following sections explain how to monitor CGI and ISAPI applications, and how to use simulation tools to help predict processor and memory requirements for CGI and ISAPI.


Monitoring Client Requests for Dynamic Pages

The first step you should use to measure the effect of an application on a computer configuration is to determine how the computer responds to different levels of application activity.

The most common indicator of the activity of an application that generates dynamic pages is rate of requests to the application. CGI and ISAPI applications become active when they respond to requests and are generally inactive between requests. The more requests the application responds to, the more active it is judged to be.

First, you measure the activity level of an application. Then you can compare the effect of different levels of activity of a single application on the computer. You can also compare the effect of the same activity levels of different applications.


Using Performance Monitor to Monitor Client Requests

Performance Monitor includes a set of counters that measure the rate of requests to CGI and ISAPI applications running under each IIS service. These counters are included in the HTTP Service, FTP Server, and Gopher Service performance objects. However, Internet Information Server 2.0 supports ISAPI only on the HTTP service. The ISAPI counters on other services always display a value of zero.

The following table lists the counters that count requests to ISAPI and CGI applications. Please note that these counters display the last observed value, not an average. It is important to log these counters over time and to display the results in a chart, as opposed to a report.

Table 9.1 Performance Monitor Counters for ISAPI and CGI Requests

Counter | Indicates
HTTP Service: Current CGI Requests | How many requests for pages generated by CGI applications are being processed simulataneously.
HTTP Service: Maximum CGI Requests | The maximum number of requests for pages generated by CGI applications that were processed simultaneously since the service started.
HTTP Service: CGI Requests | The total number of requests for pages generated by CGI applications since the service started. The value of this counter includes successful and failed requests.
HTTP Service: Current ISAPI Extension Requests | How many requests for pages generated by ISAPI DLLs are being processed simultaneously.
HTTP Service: Maximum ISAPI Extension Requests | The maximum number of requests for pages generated by ISAPI DLLs that were processed simultaneously since the service started.
HTTP Service: ISAPI Extension Requests | The total number of requests for pages generated by ISAPI DLLs since the service started. The value of this counter includes successful and failed requests.

These counters are also included in IISDyn.pmw, a Performance Monitor workspace settings file on the Windows NT Server Resource Kit Supplement 1 CD.

By themselves, these counters are indirect indicators of processor activity. When combined with information about server performance, however, these counters can help you judge the effects of different levels of activity on the performance and efficiency of your server.


Monitoring Servers Running ISAPI and CGI Applications

You can monitor the effect of ISAPI and CGI applications on the overall performance of your server. In general, CGI applications use significantly more processor time and memory than equivalent ISAPI DLLs. You can measure this disparity on your servers by using the general server monitoring techniques developed in Chapter 5, "Monitoring Virtual Memory" and Chapter 6, "Preventing Processor Bottlenecks."

This section suggests two approaches to monitoring the effects of dynamic page-generating applications on general server performance:

Using Performance Monitor to monitor server performance while running ISAPI extensions and CGI applications on your server.

Using WCAT, the Web Capacity Analysis Toolkit, to simulate the effects of CGI and ISAPI applications on your server.

You can also use Performance Monitor to monitor your WCAT tests. The following sections explain these monitoring techniques in more detail.


Monitoring the Effect of CGI and ISAPI Applications on Overall Server Performance

If you are running CGI applications or ISAPI extensions, you can use Performance Monitor to monitor the effect of these processes on your server.

Use the Performance Monitor counters in IISProc.pmw, IISMem.pmw, and IISDyn.pmw to measure processor and memory use on the server during periods of very high or very low CGI or ISAPI application activity. Log these counters while running one of the following tests:

Monitor the effect of a CGI application or an ISAPI extension on overall server performance.

Monitor the server while running with, and then, without the CGI or ISAPI application. Log the counters for several days under similar conditions. Next, compare the rates of processor use, the average length of the processor queue, the number of available bytes, and the rate of page faults of the "with application" and "without application" tests. The difference between the values should be due to performance and memory overhead of the application.

Compare the effect on your server of equivalent ISAPI and CGI applications.

If you have ISAPI and CGI scripts that generate the same pages, you can use IISProc.pmw, IISMem.pmw, and IISDyn.pmw to compare ISAPI and CGI performance. Log server performance while the server is running one application and then log server performance while the server is running the other application. Classify the data based on the average number of requests to the application during each period. Then, compare the values of the counters during periods when the rates of CGI and ISAPI requests were similar.


Using WCAT to Simulate ISAPI and CGI Applications

Even if you do not have any available ISAPI or CGI applications, you can still test the effect of such applications on your server configuration by using WCAT. WCAT comes with several prepared tests designed for simulating the effects of CGI and ISAPI applications on your server. The following table lists these tests and provides a brief explanation of each test.

Table 9.2 WCAT Tests of ISAPI and CGI Applications

Test | Description
CGI25 | 25% of the workload consists of CGI requests; the remaining 75% represents requests for static files based on an average workload.
CGI50 | 50% of the workload consists of CGI requests; the remaining 50% represents requests for static files based on an average workload.
CGI75 | 75% of the workload consists of CGI requests; the remaining 25% represents requests for static files based on an average workload.
ISAPI25 | 25% of the workload consists of ISAPI requests; the remaining 75% represents requests for static files based on an average workload.
ISAPI50 | 50% of the workload consists of ISAPI requests; the remaining 50% represents requests for static files based on an average workload.
ISAPI75 | 75% of the workload consists of ISAPI requests; the remaining 25% represents requests for static files based on an average workload.


Using Performance Monitor to Monitor WCAT Tests

You also can use Performance Monitor to monitor server performance during WCAT tests. The method for activating Performance Monitor during a WCAT test is described in detail in the WCAT user guide on the Supplement 1 CD.

The WCAT run command includes a -p switch that activates Performance Monitor during a WCAT test. When you include the -p option in the WCAT run command, the WCAT controller samples and averages selected Performance Monitor counters during the WCAT test. You can specify the Performance Monitor counters that you want WCAT to sample by including them in a script file with a filename extension of .pfc. The name of your .pfc file is part of the syntax of the -p switch.

The Supplement 1 CD includes IISDyn.pfc, a WCAT file of Performance Monitor counters, designed for use with the ISAPI and CGI tests. This file consists of the counters in IISProc.pmw, IISMem.pmw, and IISDyn.pmw.

The following experiments involve running different WCAT tests in sequence and monitoring the effect of the test on your server, using Performance Monitor. When the tests are complete, you can compare the relative effect of each test on server performance.

The suggestions for using WCAT and Performance Monitor to test server performance are:

To determine the effect of a CGI application on your server, run the CGI25, CGI50, and CGI75 tests sequentially while logging the Performance Monitor counters in Dyn.pmc.

To determine the effect of an ISAPI application on your server, run the ISAPI25, ISAPI50, and ISAPI75 tests sequentially while logging the Performance Monitor counters in Dyn.pmc.

To compare the effects of CGI to those of ISAPI, run the CGI75 and ISAPI75 tests sequentially while logging the Performance Monitor counters in Dyn.pmc.

To analyze the data from these tests, note any change in processor and memory use as the proportion of CGI or ISAPI requests increases, or between CGI and ISAPI. The effect of the change in workload varies substantially between server configurations. You can use this data to determine whether your server is prepared to handle this workload efficiently. You can vary the workload or vary the server configuration by adding processors or memory between test trials.

The next section introduces another aspect of monitoring CGI and ISAPI applications. In addition to monitoring general server performance, you can also monitor the processes in which the applications run.


Tracking CGI and ISAPI Processes

The most common way to monitor the overhead of ISAPI and CGI applications is to monitor general server performance under varying levels of application activity. This technique is described in the preceding sections.

In addition to monitoring changes in overall server performance, you can also monitor the processes in which the applications run. This section suggests some tools and methods for monitoring the processes in which ISAPI extensions and CGI applications run.


Monitoring ISAPI Extensions

ISAPI scripts are compiled into DLLs that run in the Internet Information Server process, Inetinfo.exe. You can monitor the processor and memory use of the Inetinfo process, but it is difficult to distinguish the resource use attributable to ISAPI from that of the rest of the services running under Inetinfo. It is also extremely difficult, though technically possible, to associate individual threads in Inetinfo with ISAPI requests.


Monitoring CGI Requests

CGI applications are not as difficult to monitor as ISAPI extensions. In Windows NT, CGI applications are stored and run as separate executables. Requests for pages generated by CGI run as separate processes. You can use most process-monitoring tools to view the processes in which the CGI requests run. However, the request processes often are so ephemeral that it is hard to track them effectively with any tool that isn't updated frequently or that requires that you choose the process before monitoring it.

Process Monitor and Task Manager provide a continually updated running list of processes. You can use Process Monitor and Task Manager to monitor the processes in which CGI requests run.


Using Process Monitor and Task Manager to Monitor CGI Processes

Process Monitor (Pmon.exe) and the Task Manager Process tab are both useful for monitoring CGI processes. Although these tools do not log process-specific data over time and cannot export data for other uses, they are particularly effective for monitoring short-lived processes. Both tools display a list of all processes running on the computer, along with different measures of processor and memory use.

Process Monitor is included on the Windows NT Workstation Resource Kit CD in the Performance Tools group (\Perftool\Meastool). Process Monitor is updated automatically every five seconds.

Task Manager is integrated into Windows NT. To start Task Manager, press ctrl+shift+esc. Click the Processes tab on Task Manager to see a list of processes running on the server, including the processes in which CGI requests run. You can set the rate at which Task Manager is updated by clicking Update Speed on the View menu.

The Task Manager Processes tab displays a table listing the running processes along with performance information about each process. By default, Task Manager displays the Process Identifier, CPU Usage, CPU Time, and Memory Usage of each process. You can change the type of performance information listed about each process. To add or remove a Task performance measure, from the View menu, click Select Columns, then click a performance measure.

Note

Please note that the Process Monitor and Task Manager CPU Time, Page Faults and Mem Usage counts are cumulative. These performance measures show how much of a resource the process has used since the process started. A high value might indicate that a process has been running for a long time, not that the process is using the resource at a high rate.

Warning

You should be careful when running any monitoring tool for an extended period of time at a very high refresh rate. The overhead of the tool is directly proportional to the frequency at which it is updated. When using Process Monitor and Task Manager, monitor the overhead of the processes in which the tools run and subtract the overhead from your test results.

Monitoring CGI and ISAPI processes provide another view of the performance of CGI and ISAPI applications. This additional information can help you plan your server capacity.


Capacity Planning to Support ISAPI and CGI Applications

Although the data values vary widely among different servers, CGI applications and, to a lesser extent, ISAPI extensions, have much higher overhead than standard "static" pages. But the overhead of dynamic page-generating applications should not deter you from adding dynamic pages to your published files. The ability to monitor these applications and estimate their overhead during periods of varying activity allows you to prepare your server for the increased workload.

Some suggestions for optimizing your configuration to run applications that generate dynamic pages are:

Upgrading processors. CGI and ISAPI applications both benefit from faster processors. Fast processors are especially important to CGI applications in which each request runs in a separate, single-threaded process.

Adding processors. ISAPI extensions are multithreaded and can run simultaneously on multiple processors. Adding processors is probably the easiest way to improve the efficiency of ISAPI applications. CGI applications benefit from multiple processors, too. Even though CGI requests run in separate single-threaded processes, multiple CGI requests can each run on different processors simultaneously.

Adding memory. CGI applications typically use three to five times more physical memory than equivalent ISAPI applications.

Defragmenting your disks. If your cache performance declines over time, defragment the disk. Your files might have become fragmented over time.

Redesigning your static pages. Using current technology, even ISAPI, which is optimized for Windows NT, is far slower and less efficient than serving static pages. If you are generating pages dynamically to satisfy user preferences, consider substituting ten or twenty different static variations for a single dynamically generated page. If you are generating pages dynamically to provide frequently updated data, consider redesigning your application so that it generates a single dynamic page on a fixed schedule and then stores that page for repeated static retrieval until the next update.

Converting CGI Scripts to ISAPI Scripts. ISAPI is optimized to run on Windows NT. Converting CGI applications to ISAPI extensions can improve performance significantly in a small or large installation. (To see the magnitude of the difference on your server, run the WCAT CGI75 and ISAPI75 tests, and compare the results.) For instructions on converting CGI scripts to ISAPI DLLs, see the ISAPI Programmer's Reference in the Win32 Software Development Kit.

Incorporate logging in CGI and ISAPI routines. Add transaction logging functions to your CGI and/or ISAPI code. The transaction-logging function should record the time each incoming request was received and the time it was completed. Or, you can add extensible Performance Monitor counters to the code and use Performance Monitor to create the transaction log or monitor the routines. When delays arise, the transaction log will help you determine the source of the delay.

Despite their performance cost, dynamic Web pages are likely to increase in popularity and constitute a larger proportion of the average Web server file base as the technology progresses. The challenge for administrators is to preserve speed and efficiency while publishing ever more complex pages.

On Windows NT, CGI and ISAPI both have higher overhead than serving static pages from memory. But the difference between CGI and ISAPI performance is significant. In general, CGI applications are much slower and use more processor time and memory space than equivalent ISAPI extensions. Fortunately, you can measure the effect of CGI and ISAPI applications on the performance of your servers and upgrade your configuration to meet the challenges CGI and ISAPI pose.


Chapter 10 - Additional Network Services - Enterprise Level

Terra Flora was introduced in the Microsoft Windows NT Server version 4.0 Resource Kit: Windows NT Server Networking Guide as a case study in interoperability of heterogeneous networks. Chapter 4, "Terra Flora: A Fictitious Case Study," in the Windows NT Server Networking Guide, provided the history of the corporation and presented a plan for interoperability. Chapter 5, "Network Services: Enterprise Level," provided the business justification for selecting Windows NT Server services to interoperate the heterogeneous networks. It also presented specific information on the installation and configuration of Enterprise level services that support the network itself and keep the corporation-wide information synchronized.

Terra Flora is a totally fictitious company whose business operations and networking environment are being examined and used to demonstrate the functionality of Windows NT Server products. The names of companies, products, people, characters, and data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted.

This chapter will present information on some of the additional Enterprise services that were not covered earlier. The services that will be discussed include:

Directory Service Manager for NetWare (DSMN)

Web Administration for Windows NT Server

Information about each service will include the business reasons for selecting the service and instructions on how to install and configure the service.

Located inside the back cover of the Windows NT Server Resource Kit Supplement 1 is a network diagram that represents the hardware and software now interoperating at Terra Flora. Frequent references will be made to the diagram.


Directory Service Manager for NetWare

Microsoft Directory Service Manager for NetWare (DSMN), a Microsoft Windows NT Server utility, enables synchronization of user accounts between Windows NT Server domains and servers running Novell NetWare version 2.x, 3.x, and 4.x, running in the bindery emulation mode. DSMN extends the Windows NT Server directory database service features for user and group account management to NetWare servers. By using DSMN, the NetWare server can be managed as part of the Windows NT domain, using the Windows NT Directory Services to manage the NetWare-based servers.

DSMN is a utility offered as part of the Microsoft product called Services for NetWare. For details on the use of DSMN, see the Services for NetWare Administrator's Guide.

Chapter 5 of the Windows NT Server Networking Guide described how centralized network logon was installed and configured. Terra Flora chose the network logon services provided by the Windows NT operating system because Windows NT Server is the only product that allows users to log on to all of the Terra Flora heterogeneous networks with a single user account and password. The benefit of using a single user account and password is that users only have to remember one account and password to log on and then be able to access any application they need.

One of the challenges with the use of a single logon is the synchronization of the user accounts and passwords on all servers that the users access. Currently, to synchronize user accounts and passwords at Terra Flora, network administrators must grant permissions to each user on each individual NetWare server by creating a user account. In addition to adding the users to each NetWare server, users must be added to the Windows NT domain. Thus, although the Windows NT Server network logon service provides single-account logon to all servers, administrators must still add the users to several servers.

If a user changes the password for the logon, the password must be changed on all servers that the user accesses. If the administrator forgets to change the password on a single server, the user accounts and passwords are out of sync and the user cannot access the server.

For each Windows NT domain, the directory database of the primary domain controller (PDC) contains all users of all services. Therefore, any user with permissions who is added to the domain's directory database can access any server that is part of that domain.


The Decision to Use DSMN

Terra Flora will use DSMN to synchronize the user accounts and passwords on both the Windows NT and NetWare servers. Because DSMN simplifies network administration tasks, Terra Flora can save time and money.

By using DSMN, NetWare servers can be added to the Windows NT domain and then be administered as part of that domain. The NetWare users are added to the directory database residing on the Windows NT PDC. All permissions granted to users on the NetWare servers can be granted on servers running Windows NT Server. Similarly, all permissions granted to users in the Windows NT domain can be granted on servers running NetWare. Administrators no longer need to add individual users to each individual server.


Simplifying Administrative Tasks

By using DSMN, administrators can centrally manage their Windows NT Server and NetWare account information from Windows NT Directory Services.

Administrators set up only one user account and password for each user on the network.

Administrators use a point-and-click interface to propagate, or copy, user accounts to and from servers running Windows NT version 3.51 or higher and servers running NetWare version 2.x and 3.x.

Administrators have multiple options for setting up initial passwords, selecting which user accounts are to be propagated, and performing account deletions. A trial run option is included to test a propagation strategy.


DSMN Provides Benefits to Network Users

In addition to simplifying administrative tasks, DSMN provides the following benefits to network users:

New users are added to the network quickly. The administrator adds the user to the Windows NT Server Directory Services, and the user account is automatically propagated back to all authorized NetWare servers.

Each user's account name and password are identical on all NetWare and Windows NT servers, so the same name and password are used regardless of where a user logs on.

Users who use Windows NT Server Remote Access Service (RAS) can log on through RAS by using the same user account and password.

Windows NT Directory Services can authenticate users to business applications that are running on the Windows NT and NetWare servers.


Synchronizing User Accounts at Terra Flora

The primary benefit that Terra Flora receives by using DSMN is that user accounts are synchronized between Windows NT and NetWare servers. (Please refer to the network diagram located inside the back cover of the Windows NT Server Resource Kit Supplement 1. There are two NetWare servers represented on the Terra Flora network diagram in the California domain, named CANW410DIV01 and CANW312DPT01.)


Deciding Which NetWare Servers to Add to the Domain

CANW312DPT01 is a NetWare server that houses front-end applications to the Oracle databases running on the DEC UNIX server in the Nursery division. The Nursery division users require access to the business applications housed on the DEC UNIX server through the NetWare servers. The users also need access to the Enterprise services on the Windows NT servers. For this reason, Terra Flora will add CANW312DPT01 to the Windows NT California domain.

The NetWare server CANW410DIV01 runs NetWare 4.10. This server is set up exclusively to pilot the Network Directory Services (NDS) product in the NetWare operating system. DSMN does not function on NetWare 4.10 servers unless they are operating bindery emulation. Because this NetWare server is using NDS and not bindery emulation, this server will not be added to the Windows NT California domain.

Terra Flora wants to add all of its NetWare servers running version 3.x and 2.x to the Windows NT California domain. A NetWare server in the California domain that runs version 3.12 is not represented on the network diagram. CANW312DPT02 is a department-level server that runs customized business applications for the sales department.

After adding the DSMN software, the administrators will use DSMN to select CANW312DPT01 and CANW312DPT02 as the two NetWare servers to be added to the Windows NT California domain. After they are added, the NetWare servers will be administered in the same way as any other server in the domain.


Deciding Which Accounts to Administer with DSMN

Different groups within the Nursery division, including accounting, sales, and administrators, require access to the CANW312DPT01 NetWare server. Administrators need access to perform administrative tasks on the server itself. Accounting and sales need access to the Nursery business applications housed on the DEC UNIX machine. Additionally, all three groups need access to the Windows NT servers, such as CANTS40ENT03, which houses Enterprise services of DHCP, DNS and WINS.

CANW312DPT02 is a NetWare server that stores the customized sales business applications. The sales and administrators groups will, therefore, need access to CANW312DPT02 to perform sales and administrative tasks. The accounting group will not need access to CANW312DPT02.

After the servers are added to the domain, the administrators will select which of the NetWare server user and group accounts the domain will manage. All user and group accounts can be moved to the Windows NT directory database, or only some of them. The selected accounts will be copied to the directory database of the Windows NT PDC.

Figure 10.1 When a NetWare server is added to a domain for management, NetWare user and group accounts are moved to the domain.

Maintain or Delete Remaining Accounts

If some of the users and groups are moved to the directory database, the Terra Flora administrators will choose whether to delete or retain the remaining users and groups on the NetWare server. If they are retained, the accounts will be administered by using the NetWare administrative tools.

Note

Do not use NetWare administrative tools on accounts managed by Directory Service Manager for NetWare. If you do, the accounts on that NetWare server become unsynchronized with the accounts in the domain.

After selecting which accounts will be retained and added to the Windows NT directory database, the administrators will specify how the Windows NT Server domain is to propagate user and group accounts back to the CANW312DPT01 and CANW312DPT02 NetWare servers. All accounts, or a subset of the accounts, can be copied to the NetWare servers. When the Terra Flora administrators select which Windows NT Server groups to copy, user accounts that are members of any of the groups selected will also be copied.

The list of users and groups being copied will differ for each of the two NetWare servers in the domain. If a NetWare user needs access only to specific NetWare servers, the user's account will be copied to only those servers, which minimizes network traffic and makes DSMN run more efficiently.

For example, the sales and administrators groups at Terra Flora need access to both of the NetWare servers, CANW312DPT01 and CANW312DPT02, while members of the accounting group need access to only CANW312DPT01. When specifying which groups to copy to CANW312DPT02, Terra Flora administrators select both administrators and sales; but when specifying the users to propagate to CANW312DPT01, they select all three groups.

Figure 10.2 The NetWare user accounts, along with Windows NT Server accounts, are copied back to the NetWare server.

Note

The list of groups that the Windows NT Server domain copies to the NetWare server can be modified any time after adding the NetWare server to the domain.

Identical User Names Are Merged

Terra Flora is adding multiple NetWare servers to be managed by the same California domain. Because each server has a user or group account with identical names, the accounts will be merged in the California domain.

For example, AshleyM has an administrator's account on both of Terra Flora's NetWare servers. When CANW312DPT01 is added for management to the domain, the AshleyM account is created in the Windows NT Server domain. That Windows NT Server account is also given the same rights and permissions that the AshleyM NetWare account had.

When CANW312DPT02 is added to the domain, DSMN recognizes that AshleyM already has an account in the domain. DSMN gives the account the rights and permissions of the CANW312DPT02 AshleyM account. The domain's AshleyM account then has the same rights and permissions that were previously assigned to both the NetWare server's AshleyM accounts.

DSMN can also merge accounts with different user names on multiple NetWare servers. For example, if AshleyM had an account on the CANW312DPT02 server with a user name of AshleyMe, this account can be merged into the domain's AshleyM account. This account would then have the same rights previously held by both AshleyM and AshleyMe.

For more information about renaming accounts, see the section "Using a Mapping File to Rename User Accounts" in Chapter 7, "Administering Directory Service Manager for NetWare," in the Services for NetWare Administrator's Guide.

Figure 10. 3 User accounts on separate NetWare servers can be merged into a single account in the domain, with all of the rights previously held by both accounts.

Note

If there is an account on a NetWare server that has the same name as an account on the Windows NT Server domain, the rights and permissions of the NetWare account are given to the existing Windows NT Server account. If the existing Windows NT Server account is NetWare-enabled, then the account's existing password is used. If the account is not NetWare-enabled, the account is given a new password to enable it to be copied to NetWare servers.


Installing DSMN

While you can install DSMN on any Windows NT domain server, the service runs only on PDCs. The server on which you are installing DSMN must:

Be running Windows NT Server version 4.0 or version 3.51. If the computer runs Windows NT Server 3.51, it must also run Windows NT Server Service Pack 2 or later. Only instructions for installing on Windows NT Server 4.0 are included in this supplement. For details about installing on Windows NT Server 3.51, see Chapter 1, "Understanding and Installing Directory Service Manager for NetWare," in the Microsoft Directory Service Manager for NetWare Administrator's Guide for Windows NT Server 3.51.

Have Gateway Service for NetWare installed. This service is included with Windows NT Server. For installation instructions, see the Windows NT Server Networking Guide, Chapter 5, "Network Services: Enterprise Level."

Note

You may want to install DSMN on one or more backup domain controllers to speed up recovery in the event of a failure of the PDC.

Instructions in this section include those for:

Installing DSMN from a CD-ROM.

Creating disks from the CD-ROM and installing DSMN from those disks.

Installing only the DSMN administrative tools, which can be used to remotely run DSMN on any domain server on the network.


Installing DSMN from a CD-ROM

DSMN is shipped as a separate Microsoft product and is included on the compact disc titled Services for NetWare.

Û To install DSMN on a Windows NT Server 4.0 computer from a CD-ROM

1. Double-click My Computer.

2. Double-click Control Panel.

3. Double-click Network.

4. Click the Services tab, and then click Add.

5. Click Have Disk even if Directory Service Manager for NetWare appears in the Network Service list.

6. Insert the Services for NetWare CD in the CD-ROM drive.

7. Type the path, and then click OK.

The path is drive:\DSMN\NT40\processor, where drive is the drive letter of the CD-ROM drive and processor is the server's processor type. For example, type d:\dsmn\nt40\i386 to install on an x86-based computer with a CD-ROM drive at drive D. The possible values for processor are i386, MIPS, ALPHA, and PPC.

8. Select Directory Service Manager for NetWare, and then click OK.

9. In both the Password and Confirm Password boxes, type a password for the DSMN user account, and then click OK.

This account is used by the service to perform tasks.

When you restart the computer, the DSMN service will automatically start. To configure how this service starts and stops, use the Services option in Control Panel or the net start mssync and net stop mssync commands.

Note

On computers that have multiple network cards and that run DSMN but not File and Print Services for NetWare, the computer itself must have a network number defined for the NWLink IPX/SPX Compatible Transport running on the Windows NT PDC. This network number is a NetWare concept (see your NetWare documentation), and the number you define must be unique. It must be different from all other network numbers on your NetWare network. To configure a network number, go to Control Panel, click Network, click Protocols, click NWLink IPX/SPX Compatible Transport, and then type your network number in the Internal Network Number box.


Installing DSMN from a Floppy Disk

Even if a computer does not have a CD-ROM drive, DSMN can be installed by creating floppy disks from the Services for NetWare CD.

Û To install DSMN on a Windows NT Server 4.0 computer from a floppy disk

1. Insert the Services for NetWare CD into the CD-ROM drive.

2. Format two blank, high-density, 3.5-inch floppy disks. Insert one disk into the floppy disk drive, usually drive A.

3. Switch to the \Dsmn\Nt40\Disks directory.

4. Switch to the subdirectory for the platform that you want to create installation disks for. For example, switch to Disks\i386 to create installation disks for an x86-based computer.

5. Copy the contents of the Disk1 subdirectory to the disk, and then copy the contents of the Disk2 subdirectory to the other disk.

6. Follow the steps in the previous procedure, with the following exception. In the Insert Disk dialog box, specify the drive that contains Disk 1. You will be prompted to insert Disk 2.


Installing DSMN Administrative Tools

Terra Flora will install just the administrative tools for DSMN on computers running Windows NT Workstation or Windows NT Server that will be used to administer domain servers remotely.

For instructions on how to install the DSMN administrative tools, follow the steps in the earlier procedure for installing DSMN from a CD-ROM. In step 8, however, select Directory Service Manager for NetWare Administrative Tools Only instead of Directory Service Manager for NetWare.

Note

To administer a domain other than the domain containing your computer, that domain must be trusted by the domain containing your computer.


Synchronizing Accounts on Servers

Synchronization Manager is the tool used to add NetWare servers for management within Windows NT Server domains and to manage other aspects of DSMN. The main screen of Synchronization Manager appears below.

The NetWare Server column lists the names of servers that have been added to this domain for management. The Description column shows the version and type of each server. To the left of the server name is an icon that indicates the current synchronization status of the server, as shown in the following table.

Table 10.1 Icon Representation of Synchronization Status

Icon | Status
 | The server is currently synchronized with the domain.
 | The server is not currently synchronized. Directory Service Manager for NetWare will soon synchronize it.

When DSMN is installed, it is added to the Administrative Tools menu of Windows NT Server. When you click DSMN to start it, Synchronization Manager is displayed.

Û To start Synchronization Manager

1. Click Start.

2. Point to Programs.

3. Point to Administrative Tools.

4. Click Directory Service Manager for NetWare.


Adding a NetWare Server for Management

At Terra Flora, the NetWare servers in the California domain named CANW312DPT01 and CANW312DPT02 will be added to the Windows NT California domain. In this way, users set up in the Windows NT directory database can be copied to the NetWare servers and will remain synchronized.

When a NetWare server is added to a Windows NT domain, user and group accounts are copied from the server to the domain. Those accounts, along with original Windows NT Server accounts, are then copied back to the NetWare server. From then on, the accounts are maintained on the domain, and account changes are automatically copied to the NetWare servers in the domain.

Note

For compatibility, Directory Service Manager for NetWare cannot propagate more than 2,000 accounts to a NetWare server. If you try to propagate too many accounts to a NetWare server, you will be prompted to propagate fewer groups.

Before Adding a NetWare Server to a Domain

To ensure that the addition of a NetWare server to a domain for management goes smoothly, do the following before adding the server:

Use NetWare utilities to back up the NetWare server's bindery.

Check user names on the NetWare server and the Windows NT Server domain. If any are identical, unless you rename the NetWare user account, the rights and permissions of the NetWare user account will be granted to the existing Windows NT Server account. For more information about renaming user accounts, see the section "Using a Mapping File to Rename User Accounts" in Chapter 7, "Administering Directory Service Manager for NetWare," in the Services for NetWare Administrator's Guide.

If multiple NetWare servers are being added to the domain, check whether any users have accounts on multiple NetWare servers with different user names. If so, choose the name you want the user to have on the domain, and then transfer the other accounts to that user name. For more information, see the section "Using a Mapping File to Rename User Accounts" in Chapter 7, "Administering Directory Service Manager for NetWare," in the Services for NetWare Administrator's Guide.

Check the account policies of the domain to make sure they are acceptable. After a NetWare server is added, these policies will affect user logons to the NetWare server.

Note

To maintain password history, set the domain's password uniqueness to remember passwords, and then set the number of passwords to eight or more. If the limit is less than eight, password history affects only logons to servers running Windows NT Server, not to NetWare servers.

If the File and Print Services for NetWare product was previously installed on the primary domain controller, reset the passwords of any user accounts that were NetWare-enabled before DSMN was installed. DSMN cannot read these existing passwords.

To enable previously NetWare-enabled users to be copied to NetWare servers, create a batch file that calls the net user command for each user and resets the password. For the most security, you can use the /rand option to randomly generate new passwords for these users.

Perform a trial run of the addition, and then carefully examine the report it generates to make sure that the results are what you want.

For details on any of the preceding steps, see Chapter 7, "Administering Directory Service Manager for NetWare," in the Services for NetWare Administrator's Guide.

After the preceding steps are complete, you are ready to add the NetWare server to the Windows NT domain, where it will be managed by using Windows NT Server administrative tools.

To add a NetWare server to be managed in a domain

1. In Synchronization Manager, click Add Server to Manage on the NetWare Server menu.

2. Enter the name of the NetWare server, and then click OK.

3. Type the user name and password to be used to connect to the NetWare server, and then click OK.

The user name must have Supervisor privileges on the NetWare server.

4. Select options in the Propagate NetWare Accounts to Windows NT Domain dialog box to specify how you want NetWare user accounts copied to the domain.

To use a mapping file, click Use Mapping File. To create the mapping file, type a new file name in the File box, and then click Edit. For details on how to use a mapping file, see Chapter 7, "Administering Directory Service Manager for NetWare" in the Services for NetWare Administrator's Guide.

To specify users, groups, and passwords, click Ignore Mapping File.

5. Click Trial Run.

This optional but recommended step generates a report that shows which user and group accounts will be successfully propagated, as well as new user passwords.

6. Click OK to add the server.

7. Click Yes to continue if you have already backed up the bindery of the NetWare server. Otherwise, click No and then back up the bindery before adding the server.

8. In the Set Propagated Accounts on [Server] dialog box, click the option to propagate either all groups (and their members) or only some groups back to the NetWare server.

For help with an option in this dialog box, click Help.

9. Click Yes to delete the NetWare user and group accounts that you are not propagating to the Windows NT Server domain. Click No to keep these accounts and continue managing them on the NetWare server using NetWare administrative tools.

Accounts left behind on the NetWare server cannot use chgpass; they must use NetWare utilities to change their passwords.

Note

When a NetWare server is added to a domain for management, a user account named WINNT_SYNC_AGENT appears in that server's bindery. This account is used by DSMN to access the NetWare server's bindery and should not be deleted.

You can remove a NetWare server from management with a domain at any time. You can then use NetWare administrative tools to administer the server and its current bindery. Or you can restore the bindery if you want to return the server to how it was before you added it to the domain. You can add the server back to a domain at any time.


Administering NetWare Servers as Part of a Domain

After NetWare servers are added to a domain for management and NetWare accounts are specified, Terra Flora will use the Windows NT Server tool, User Manager for Domains, to administer those accounts. Any changes are automatically copied to the NetWare server.

The following table indicates which tools are used to perform administrative tasks.

Table 10.2 Administrative Tools Used to Perform Administration Tasks

Task | Administrative tool
Add NetWare servers to domains | Synchronization Manager
Specify which Windows NT Server groups to copy to NetWare servers | Synchronization Manager
Administer the association of NetWare servers and Windows NT Server domains | Synchronization Manager
Manage account properties of users and groups | User Manager for Domains

For more information, see Chapter 7, "Administering Directory Service Manager for NetWare," in the Services for NetWare Administrator's Guide

Note

After adding a NetWare server to a domain, you continue to use NetWare administrative tools to manage NetWare server functions other than user account management. These functions include shared volumes, file permissions and trustee rights, accounting, and printing.

A NetWare server can participate in only one Windows NT Server domain. After a NetWare server has been added to a domain for management, you cannot add it to another domain without removing it from the first one.


Web Administration for Microsoft Windows NT

Terra Flora administrators often perform network administrative duties at locations other than their desks — for example, when they need to replace a server at another location. Because replacing a server can take several hours, the administrators would like to remotely administer any Windows NT Server from any computer anywhere on the network. Web Administration for Microsoft Windows NT Server provides this capability.

The Web Administration software can be installed on any server that runs Windows NT Server 4.0 and Microsoft Internet Information Server 2.0 (IIS). Installing the Web Administration software on the server enables the server to publish or display Web pages that include forms you can use to administer that particular server.

For information about using Web Administration for Windows NT, see: http://www.microsoft.com/ntserver/webadmin/webadminfaq.htm.


The Decision to Use Web Administration

Web Administration for Microsoft Windows NT Server was chosen by Terra Flora because it is a centralized administration tool that enables remote administration of Windows NT servers from any computer that has a Web browser installed.

Most Terra Flora administrators work primarily at corporate headquarters in Sacramento, California. They travel to various locations within corporate headquarters to perform their work. When administrators are away from their computers, they also need to be able to administer the company's computers that run Windows NT Server.

For example, Terra Flora administrator AshleyM has an office and desktop client computer in the administrator's bull pen, which is located in the area of Building 1 that houses all the main Enterprise servers. On Tuesday, one of the payroll department servers in Building 4 failed. AshleyM went to Building 4 to reload and configure the payroll server.

While in Building 4, AshleyM received a call from a retail store manager stating that a recently hired employee did not have access to the retail store's software.

To better understand this scenario, refer to the Terra Flora network diagram inside the back cover of this supplement. The new employee would authenticate to the network through the server named NENTS40ENT01. AshleyM needs the ability to log on to the Web and set up the user account in the northeast domain from the client she was using in the Building 4 site. Without the Web Administration tool, AshleyM needs to contact another administrator to perform the task.


Web Browsers Are Required

To use the Web Administration tool, administrators need access to a computer that has a Web browser installed. A Web browser is a software tool that retrieves a document from a Web server, interprets the hypertext markup language (HTML) codes, and displays the document to the user with as much graphical content as the software can supply. The client's Web browser will display the graphical interface needed to administer the Windows NT servers. After Web browsers are installed, the Terra Flora administrators will be able to administer any Windows NT Server.


Security

Web Administration for Windows NT Server provides the capability to administer remote Windows NT servers anywhere on an intranet and from the Internet. Terra Flora recognized that they could communicate on the Internet with thousands of potential customers. Conversely, this means that they could be opening their corporate intranet to these same thousands, creating a certain degree of risk. Terra Flora management realized that they need to implement a security configuration that would reduce some of this risk.

Web Administration for Windows NT Server supports several modes of security. Each server administered must support Basic authentication, Windows NT Challenge Response security, or both. Also, the Secure Sockets Layer (SSL) protocol can be used with either or both of these modes for encryption. With encryption turned on, the information in a session is not displayed in readable format by the user.

Basic authentication simply prompts the user for a name and password when the administrator accesses the server. The name supplied is checked against the members of the administrators group on the server. Passwords are transmitted in clear text, which means that they can be viewed.

Windows NT Challenge Response is more sophisticated, and passwords are not transmitted over the network. With this security, the administrator must be logged on to the computer with a user name that is recognized as a member of the Administrator group on the computer they want to administer.

When choosing between Basic authentication and Windows NT Challenge Response, the administrator must consider what the Web browser used to administer the server supports. For more information about what security is supported by different browsers, see the "Browser/Password Authentication Matrix" at http://www.microsoft.com/ntserver/webadmin/webadminfaq.htm.

Terra Flora will also configure Web Administration for Microsoft Windows NT to use the Secure Sockets Layer (SSL) protocol. SSL supports authentication of users and encryption of session data. To use SSL, Terra Flora administrators must obtain a certificate from a certificate authority such as VeriSign. For more information on SSL, see Chapter 5, "Securing Your Site Against Intruders," in the online Windows NT Server Microsoft Internet Information Server Installation and Administration Guide.

Because the Web browsers at Terra Flora support only Basic authentication, Terra Flora decided to use SSL. Even if additional clients supporting Windows NT Challenge Response are supplied with Web browsers, SSL will still be used because SSL encrypts all data in the session. See the section "Adding SSL to Provide Additional Security" later in this chapter for details.

If you are not familiar with Internet security, see the following sources to learn more about it:

Chapter 3, "Configuring and Managing Your Internet Information Server," in the online Microsoft Internet Information Server Installation and Administration Guide.

Chapter 5, "Securing Your Site Against Intruders," in the online Microsoft Internet Information Server Installation and Administration Guide.

Chapter 3, "Server Security on the Internet," in the Microsoft Windows NT Server Resource Kit: Windows NT Server Internet Guide.

For more information about general Windows NT Server security, see the following:

Windows NT Server Concepts and Planning.

Chapter 2, "Network Security and Domain Planning," in the Microsoft Windows NT Server Resource Kit: Windows NT Server Networking Guide.


Why Terra Flora Will Use Web Administration

The benefit to Terra Flora in using the Web Administration for Windows NT is that limited administrative tasks can be performed remotely to any Windows NT Server from any computer with a Web browser installed. Web Administration for Windows NT assumes that the administrator is familiar with the use of the Windows NT administration tools. For information on use of the Windows NT Server administration tools, see Help.

The following table lists some of the Windows NT Server administration tasks you can accomplish with Web Administration for Microsoft Windows NT Server.

Table 10.3 Tasks You Can Perform with Web Administration for Microsoft Windows NT Server

Category | Tasks
Account Management | Create and delete user accounts (including FPNW user accounts)
 | View and change user information (properties)
 | Change user passwords
 | Disable user accounts
 | Create and remove groups
 | Add and remove users to and from groups
 | Add workstations to the domain
Share Management | View shares for all installed file services (Microsoft, Macintosh, and NetWare compatible file services)
 | Change permissions on shares
 | Create new shares for all installed file services
Session Management | View current sessions
 | Delete one or all sessions
 | Send message to current users of the server
Server Management | Shutdown (reboot) server
 | Change services/driver configuration
 | View System, Application, and Security Log events
 | Server configuration data dump
Printer Management | List print queues and jobs in each queue
 | Pause queue or specific print job
 | Flush queue or specific print job


Remote Administration Using Web Administration

As stated earlier, to use the Web Administration tool, you must be familiar with the Windows NT Server Administrative tools. For example, setting up user accounts using the Web Administration tool is visually different to the administrator than if the administrator uses the Windows NT Server Administrative tool, User Manager for Domains. The differences are not significant if you are familiar with what is required to set up user accounts using the Windows NT Server Administrative tool, User Manager for Domains. For details about using Windows NT Server Administrative tools, see Help.

This section demonstrates how AshleyM, the Terra Flora administrator was able to set up a user remotely from a client located in Building 4 using the Web Administrator.

Adding a User Account with Web Administration

For details on installing the Web Administration for Microsoft Windows NT Server, see the next section, "Web Administration Installation at Terra Flora." Once the software is installed, Ashley M can remotely set up user accounts with Web Administration.

To add a user account using Web Administration:

From the Web page titled Web Administration of Microsoft Windows NT Server, click Accounts. The Account Management on Server CANTS40ENT02 Web page is displayed. The Web page will display the name of the server you are administering; in the following example, CANTS40ENT02 is displayed.

Click Users. A User Accounts dialog box is displayed on the Web page, as shown following.

Click Create New. The Create New User Account dialog box is displayed on the Web page, as shown following.

Supply the information as illustrated in the Web page displayed directly preceding. Click Create. The user account is added to the domain.


Web Administration Installation at Terra Flora

At Terra Flora, installing Web Administration will involve three steps.

Installing Web Administration

Adding SSL to provide additional security

Configuring Password Authentication

You can install the Web Administration for Microsoft Windows NT Server software on any server that runs both of the following:

Windows NT Server 4.0

Internet Information Server 2.0 (included on the Windows NT Server CD)

The actual Web Administration interface is a series of HTML pages that the Administrator navigates through using the client's Web browser. Administrative tasks can be performed using the pages, which include some Wizard-like explanations to assist the user.

You will also need to use a Web Browser. The browser can be located on the server itself or on any other computer that has network access to your server.


Installing Web Administration

Before installing Web Administration, check to see if a previous version of Web Administration of Microsoft Windows has been installed on the server. If so, complete the following steps. Once the steps are completed, you can re-install Web Administration on the server.

1. If you have a previous version of Web Administration of Microsoft Windows NT Server tool installed on this server, stop all Microsoft Internet Information Server services you have running.

2. Delete the following two directories and their contents: inetsrv_root\scripts\NTAdmin and inetsrv_root\wwwroot\NTAdmin

To install Web Administration on the server

Install the software by clicking Web Administration on the Resource Kit Master Setup Screen.

1. The Master setup program auto-launches when the Resource Kit CD is installed, or you can run MSETUP.EXE from the CD root directory.

Or with the Resource Kit CD in the CD ROM, from the Start menu, click Run. Under Open, type

\\drive:\apps\webadmin

and click OK.

2. Restart the Microsoft Internet Information Server services if necessary.

3. Configure password authentication in Microsoft Internet Information Server. For more information, see the section "Configuring Password Authentication."

Note

This self-extracting setup program will install all the files needed into two directories on your server (inetsrv_root\scripts\NTAdmin and inetsrv_root\wwwroot\NTAdmin) and make the required Registry entries.


Adding SSL to Provide Additional Security

As mentioned in the section "Security," if your browser supports only Basic password authentication, it is recommended that you also use SSL. You may also want to use SSL even if you use Windows NT Challenge Response because SSL encrypts all data in the session.

Using the Web Administration tools, you can set up a server to require the use of SSL for administration. To do so, after installing Web Administration on the server, use a Web browser to connect to the server over the Web to administer it.

Û To require the use of SSL for administration

1. Click Maintenance.

2. Click Web Admin Preferences.

3. Select the Ensure use of SSL secure channel check box and click OK.

This sets the Registry entry SSLRequired to 1. SSLRequired is in the Registry key:

HKEY_LOCAL_MACHINE\Software
\Microsoft
\Inetsrv_NTAdmin.

Note

To find which type of password authentication works for the Web browser you will be using, see "Troubleshooting and Common Issues" in the paper titled Web Administration of Microsoft Windows NT Server located at: http://www.microsoft.com/NTServer/webadmin/webadmin.htm.


Configuring Password Authentication

When configuring password authentication, you indicate which authentication type you are going to use. As stated previously in the section "Security," the type of authentication you select depends on what is supported by your Web browser.

To see what authentication methods work with your browser, see "Troubleshooting and Common Issues" on the Web page titled Web Administration of Microsoft Windows NT Server located at: http://www.microsoft.com/ntserver/webadmin/webadmin.htm.

To configure password authentication on the server

1. To start the tool, click Start.

2. Point to and click Programs.

3. Point to and click Microsoft Internet Server.

4. Point to and click Internet Service Manager.

You should see a list of services running on your machine.

5. Double-click the server name on the WWW Service line to open the property page and to start the WWW service if it isn't already started.

6. On the property page, in the Password Authentication group box, select the authentication method you wish to use.

If you need additional information on how to configure the service, see your Microsoft Internet Information Server version 2.0 documentation.


Appendix A - Major Revisions to Existing Resource Kit Books

Supplemental or updated information for both the Microsoft Windows NT Workstation Resource Kit: Windows NT Workstation Resource Guide and the Microsoft Windows NT Server Resource Kit: Windows NT Server Networking Guide is included here as follows:

For Windows NT Workstation Resource Guide, Part V, "Windows NT Registry," this appendix adds a supplemental section titled "Remote Access to the Registry." This supplemental section also contains a correction to an error in Windows NT Workstation Resource Guide Chapter 6, "Windows NT Security," and information on a related topic, "Remote Performance Monitoring."

For Windows NT Server Networking Guide, Chapter 9, "Managing Microsoft DNS Servers," this appendix updates the section titled "Porting Data Files from Other DNS Servers."

For Windows NT Server Networking Guide, Chapter 1, "Windows NT Networking Architecture," this appendix replaces the former section titled "Server Message Blocks" with a new version, titled "Server Message Blocks and the Common Internet File System."


Windows NT Workstation Resource Guide, Part V, "Windows NT Registry"

The following section contains supplemental information on the Windows NT Registry.

"Remote Access to the Registry"

"winreg: Connecting to the Windows NT Registry"

"AllowedPaths: Exceptions to winreg"


Remote Access to the Registry

Windows NT includes a number of security features that protect the Registry from inadvertent or unwarranted access. Windows NT establishes an access control list (ACL) for each Registry subtree, key, and subkey that determines who has access to a Registry element and what a user is permitted to do to that element.

In addition, Windows NT version 4.0 includes an optional security check that controls remote access to the Registry. This check determines which users can connect to the Registry from another computer. After a user is connected, the ACLs for each Registry element govern the user's access to the Registry.

This section explains how Windows NT controls who can connect to the Registry of a remote computer, and it describes:

How the system determines who can connect to the Registry.

The winreg subkey, whose ACL determines who can connect to the Registry.

The default values for the winreg ACL and how to change them.

The AllowedPaths subkey of winreg, which stores a list of commonly used Registry paths. Users who are not included in the winreg ACL can connect to the Registry by using access keys listed in these exception paths.

This material is intended for users who are familiar with both the basic structure of the Windows NT Registry and the basic security features of Windows NT. It is a supplement to Windows NT Workstation Resource Guide, Part V, "Windows NT Registry," and it corrects an error in Windows NT Workstation Resource Guide Chapter 6, "Windows NT Security."

This material also contains a related topic, "Remote Performance Monitoring," which explains the winreg permissions that must be granted to anyone who uses Performance Monitor to monitor Windows NT computers remotely.

Warning

To add or modify a Registry value entry, use admininstrative tools such as Control Panel or System Policy Editor whenever possible. Using a Registry editor (Regedit or Regedt32) to change a value can have unforeseen effects, including changes that can prevent you from starting your system.


winreg: Connecting to the Windows NT Registry

Windows NT 4.0 uses the ACL for winreg, an optional Registry subkey, to determine who can connect to the Registry from another computer. This section explains how to use the winreg subkey ACL to control remote access to the Registry.

Note

The ACL for winreg, not a Boolean value stored in winreg, controls remote access to the Registry. The information in Windows NT Workstation Resource Guide, Chapter 6, "Windows NT Security," is incorrect in this regard.

When a user tries to connect to the Registry remotely, Windows NT looks for the winreg subkey.

If winreg is in the Registry, the ACL for winreg determines which users can connect to the Registry remotely. To connect to the Registry, users must have at least read/write permission, including permission to create subkeys and set values.

If winreg does not appear in the Registry, all users can connect to the Registry remotely.

After a user is connected to the Registry, the ACL for each Registry key or subkey determines whether the user can read, edit, add, and/or delete Registry contents.

The winreg subkey must be located in the following Registry path:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Control
\SecurePipeServers
\winreg

By default, winreg is included in the Registry of Windows NT 4.0 servers only. Administrators can add winreg to the Registry of Windows NT workstations and to the Registry of workstations and servers running Windows NT 3.51 Service Pack 2.

Note

If you add a winreg subkey to the Registry, be sure to add an AllowedPaths subkey under it. Failure to do so can disable some system services. The AllowedPaths subkey is described in the following sections.

The default ACL for winreg is as follows:

Operating system | Default ACL
Windows NT Server | Administrators: Full Control
Windows NT Workstation | (Not in the Registry)

Û To give a user permission to connect to the Registry remotely

1. Start Regedt32.

2. Click the winreg subkey to select it.

3. On the Security menu, click Permissions.

The ACL for winreg appears in the Registry Key Permissions dialog box.

4. Click the Add button in the Registry Key Permissions dialog box.

5. Add the user to the winreg ACL and give the user read access. For detailed instructions, click the Help button in the Registry Key Permissions dialog box.

6. Double-click the name of the user you just added.

7. In the Special Access dialog box, select the Set Value and Create Subkeycheck boxes.

8. Click OK, and then click OK again to close the dialog boxes.

If a user does not have sufficient access to winreg, that user may still be able to connect to the Registry. The winreg subkey contains the AllowedPaths subkey, which stores exceptions to the permissions set in winreg.


AllowedPaths: Exceptions to winreg

The AllowedPaths subkey in winreg contains a single value entry, Machine, which stores a list of paths from the HKEY_LOCAL_MACHINE subtree. The paths named in AllowedPaths are known as exception paths. Users who are not included in the winreg ACL can connect to the Registry to access one of these exception paths.

AllowedPaths was added to enable users to use system services that require that they connect to the Registry. Users must have permission to access the final subkey in an exception path before they can view or edit the Registry remotely.

Note

The exception paths in AllowedPaths are necessary to maintain backward compatibility with system components that need remote Registry access. If you add a winreg subkey to the Registry, be sure to also add an AllowedPaths subkey under it, and then add the default values for the Machine value entry, as described following.

The allowed paths are stored in the Machine value entry in the AllowedPaths subkey. AllowedPaths must appear in the following Registry path:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\SecurePipeServers
\winreg
\AllowedPaths

The Machine value entry appears as follows:

Machine REG_MULTI_SZ
Range: HKEY_LOCAL_MACHINE registry paths
Default: System\CurrentControlSet\Control\ProductOptions
System\CurrentControlSet\Control\Print\Printers
System\CurrentControlSet\Services\EventLog
Software\Microsoft\Windows NT\CurrentVersion

Administrators can add paths to this list. However, if you delete a path, you might disable an essential system service.

The exception granted to paths listed in Machine applies to the last subkey listed in the path and to all subkeys it contains. For example, if Machine includes System\CurrentControlSet\Services\EventLog, any user could connect remotely to the EventLog subkey or to any of its subkeys (or to the subkeys of its subkeys), but not to any other subkey directly under Services, unless that other subkey was specifically listed in Machine.


Remote Performance Monitoring

Windows NT 4.0 includes increased security features to protect the Registry from unwarranted remote access. These new features can prevent users who are not administrators from using Performance Monitor to monitor a Windows NT 4.0 Server from another computer.

This section includes recommended changes to your configuration to allow remote performance monitoring without compromising the security of Registry data. It assumes that you are familiar with the Windows NT Registry structure and with the basic security features of Windows NT.

For general information about security for remote Registry access, see "Remote Access to the Registry," earlier in this appendix.


Enabling Remote Monitoring

Users who monitor another computer remotely by using Performance Monitor require the following permissions:

At least read access to the Perfc*.dat and Perfh*.dat files on the remote computer. These files are installed with Windows NT.

The asterisk in the preceding filenames represents the numeric ID of the spoken language installed with Windows NT. For example, on systems using the English language, the files are called Perfc009.dat and Perfh009.dat.

Permission to connect to the Registry of the computer they are monitoring.

At least read access to the Perflib\LanguageID subkey in the Registry of the remote computer.

The LanguageID subkey noted earlier is named for the numeric ID of the spoken language installed with Windows NT. For example, on systems using the English language, the subkey is Perflib\009.

The following sections explain how to display and change these permissions. It recommends settings that enable a Performance Monitor user to remotely monitor another computer.


Access to Performance Monitor Files on Disk

To monitor a computer remotely by using Performance Monitor, you must have access to Perfc*.dat and Perfh*.dat files, as described previously. By default, these files are installed in Systemroot\System32. If these files are stored on a Windows NT file system (NTFS) partition on the computer being monitored, make certain that the user who is monitoring the remote computer has at least read access to both of the files.

You can use Windows Explorer to view or change the ACL for the Perfc*.dat and Perfh*.dat files. The ACL controls security for these files.


Remote Access to the Registry for Performance Monitor Users

Remote Access to the Registry for
Performance Monitor Users

Performance Monitor extracts counter data from the Registry. A Performance Monitor user who monitors another computer remotely must have permission to connect to the Registry of the remote computer.

Permission to connect is set on the remote computer. Users who have permission to connect to a remote computer's Registry can do so from any computer. By default, only the administrators of a Windows NT Server are permitted to connect to its Registry from another computer. This section explains how to give other users this permission.

On computers running Windows NT 4.0 (and Windows NT 3.51 Service Pack 2), the system uses the ACL for winreg, an optional Registry subkey, to determine who can connect to the Registry from another computer. When a user tries to connect to the Registry remotely, the system looks for this winreg subkey, as described previously in the section "winreg: Connecting to the Windows NT Registry." winreg is located in the following Registry path:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Control
\SecurePipeServers
\winreg

When a user tries to connect to the Registry remotely, the system looks for the winreg subkey.

On Windows NT servers, winreg is included in the Registry by default. The default ACL for winreg gives full control to administrators, allowing them to connect to the Registry. No other users have permission by default. If the Performance Monitor user who is monitoring the server remotely is not an administrator, you must add that user to the ACL for winreg and then give him or her at least read/write permission.

On Windows NT workstations, and computers running Windows NT 3.51 Service Pack 2, winreg is not included in the Registry by default. However, administrators can add winreg to the Registry of these computers to control remote access. If winreg appears in the Registry, the Performance Monitor user must be listed in the ACL for winreg and have at least read/write permission to winreg.

Û To display the ACL for winreg

1. Start Regedt32 on the computer to be monitored.

2. Click the winreg subkey in the following Registry path:

HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Control
\SecurePipeServers
\winreg

If winreg does not appear in the Registry, all users can connect to the Registry remotely. In that case, you can skip both this procedure and the following one and go to the next section, "Access to the Perflib Subkeys."

3. On the Security menu, click Permissions.

The ACL for winreg appears in the Registry Key Permissions dialog box.

4. Double-click the ACL entry for a user or user group to display its permissions.

Users must have at least read/write permission (that is, they must have special access permission to create subkeys and set values) to use winreg to monitor a computer from another computer. Full control is not required. If those people listed as Administrators for your computer have read/write permission to winreg, you can add a user to the list of Administrators. However, you can also give users just the permissions they need to monitor computers remotely.

Û To give a user permission to monitor a computer remotely

1. Display the ACL for the winreg subkey.

2. Click the Add button in the Registry Key Permissions dialog box for winreg.

3. Add the user to the winreg ACL and give the user read access. For detailed instructions, click the Help button in the Registry Key Permissions dialog box.

4. Double-click the name of the user you just added.

5. In the Special Access dialog box, select the Set Value and Create Subkey check boxes.

6. Click OK, and then click OK again to close the dialog boxes.

When you have set the access to winreg, verify that the user has at least read access to all subkeys in the path to winreg. (By default, the Everyone group has permission to read all winreg subkeys and the subkeys in its path.) To check the ACL for each subkey in the path, click Permissions on the Security menu, and then grant the user read access to any ACLs that do not otherwise permit it.


Access to the Perflib Subkeys

After a Performance Monitor user is connected to the Registry of the computer to be monitored, that user needs at least read access to the subkeys that Performance Monitor uses on the remote computer.

The system uses the ACL for the Perflib/LanguageID subkey to determine who has access to Performance Monitor data in the Registry, where Language ID is the numeric code for the spoken language installed with Windows NT. The Perflib\LanguageID subkey is located in the following Registry path:

HKEY_LOCAL_MACHINE\Software
\Microsoft
\Windows NT
\CurrentVersion
\Perflib
\LanguageID

By default, the Everyone group has read access to the Perflib/LanguageID subkey. However, you might need to give a user permission to read the Perflib\LanguageID subkey permissions if default permissions on the computer being monitored have been changed.

Û To give a user permission to read the Perflib\LanguageID subkey

1. Start Regedt32 on the computer to be monitored.

2. Click the LanguageID subkey to select it.

3. On the Security menu, click Permissions.

The ACL for the subkey appears in the Registry Key Permissions dialog box.

4. If necessary, click Add to add the user to the ACL and grant read access. For detailed instructions, click the Help button in the Registry Key Permissions dialog box.

5. To check the ACL for each subkey in the path to the LanguageID subkey, click Permissions on the Security menu. Verify that the user has read access to all subkeys in the path. Add read access to any ACLs that do not otherwise
permit it.


Windows NT Server Networking Guide, Chapter 9, "Managing Microsoft DNS Servers"

The following section has been updated in this chapter:

"Porting Data Files from other DNS Servers"


Porting Data Files from Other DNS Servers

You can use the boot, zone, cache, and other files from non-Microsoft RFC-compliant DNS servers on a Microsoft DNS server. (RFCs, or Requests for Comments, are the official documents of the Internet Engineering Task Force specifying the details for Transmission Control Protocol/Internet Protocol, or TCP/IP, protocols.) To do this, you must install these files in the \Systemroot\System32\DNS directory, and then stop and restart the DNS server.

Before installing files from other DNS servers on a Microsoft DNS server, you must edit the filename and directory location text in the ported files and make additional changes as described in this section.

The boot file is used to load the data files you want to port into a Microsoft DNS server. A boot file is actually a file that controls the startup behavior of DNS servers running under a Berkeley Internet Name Domain (BIND) implementation of DNS. It is a BIND-specific feature and not a requirement of the DNS RFCs. The Microsoft DNS server ability to use a boot file on initial startup is provided to support migration of data from BIND-based DNS servers to Microsoft DNS servers.

Although Microsoft DNS server supports boot files, you must install the edited boot file before using DNS Manager. Starting DNS Manager configures the Microsoft DNS server to use the Windows NT Server Registry instead of the boot file.

If you need to port data files after starting DNS Manager, you must change the value of the EnableRegistryBoot Registry parameter from 1 to 0. The EnableRegistryBoot parameter is located in the following key:

\HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\DNS
\Parameters

Û To change the value of the EnableRegistryBoot parameter

1. Click the Start button, and then click Run.

2. In the Open box, type regedit, and then press ENTER.

3. Open the following key folder:

\HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\DNS
\Parameters

4. Select the EnableRegistryBoot parameter in the right pane of the Registry Editor, and then on the Edit menu click Modify.

5. In the Value Data box, type 0.

6. Click OK.

7. On the Edit menu, click New, and then click DWORD Value.

8. Type 0 in the value box, and press enter.

9. Stop and restart the Microsoft DNS server by using Services in Control Panel.

The following table describes the format of boot file commands. You can use any text editor to edit or create a boot file. Commands must start at the beginning of a line, and no spaces may precede the commands.

Table A.1 BIND Boot File Commands (Replaces Table 9.4 in Windows NT Server 4.0 Networking Guide)

Command | Description |  | Syntax
Directory | Specifies a directory where other files referred to in the boot file can be found. | directory directory
Cache | Specifies a file used to help the DNS service contact DNS servers for the root domain. This command and the file it refers to must be present. | cache filename
Primary | Specifies a domain for which this DNS server is authoritative, and a database file that contains the resource records for that domain in the zone file. Multiple primary command records can be entered in the boot file. | primary domain filename
Secondary | Specifies a domain for which this DNS server is authoritative, and a list of master server Internet Protocol (IP) addresses from which to attempt downloading the zone information. | secondary domain hostlist local filename
Forwarder | Identifies other DNS servers to which the local DNS server can send recursive queries when the local DNS server cannot resolve the queries itself. | forwarders hostlist
Slave | Specifies that the local DNS server cannot resolve queries and must send the queries to DNS servers identified in the forwarders host list. This command can only be used directly following the forwarder command. | slave


Windows NT Server Networking Guide, Chapter 1, "Windows NT Networking Architecture"

The following section:

"Server Message Blocks and the Common Internet File System" replaces the existing section titled "Server Message Blocks."


Server Message Blocks and the Common Internet File System

The Server Message Blocks (SMB) protocol, developed jointly by Microsoft, Intel, and IBM, defines a series of commands used to pass information between networked computers. The SMB redirector packages requests meant for remote servers in an SMB structure.

SMB uses four message types, which are listed following:

Session control messages, which consist of commands that start and end a redirector connection to a shared resource at the server.

File messages, which the redirector uses to gain access to files at the server.

Printer messages, which the redirector uses to send data to a print queue at a server and to get status information about the print queue.

Message messages, which allow an application to exchange messages with another workstation.

The Common Internet File System (CIFS) is a subset of the SMB protocol tuned for use on the Internet. CIFS has been submitted by Microsoft to the Internet Engineering Task Force as an Internet Draft.

SMBs and CIFS provide interoperability between different versions of the Microsoft family of networking products and other networks that use SMBs. SMB and CIFS clients and servers are available for the following operating systems and products:

Windows NT Server

Windows NT Workstation

Microsoft Windows 95

Microsoft Windows for Workgroups

Microsoft LAN Manager for Microsoft Operating System/2 (MS OS/2)

LAN Manager for MS-DOS®

LAN Manager for UNIX

Apple Macintosh®

IBM Warp Connect

DEC Pathworks

Unisys Advanced Server for UNIX

SAMBA

SCO UNIX

For more information about CIFS, see http://www.microsoft.com/intdev/cifs.


Appendix B - Minor Revisions to Existing Resource Kit Books

Future reprints of the four volumes in the Microsoft Windows NT Server Resource Kit version 4.0 and the Microsoft Windows NT Workstation Resource Kit version 4.0 will contain slightly updated information. For those customers who have the first editions of these volumes, a list of the changes that will be made when we reprint these books follows. The online Help versions of these books on the Microsoft Windows NT Server Resource Kit Supplement 1 CD already reflect these changes.


Windows NT Server Resource Kit

The following sections contain changes made to the Windows NT Server Resource Kit. There is a section addressing changes for each of the three books.

"Windows NT Server Resource Guide"

"Windows NT Server Networking Guide"

"Windows NT Server Internet Guide"


Windows NT Server Resource Guide

The following changes were made to the Windows NT Server Resource Guide:

Chapter 2, "Printing"

Next to the last paragraph, last sentence, preceding the words "printer drivers," insert the words "x86-based."

Third sentence, add the word "job" after the first instance of the word "print."

Last sentence, replace the word "four" with "three."


Windows NT Server Networking Guide

The following changes were made to the Windows NT Server Networking Guide:

Chapter 1, "Windows NT Networking Architecture"

Figure 1.1 has been changed to clarify that the Microkernel and HAL are not Windows NT Executive Services.

Replace the second paragraph under the heading "Remote Access Service" with the information following:

The distinctions between RAS and remote control solutions (such as Cubix and pcANYWHERE) are important:

RAS is a software-based multi-protocol router; remote control solutions work by sharing screen, keyboard, and mouse over the remote link.

In a remote control solution, users share a CPU or multiple CPUs on the server. The RAS server's CPU is dedicated to communications, not to running applications.

Replace the entire section under the heading "Point-to-Point Tunneling Protocol" with the information following:

A RAS server is usually connected to a PSTN, ISDN, or X.25 network, allowing remote users to access a server through these networks. RAS now allows remote users access through the Internet by using the new Point-to-Point Tunneling Protocol (PPTP).

PPTP is a new networking technology that supports multiprotocol virtual private networks (VPNs), enabling remote users to access corporate networks securely across the Internet by dialing into an Internet Service Provider (ISP) or by connecting directly to the Internet. For more information, see the Microsoft Windows NT Server Networking Supplement, Chapter 11, "Point-to-Point Tunneling Protocol (PPTP)."

Chapter 2, "Network Security and Domain Planning," In the first sentence under the heading "Using a RAS-connected BDC as a PDC," replace the words "dial-out-only RAS client" with the words "dial-up networking client." In the next sentence, replace the words "RAS-connected client" with the words "dial-up networking client."

Chapter 5, "Network Services: Enterprise Level"

Replace the heading in the middle of the page, "Windows 95 Clients to Windows NT servers," with the heading "Windows 95 Clients Authenticating to Windows NT Servers."

In the next to last paragraph, change the reference "Windows NT Server Services for Macintosh" to "Windows NT Server Networking Supplement."

In the first paragraph under the heading "Secure Access to Corporate Networks over the Internet," in the first line, delete the word "a" that precedes "PPTP" and the word "driver" that follows "PPTP." Also, in the first line, change the word "driver" that follows the word "WAN" to "protocol." The amended first line reads "A RAS client that has PPTP as its WAN protocol can access resources on a remote LAN by connecting to a Windows NT RAS server through the Internet." In the second line of the second paragraph, delete the word "The" that precedes the word "PPTP" and the word "driver" that follows "PPTP."

Under the heading "Installing PPTP," replace the first sentence with "You must have the PPTP protocol installed on the RAS servers and on the client or communications servers." Change Step 4 of the procedure "To Install PPTP" to "Select Point-to-Point Protocol, and then click Add." Change Step 8 to "RAS setup will start and add the PPTP protocol to RAS." Also, delete "DNS" from the sentence following the procedure.

Chapter 6, "TCP/IP Implementation Details"

Delete the second bulleted item "Point-Point Tunneling Protocol (PPTP)."

In the first paragraph, second line, replace "RAS clients" with "dial-up networking clients." In the second paragraph, fifth line, replace "RAS client" with "dial-up networking client." Replace the heading "RAS Clients" with "Dial-Up Clients." In the paragraph before the paragraph introducing the route table, last sentence, change "Windows NT workstation" to "computer running Windows NT Workstation or Windows NT Server."

Chapter 8, "Managing Microsoft WINS Servers," remove the two paragraphs following Table 8.10.

Chapter 9, "Managing Microsoft DNS Servers"

Change the World Wide Web address for the Internet Network Information Center (InterNIC) from (http://www.internic.com) to (http://www.internic.net).

Add the following line to the end of the first Note: "This is done to support BIND versions earlier than BIND version 4.94."

Change the heading "Cache Files" to "Cache File."

Fifth paragraph, replace "DSN" in the next to the last line of the paragraph with "DNS."

First paragraph, last sentence, delete the word "Microsoft" preceding DHCP. In Step 5 of the procedure on that page, delete the sentence "Unresolved host name queries will then be passed to a DNS server."

In the procedure "To clear the Microsoft DNS server statistics by using the dnsstat command," in Step 2, change "dnstat" to "dnsstat"

Change the heading near the bottom of the page from "Zone Wizard Did Not Correctly Autocreate SOA, NS or a Record" to "Zone Wizard Did Not Correctly Autocreate SOA, NS, or A Record."


Changes at Terra Flora

Terra Flora was introduced as a fictitious corporation to provide a case study in interoperating heterogeneous networks. Chapter 4, "Terra Flora: A Fictitious Case Study," provided the history of the corporation and presented the plan for interoperability. Chapter 5, "Network Services: Enterprise Level," provided the business justification for selecting Windows NT Server services to interoperate the heterogeneous networks. It also presented specific information on the installation and configuration of Enterprise level services that support the network itself and keep the corporation-wide information synchronized.

Once the networks were interoperating, the network administrators began evaluating the potential for network failure. That evaluation process produced changes to the Terra Flora network diagram. The changes to the network diagram are as follows:

Chapter 5, "Network Services: Enterprise Level," in the figure, remove all the Integrated Services Digital Network (ISDN) communication connections except the ISDN link from server EUNTS40DPT01. Replace the T1 communication line going into and out of the server NENTS40ENT02 with two fractional T1 communication lines. Replace the T1 communication line going into and out of server EUNTS40ENT01 with two fractional T1 communication lines. Replace the communication line going into server NENTS40DPT01 with two switched 56 communication lines.

Appendix F, "Routers and Switches," in Figure F.3, remove all the ISDN communications connections. Add a backup router to network router CABNR10ENT02. Replace the T1 communication line, 1.54 megabits per second (Mbps), connecting the Enterprise router to Boston and on to New York with two fractional T1 communication lines, 128 kilobits per second (Kbps). Replace the switched 56 communications line, 56 Kbps, connecting the NENTS40DIV01 server to the Department with two switched 56 communication lines, 56 Kbps. Replace the T1 communication line, 1.54 Kbps, connecting the Enterprise router to Amsterdam and on to London with two fractional T1 communication lines, 64 Kbps.

Back cover, "Terra Flora Network Diagram"

Remove the ISDN connections to the servers NENTS40ENT01, EUNTS40ENT01, and NENTS40DPT02. Remove the ISDN connection to the network routers CABNR10ENT01 and CABNR10ENT02.

Replace the ISDN communication line from the network router CABNR10ENT01 to the Disaster Recovery Site with Backup Network Link, T1.

Add a backup router to the network router CABNR10ENT02.

Replace the T3 communication line, 45 Mbps, between the routers CABNR10ENT01 and CABNR10ENT02 with two T1 communication lines, 1.45 Mbps.

Replace the T1 communication line, 1.54 Mbps, connecting the Enterprise router CABNR10ENT02 to Boston and on to New York with two fractional T1 communication lines, 128 Kbps. Replace the New York leased line, 128 Kbps, with two fractional T1 communication lines, 128 Kbps.

Replace the switched 56 communications line, 56 Kbps, connecting the NENTS40DIV01 server to the NENTS40DPT01 server with two switched 56 communication lines, 56 Kbps.

Replace the T1 communication line, 1.54 Kbps, connecting the Enterprise router CABNR10ENT02 to Amsterdam and on to London with two fractional T1 communication lines, 64 Kbps.


Windows NT Server Internet Guide

The following changes were made to the Windows NT Server Internet Guide:

Chapter 1, "Internet Information Server Architecture," replace all references to Netmonitor with Network Monitor.

Chapter 7, "Internet Tools," Delete the section on Mail Server (MailSrv). The MailSrv utility no longer ships with the Windows NT Server Resource Kit.

Back cover, "Terra Flora Network Diagram"

Remove the ISDN connections to the servers NENTS40ENT01, EUNTS40ENT01, and NENTS40DPT02. Remove the ISDN connection to the network routers CABNR10ENT01 and CABNR10ENT02.

Replace the ISDN communication line from the network router CABNR10ENT01 to the Disaster Recovery Site with Backup Network Link, T1.

Add a backup router to the network router CABNR10ENT02.

Replace the T3 communication line, 45 Mbps, between the routers CABNR10ENT01 and CABNR10ENT02 with two T1 communication lines, 1.45 Mbps.

Replace the T1 communication line, 1.54 Mbps, connecting the Enterprise router CABNR10ENT02 to Boston and on to New York with two fractional T1 communication lines, 128 Kbps. Replace the New York leased line, 128 Kbps, with two fractional T1 communication lines, 128 Kbps.

Replace the switched 56 communications line, 56 Kbps, connecting the NENTS40DIV01 server to the NENTS40DPT01 server with two switched 56 communication lines, 56 Kbps.

Replace the T1 communication line, 1.54 Kbps, connecting the Enterprise router CABNR10ENT02 to Amsterdam and on to London with two fractional T1 communication lines, 64 Kbps.


Windows NT Workstation Resource Kit

The following section contains changes made to the Windows NT Workstation Resource Guide.

Chapter 5, "Windows NT 4.0 Workstation Architecture," Figure 5.3 has been changed to clarify that the Microkernel and HAL are not Windows NT Executive Services.

Chapter 7, "Printing"

Second paragraph, second sentence, add the word "job" after the first instance of the word "print."

Under the heading "Separator Page Files," second paragraph, last sentence, change the word "four" to "three."

Chapter 9, "The Art of Performance Monitoring"

In the first paragraph, replace "Ndvdm.exe" with "Ntvdm.exe"

In the first paragraph, replace "experimental" with "investigative."

Chapter 10, "About Performance Monitor"

In the first paragraph under the heading "New Counter Type," delete the phrase "but it displays a zero if the difference is negative."

In the first paragraph under "Starting and Setting Up Performance Monitor," replace "boot" with "log on."

In the last bulleted item, delete the sentence "If it is negative, they display a zero."

Delete the first bulleted item.

First paragraph, delete "running Network Monitor Agent."

The figure has been changed to clarify that the Microkernel and HAL are not Windows NT Executive Services.

Change the cross-reference under "All values for my disks are zero, but I know they are active" from "For information about Diskperf, see "Enabling the Disk Counters" in Chapter 6" to "For information on Diskperf, see "Enabling the Disk Counters" in Chapter 14, "Detecting Disk Bottlenecks."

Chapter 12, "Detecting Memory Bottlenecks," change the reference in the third bulleted item from "(as described in Chapter 7)" to "(as described in Chapter 15, "Detecting Cache Bottlenecks")."

Chapter 14, "Detecting Disk Bottlenecks"

Delete the diagram on the lower half of the page.

In the upper left hand corner of the figure, replace "ide.log" with "100."

First paragraph of the last bulleted item, replace the word "turbulence" with "interference." In the last sentence of that paragraph, add the word "length" after the word "cable." In the second paragraph of the last bulleted item, replace all instances of "serial" with "parallel" and all instances of "parallel" with "serial."

Back cover, the figures "Windows NT 3.51 Architecture" and "Windows NT 4.0 Architecture" have been changed to clarify that the Microkernel and HAL are not Windows NT Executive Services.


Glossary

A

access control entry (ACE)

An entry in an access control list (ACL). Each access control entry defines the protection or auditing to be applied to a file or other object for a specific user or group of users. See also access control list (ACL).

access control list (ACL)

The part of a security descriptor that enumerates both the protections to accessing and the auditing of that accessing that are applied to an object. The owner of an object has discretionary access control of the object and can change the object's ACL to allow or disallow others access to the object. Access control lists are ordered lists of access control entries (ACEs). There are two types of ACLs: discretionary (DACL) and system (SACL). See also access control entry (ACE); discretionary access control list (DACL); system access control list (SACL).

access permission

A rule associated with an object (usually a directory, file, or printer) to regulate which users can have access to the object and in what manner. See also user rights.

access privileges

Permissions set by Macintosh users that allow them to view and make changes to folders on a server. By setting access privileges (called permissions when set on the computer running Windows NT Server), you control which Macintosh can use folders in a volume. Services for Macintosh (SFM) translates access privileges set by Macintosh users to the equivalent Windows NT permissions.

access token (or security token)

An object that uniquely identifies a user who has logged on. An access token is attached to all the user's processes and contains the user's security ID (SID), the SIDs of any groups to which the user belongs, any permissions that the user owns, the default owner of any objects that the user's processes create, and the default access control list (ACL) to be applied to any objects that the user's processes create. See also permissions.

access violation

An attempt to carry out a memory operation that is not allowed by Windows NT memory management. This can include an invalid operation (such as writing to a read-only buffer); accessing memory beyond the limit of the current program's address space (a "length violation"); accessing a page to which the system forbids access; or accessing a page that is currently resident but dedicated to the use of an Executive component.

account

See group account; user account.

account lockout

A Windows NT Server security feature that locks a user account if a number of failed logon attempts occur within a specified amount of time, based on account policy lockout settings. (Locked accounts cannot log on.)

account policy

Controls the way passwords must be used by all user accounts of a domain or of an individual computer. Specifics include minimum password length, how often a user must change his or her password, and how often users can reuse old passwords. Account policy can be set for all user accounts in a domain when administering a domain, and for all user accounts of a single workstation or member server when administering a computer.

ACK

Short for acknowledgment. The transmission control protocol (TCP) requires that the recipient of data packets acknowledge successful receipt of data. Such acknowledgments (ACKs) generate additional network traffic, diminishing the rate at which data passes in favor of reliability. To reduce the impact on performance, most hosts send an acknowledgment for every other segment or when a specified time interval has passed.

acknowledgment

See ACK.

active

Refers to the window or icon that you are currently using or that is currently selected. Windows NT always applies the next keystroke or command you choose to the active window. If a window is active, its title bar changes color to differentiate it from other windows. If an icon is active, its label changes color. Windows or icons on the desktop that are not selected are inactive.

ActiveX™

An umbrella term for Microsoft technologies that enable developers to create interactive content for the World Wide Web.

adapter card

See network adapter.

address

Within Network Monitor, an address refers to a hexadecimal number that identifies a computer uniquely on the network.

address classes

Predefined groupings of Internet addresses, with each class defining networks of a certain size. The range of numbers that can be assigned for the first octet in the IP address is based on the address class. Class A networks (values 1 – 126) are the largest, with over 16 million hosts per network. Class B networks (128 – 191) have up to 65,534 hosts per network, and Class C networks (192 – 223) can have up to 254 hosts per network. See also octet.

address pairs

Refers to the two specific computers between which you want to monitor traffic by using Network Monitor. Up to four specific address pairs can be monitored simultaneously to capture frames from particular computers on your network. See also frame.

Address Resolution Protocol (ARP)

A network-maintenance protocol in the TCP/IP suite that provides IP address-to-MAC address resolution for IP packets. Not directly related to data transport. See also IP address; media access control (MAC); packet; Transmission Control Protocol/Internet Protocol (TCP/IP).

administrative account

An account that is a member of the Administrators local group of a computer or domain.

administrative alerts

Administrative alerts relate to server and resource use and warn about problems in areas such as security and access, user sessions, server shutdown due to power loss (when UPS is available), directory replication, and printing. When a computer generates an administrative alert, a message is sent to a predefined list of users and computers. See also Alerter service; uninterruptible power supply (UPS).

administrator

A person responsible for setting up and managing domain controllers or local computers and their user and group accounts, assigning passwords and permissions, and helping users with networking issues. To use administrative tools such as User Manager or User Manager for Domains, an administrator must be logged on as a member of the Administrators local group of the computer or domain, respectively.

Administrator privilege

One of three privilege levels you can assign to a Windows NT user account. Every user account has one of the three privilege levels (Administrator, Guest, and User). See also administrator; Guest privilege; User privilege.

Advanced RISC Computing (ARC)

ARC names are a generic method of identifying devices within the ARC environment. See also reduced instruction set computing (RISC).

agent

In SNMP, agent information consists of comments about the user, the physical location of the computer, and the types of service to report based on the computer's configuration. See also Simple Network Management Protocol (SNMP).

Alerter service

Notifies selected users and computers of administrative alerts that occur on a computer. Used by the Server service and other services. Requires the Messenger service. See also administrative alerts; Messenger service.

anonymous-level security token

The type of security token used when a server impersonates a client. If, when the client calls the server, the client specifies an anonymous impersonation mode, the server cannot access any of the client's identification information, such as its security identifier (SID) or privileges. The server will have to use an anonymous-level security token when representing the client in successive operations. See also access token.

Anonymous user

A connection for which the request either did not contain a user name and password or whose user name and password were ignored because authentication is not permitted on the server.

API

See application programming interface.

AppleShare

Client software that is shipped with each Macintosh and with Apple Computer server software. With Services for Macintosh, a Macintosh use its native AppleShare client software to connect to computers running Windows NT Server that have Services for Macintosh.

AppleTalk

Apple Computer network architecture and network protocols. A network that has Macintosh clients and a computer running Windows NT Server with Services for Macintosh functions as an AppleTalk network.

AppleTalk Filing Protocol

The presentation layer protocol that manages access of remote files in an AppleTalk network.

AppleTalk Phase 2

The extended AppleTalk Internet model designed by Apple Computer. It supports multiple zones within a network and extended addressing capacity.

AppleTalk Protocol

The set of network protocols on which AppleTalk network architecture is based. Setting up Services for Macintosh installs its AppleTalk Protocol stack on a computer running Windows NT Server so that Macintosh clients can connect to it.

AppleTalk Transport

The layer of AppleTalk Phase 2 protocols that deliver data to its destination on the network.

application

A computer program used for a particular kind of work, such as word processing. This term is often used interchangeably with "program."

application log

The application log contains specific events logged by applications. Applications developers decide which events to monitor (for example, a database program might record a file error in the application log). Use Event Viewer to view the application log.

application programming interface (API)

A set of routines that an application program uses to request and carry out lower-level services performed by another component, such as the computer's operating system or a service running on a network computer. These maintenance chores are performed by the computer's operating system, and an API provides the program with a means of communicating with the system, telling it which system-level task to perform and when.

application window

The main window for an application, which contains the application's menu bar and work area. An application window may contain multiple document windows.

ARC

See Advanced RISC Computing.

archive bit

Backup programs use the archive bit to mark the files after backing them up, if a normal or incremental backup is performed. See also backup types.

ARP

See Address Resolution Protocol.

ARP reply packet

All ARP-enabled systems on the local IP network detect ARP request packets, and the system that owns the IP address in question replies by sending its physical address to the requester in an ARP reply packet. The physical/IP address is then stored in the ARP cache of the requesting system for subsequent use. See also Address Resolution Protocol (ARP); ARP request packet; Internet Protocol (IP); MAC address.

ARP request packet

If two systems are to communicate across a TCP/IP network, the system sending the packet must map the IP address of the final destination to the physical address of the final destination. This physical address is also referred to as a MAC address, a unique 48-bit number assigned to the network interface card by the manufacturer. IP acquires this physical address by broadcasting a special inquiry packet (an ARP request packet) containing the IP address of the destination system. See also Address Resolution Protocol (ARP); Internet Protocol (IP); MAC address; media access control (MAC).

AS/400

A type of IBM minicomputer.

ASCII file

Also called a text file, a text-only file, or an ASCII text file, refers to a file in the universally recognized text format called ASCII (American Standard Code for Information Interchange). An ASCII file contains characters, spaces, punctuation, carriage returns, and sometimes tabs and an end-of-file marker, but it contains no formatting information. This generic format is useful for transferring files between programs that could not otherwise understand each other's documents. See also text file.

associate

To identify a filename extension as "belonging" to a certain application so that when you open any file with that extension, the application starts automatically.

attributes

Information that indicates whether a file is a read-only, hidden, system, or compressed file, and whether the file has been changed since a backup copy of it was made.

A-type resource record

A line (record) in a computer's Domain Name System database that maps a computer's domain name (host name) to an IP address in a DNS zone.

auditing

Tracking activities of users by recording selected types of events in the security log of a server or a workstation.

audit policy

For the servers of a domain or for an individual computer, defines the type of security events that will be logged.

authentication

Validation of a user's logon information. When a user logs on to an account on a computer running Windows NT Workstation, the authentication is performed by that workstation. When a user logs on to an account on a Windows NT Server domain, authentication may be performed by any server of that domain. See also Basic (clear-text) authentication; challenge/response authentication; server; trust relationship.

B

backup domain controller (BDC)

In a Windows NT Server domain, a computer running Windows NT Server that receives a copy of the domain's directory database, which contains all account and security policy information for the domain. The copy is synchronized periodically and automatically with the master copy on the primary domain controller (PDC). BDCs also authenticate user logons and can be promoted to function as PDCs as needed. Multiple BDCs can exist on a domain. See also member server; primary domain controller (PDC).

backup set

A collection of files from one drive that is backed up during a single backup operation.

backup set catalog

At the end of each backup set, Windows NT Backup stores a summary of file and/or directory information in a backup set catalog. Catalog information includes the number of tapes in a set of tapes as well as the date they were created and the dates of each file in the catalog. Catalogs are created for each backup set and are stored on the last tape in the set. See also backup set.

backup set map

At the end of each tape used for backup, a backup set map maintains the exact tape location of the backup set's data and catalog.

backup types:

copy backup

Copies all selected files, but does not mark each file as having been backed up. Copying is useful if you want to back up files between normal and incremental backups, because copying will not invalidate these other backup operations.

daily backup

Copies all selected files that have been modified the day the daily backup is performed.

differential backup

Copies those files created or changed since the last normal (or incremental) backup. It does not mark files as having been backed up.

incremental backup

Backs up only those files created or changed since the last normal (or incremental) backup. It marks files as having been backed up.

normal backup

Copies all selected files and marks each as having been backed up. Normal backups give you the ability to restore files quickly because files on the last tape are the most current.

bandwidth

In communications, the difference between the highest and lowest frequencies in a given range. For example, a telephone line accommodates a bandwidth of 3000 Hz, the difference between the lowest (300 Hz) and highest (3300 Hz) frequencies it can carry. In computer networks, greater bandwidth indicates faster data-transfer capability and is expressed in bits per second (bps). Also known as "throughput."

Bandwidth Throttler

A feature of the IIS services that enforces a limit on the amount of bandwidth available to the IIS services. This limit applies to the sum of bandwidth used by all three IIS services. Administrators can enable the Bandwidth Throttler and set a bandwidth limit by using the Microsoft Internet Service Manager.

Basic (clear-text) authentication

A method of authentication that encodes user name and password data transmissions. Basic authentication is called "clear text" because the base-64 encoding can be decoded by anyone with a freely available decoding utility. Note that encoding is not the same as encryption. See also challenge/response authentication; encryption.

batch program

An ASCII file (unformatted text file) that contains one or more Windows NT commands. A batch program's filename has a .cmd or .bat extension. When you type the filename at the command prompt, the commands are processed sequentially.

batch queue facility

A program that effects a logon without user input, used for delayed logons.

BDC

See backup domain controller.

binary

A base-2 number system, in which values are expressed as combinations of two digits, 0
and 1.

binary-file transfer

A method of transferring binary files from Windows NT HyperTerminal to a remote computer. Binary files consist of ASCII characters plus the extended ASCII character set. These files are not converted or translated during the transfer process. See also ASCII file.

binding

A process that establishes the communication channel between a protocol driver (such as TCP/IP) and a network adapter. See also network adapter; Transmission Control Protocol/Internet Protocol (TCP/IP).

bits per second (bps)

A measure of the speed at which a device, such as a modem, can transfer data.

blue screen

The screen displayed when Windows NT encounters a serious error.

bookmarks

A Windows NT feature that enables you to highlight major points of interest at various points in a Performance Monitor log file and then return to them easily when you work with that log file later on during performance monitoring. Bookmarks are also used in other applications, such as Microsoft Word.

boot loader

Defines the information needed for system startup, such as the location for the operating system's files. Windows NT automatically creates the correct configuration and checks this information whenever you start your system.

BOOTP

See Bootstrap protocol.

boot partition

The volume, formatted for either an NTFS or FAT file system, that contains the Windows NT operating system and its support files. The boot partition can be (but does not have to be) the same as the system partition. See also file allocation table (FAT); partition; Windows NT file system (NTFS).

Bootstrap protocol (BOOTP)

A TCP/IP network protocol, defined by RFC 951 and RFC 1542, used to configure systems. DHCP is an extension of BOOTP. See also Dynamic Host Configuration Protocol (DHCP).

bps

See bits per second.

branch

A segment of the directory tree, representing a directory (or folder) and any subdirectories (or folders within folders) it contains.

bridge

Connects multiple networks, subnets, or rings into one large logical network. A bridge maintains a table of node addresses and, based on this, forwards packets to a specific subnet, reducing traffic on other subnets. In a bridged network, there can be only one path to any destination (otherwise packets would circle the network, causing network storms). A bridge is more sophisticated than a repeater, but not as sophisticated as a router. See also packet; repeaters; router; subnet.

broadcast datagram

An IP datagram sent to all hosts on the subnet. See also datagram; Internet Protocol (IP); subnet.

broadcast message

A network message sent from a single computer that is distributed to all other devices on the same segment of the network as the sending computer.

broadcast name resolution

A mechanism defined in RFC 1001/1002 that uses broadcasts to resolve names to IP addresses through a process of registration, resolution, and name release. See also broadcast datagram; IP address.

brouter

Combines elements of the bridge and the router. Usually, a brouter acts as a router for one transport protocol (such as TCP/IP), sending packets of that format along detailed routes to their destinations. The brouter also acts as a bridge for all other types of packets (such as IPX), just passing them on, as long as they are not local to the LAN segment from which they originated. See also bridge; packet; router.

browse

To view available network resources by looking through lists of folders, files, user accounts, groups, domains, or computers. Browsing allows users on a Windows NT network to see what domains and computers are accessible from their local computer. See also Windows NT browser system.

browse list

A list kept by the master browser of all of the servers and domains on the network. This list is available to any workstation on the network requesting it. See also browse.

browse master

See master browser; Windows NT browser system.

buffer

A reserved portion of memory in which data is temporarily held pending an opportunity to complete its transfer to or from a storage device or another location in memory. Some devices, such as printers or the adapters supporting them, commonly have their own buffers. See also memory.

built-in groups

Default groups, provided with Windows NT Workstation and Windows NT Server, that have been granted useful collections of rights and built-in abilities. In most cases, a built-in group provides all the capabilities needed by a particular user. For example, if a domain user account belongs to the built-in Administrators group, logging on with that account gives a user administrative capabilities over the domain and the servers of the domain. To provide a needed set of capabilities to a user account, assign it to the appropriate built-in group. See also group; User Manager; User Manager for Domains.

bulk data encryption

The encryption of all data sent over a network.

C

cache

A special memory subsystem that stores the contents of frequently accessed RAM locations and the addresses where these data items are stored. In Windows NT, for example, user profiles have a locally cached copy of part of the Registry.

caching

In DNS name resolution, caching refers to a local cache where information about the DNS domain name space is kept. Whenever a resolver request arrives, the local name server checks both its static information and the cache for the name to IP address mapping. See also Domain Name System (DNS); IP address; mapping.

Callback Control Protocol (CBCP)

A protocol that negotiates callback information with a remote client.

capture

The process by which Network Monitor copies frames. (A frame is information that has been divided into smaller pieces by the network software prior to transmission.) See also frame.

capture buffer

A reserved, resizable storage area in memory where Network Monitor copies all frames it detects from the network. When the capture buffer overflows, each new frame replaces the oldest frame in the buffer.

capture filter

Functions like a database query to single out a subset of frames to be monitored in Network Monitor. You can filter on the basis of source and destination addresses, protocols, protocol properties, or by specifying a pattern offset. See also capture; frame.

capture password

Required to be able to capture statistics from the network and to display captured data using Network Monitor.

capture trigger

Performs a specified action (such as starting an executable file) when Network Monitor detects a particular set of conditions on the network.

catalog

See backup set catalog.

CBCP

See Callback Control Protocol.

CCP

See Compression Control Protocol.

centralized network administration

A centralized view of the entire network from any workstation on the network that provides the ability to track and manage information on users, groups, and resources in a distributed network.

CGI

See Common Gateway Interface.

Challenge Handshake Authentication Protocol (CHAP)

A protocol used by Microsoft RAS to negotiate the most secure form of encrypted authentication supported by both server and client. See also encryption.

challenge/response authentication

A method of authentication in which a server uses challenge/response algorithms and Windows NT security to control access to resources. See also Basic (clear-text) authentication; encryption.

change log

An inventory of the most recent changes made to the directory database such as new or changed passwords, new or changed user and group accounts, and any changes to associated group memberships and user rights. Change logs provide fault tolerance, so if your system crashes before a write completes, Windows NT can complete the write the next time you boot. This log holds only a certain number of changes, however, so when a new change is added, the oldest change is deleted. See also directory database; fault tolerance.

CHAP

See Challenge Handshake Authentication Protocol.

check box

A small box in a dialog box or property page that can be selected or cleared. Check boxes represent an option that you can turn on or off. When a check box is selected, an X or a check mark appears in the box.

checksum

The mathematical computation used to verify the accuracy of data in TCP/IP packets. See also packet; Transmission Control Protocol/Internet Protocol (TCP/IP).

choose

To pick an item that begins an action in Windows NT. You often click a command on a menu to perform a task, and you click an icon to start an application.

Chooser

The Macintosh desk accessory with which users select the network server and printers they want to use.

Chooser Pack

A collection of files, some of which contain PostScript information. When a Macintosh sends a print job to a PostScript printer, the printer uses a Chooser Pack to interpret PostScript commands in the print job. See PostScript printer; print processor.

circular dependency

A dependency in which an action that appears later in a chain is contingent upon an earlier action. For example, three services (A, B, and C) are linked. A is dependent upon B to start. B is dependent upon C to start. A circular dependency results when C is dependent upon A to start. See also dependency.

clear

To turn off an option by removing the X or check mark from a check box. To clear a check box, you can click it, or you can select it and then press the spacebar.

clear-text authentication

See Basic (clear-text) authentication.

clear-text passwords

Passwords that are not scrambled, thus making them more susceptible to network sniffers. See also network sniffer.

click

To press and release a mouse button quickly.

client

A computer that accesses shared network resources provided by another computer, called a server. See also server; workstation.

client application

A Windows NT application that can display and store linked or embedded objects. For distributed applications, the application that imitates a request to a server application. See also DCOM Configuration tool; Distributed Component Object Module (DCOM); server application.

Client Service for NetWare

Included with Windows NT Workstation, enabling workstations to make direct connections to file and printer resources at NetWare servers running NetWare 2.x or later.

Clipboard

A temporary storage area in memory, used to transfer information. You can cut or copy information onto the Clipboard and then paste it into another document or application.

close

Remove a window or dialog box, or quit an application. To close a window, you can click Close on the Control menu, or you can click the close button icon in the upper right corner of the dialog box. When you close an application window, you quit the application.

collapse

To hide additional directory levels below a selected directory in the directory tree.

color scheme

A combination of complementary colors for screen elements.

command

A word or phrase, usually found on a menu, that you click to carry out an action. You click a command on a menu or type a command at the Windows NT command prompt. You can also type a command in the Run dialog box, which you open by clicking Run on the Start menu.

command button

A button in a dialog box that carries out or cancels the selected action. Two common command buttons are OK and Cancel. If you click a command button that contains an ellipsis (for example, Browse... ), another dialog box appears.

Common Gateway Interface (CGI)

A standard interface for HTTP server application development. The standard was developed by the National Center for Supercomputing Applications.

common group

Common groups appear in the program list on the Start menu for all users who log on to the computer. Only Administrators can create or change common groups.

communications settings

Settings that specify how information is transferred from your computer to a device (usually a printer or modem).

community names

A group of hosts to which a server belongs that is running the SNMP service. The community name is placed in the SNMP packet when the trap is sent. Typically, all hosts belong to Public, which is the standard name for the common community of all hosts. See also packet; Simple Network Management Protocol (SNMP); trap.

compact

A command-line utility used to compress files on NTFS volumes. To see command line options, type compact /? at the command prompt. To access this utility, you can also right-click any file or directory on an NTFS volume in Windows NT Explorer, then click Properties to compress or uncompress the files.

compound device

A device that plays specific media files. For example, to run a compound device such as a MIDI sequencer, you must specify a MIDI file.

Compression Control Protocol (CCP)

A protocol that negotiates compression with a remote client.

computer account

Each computer running Windows NT Workstation and Windows NT Server that participates in a domain has its own account in the directory database. A computer account is created when the computer is first identified to the domain during network setup at installation time.

Computer Browser service

Maintains an up-to-date list of computers, and provides the list to applications when requested. Provides the computer lists displayed in the Network Neighborhood, Select Computer, and Select Domain dialog boxes; and (for Windows NT Server only) in the Server Manager window.

computer name

A unique name of up to 15 uppercase characters that identifies a computer to the network. The name cannot be the same as any other computer or domain name in the network.

configure

To change the initial setup of a client, a Macintosh-accessible volume, a server, or a network.

connect

To assign a drive letter, port, or computer name to a shared resource so that you can use it with Windows NT.

connected user

A user accessing a computer or a resource across the network.

connection

A software link between a client and a shared resource such as a printer or a shared directory on a server. Connections require a network adapter or modem.

connection-oriented protocol

A network protocol with four important characteristics: the path for data packets is established in advance; the resources required for a connection are reserved in advance; a connection's resource reservation is enforced throughout the life of that connection; and when a connection's data transfer is completed, the connection is terminated and the allocated resources are freed.

control codes

Codes that specify terminal commands or formatting instructions (such as linefeeds or carriage returns) in a text file. Control codes are usually preceded by a caret (^).

controller

See backup domain controller (BDC); primary domain controller (PDC).

Control menu

See window menu.

control set

All Windows NT startup-related data that is not computed during startup is saved in a Registry key. This startup data is organized into control sets, each of which contains a complete set of parameters for starting up devices and services. The Registry always contains at least two control sets, each of which contains information about all the configurable options for the computer: the current control set and the LastKnownGood control set. See also current control set; LastKnownGood (LKG) control set.

conventional memory

Up to the first 640K of memory in your computer. MS-DOS uses this memory to run applications.

CRC

See cyclic redundancy check.

current control set

The control set that was used most recently to start the computer and that contains any changes made to the startup information during the current session. See also LastKnownGood (LKG) control set.

current directory

The directory that you are currently working in. Also called "current folder."

cyclic redundancy check (CRC)

A procedure used on disk drives to ensure that the data written to a sector is read correctly later. This procedure is also used in checking for errors in data transmission.

The procedure is known as a redundancy check because each data transmission includes not only data but extra (redundant) error-checking values. The sending device generates a number based on the data to be transmitted and sends its result along with the data to the receiving device. The receiving device repeats the same calculation after transmission. If both devices obtain the same result, it is assumed that the transmission is error-free.

D

DACL

See discretionary access control list; see also system access control list (SACL).

daemon

A networking program that runs in the background.

database query

The process of extracting data from a database and presenting it for use.

data carrier

In communications, either a specified frequency that can be modulated to convey information or a company that provides telephone and other communications services to consumers.

Data Carrier Detect (DCD)

Tracks the presence of a data carrier. See also data carrier.

data communications equipment (DCE)

An elaborate worldwide network of packet-forwarding nodes that participate in delivering an X.25 packet to its designated address, for example, a modem. See also node; packet; X.25.

Data Encryption Standard (DES)

A type of encryption (the U.S. government standard) designed to protect against password discovery and playback. Microsoft RAS uses DES encryption when both the client and the server are using RAS.

data fork

The part of a Macintosh file that holds most of the file's information. The data fork is the part of the file shared between Macintosh and PC clients.

datagram

A packet of data and other delivery information that is routed through a packet-switched network or transmitted on a local area network. See also packet.

Data Source Name (DSN)

The logical name used by ODBC to refer to the drive and other information required to access data. The name is use by Internet Information Server for a connection to an ODBC data source, such as a SQL Server database. To set this name, use ODBC in the Control Panel.

data stream

Windows NT Network Monitor monitors the network data stream, which consists of all information transferred over a network at any given time.

Data Terminal Equipment (DTE)

For example, a RAS server or client. See also Remote Access Service (RAS).

dbWeb Administrator

The graphical user tool for Microsoft dbWeb that allows an administrator to create definition templates referred to as schemas. Schemas control how and what information from a private database is available to visitors who use the Internet to access the public Microsoft dbWeb gateway to the private database. See also schemas.

DCD

See Data Carrier Detect.

DCE

See data communications equipment.

DCOM

See Distributed Component Object Model.

DCOM Configuration tool

A Windows NT Server utility that can be used to configure 32-bit applications for DCOM communication over the network. See also Distributed Component Object Model (DCOM).

DDE

See dynamic data exchange.

deadlock condition

A run-time error condition that occurs when two threads of execution are blocked, each waiting to acquire a resource that the other holds, and both unable to continue running.

decision tree

A geographical representation of a filter's logic used by Windows NT Network Monitor. When you include or exclude information from your capture specifications, the decision tree reflects these specifications.

default button

In some dialog boxes, the command button that is selected or highlighted when the dialog box is initially displayed. The default button has a bold border, indicating that it will be chosen automatically if you press enter. To override a default button, you can click Cancel or another command button.

default gateway

In TCP/IP, the intermediate network device on the local network that has knowledge of the network IDs of the other networks in the Internet, so it can forward the packets to other gateways until the packet is eventually delivered to a gateway connected to the specified destination. See also gateway; network ID; packet.

default network

In the Macintosh environment, this refers to the physical network on which a server's processes reside as nodes and on which the server appears to users. A server's default network must be one to which that server is attached. Only servers on AppleTalk Phase 2 internets have default networks.

default owner

The person assigned ownership of a folder on the server when the account of the folder or volume's previous owner expires or is deleted. Each server has one default owner; you can specify the owner.

default printer

The printer that is used if you choose the Print command without first specifying which printer you want to use with an application. You can have only one default printer; it should be the printer you use most often.

default profile

See system default profile; user default profile.

default user

Every user profile begins as a copy of default user, a default user profile stored on each computer running Windows NT Workstation or Windows NT Server.

default zone

The zone to which all Macintosh clients on the network are assigned by default.

dependency

A situation in which one action must take place before another can happen. For example, if action A does not occur, then action D cannot occur. Some Windows NT drivers have dependencies on other drivers or groups of drivers. For example, driver A will not load unless some driver from the G group loads first. See also circular dependency.

dependent service

A service that requires support of another service. For example, the Alerter service is dependent on the Messenger service. See also Alerter service; Messenger service.

DES

See Data Encryption Standard.

descendent key

All the subkeys that appear when a key in the Registry is expanded. A descendent key is the same thing as a subkey. See also key; Registry; subkey.

desired zone

The zone in which Services for Macintosh appears on the network. See also default zone.

desktop

The background of your screen, on which windows, icons, and dialog boxes appear.

desktop pattern

A design that appears across your desktop. You can create your own pattern or select a pattern provided by Windows NT.

destination directory

The directory to which you intend to copy or move one or more files.

destination document

The document into which a package or a linked or embedded object is being inserted. For an embedded object, this is sometimes also called the container document. See also embedded object; linked object; package.

device

Any piece of equipment that can be attached to a network — for example, a computer, a printer, or any other peripheral equipment.

device contention

The way Windows NT allocates access to peripheral devices, such as modems or printers, when more than one application is trying to use the same device.

device driver

A program that enables a specific piece of hardware (device) to communicate with Windows NT. Although a device may be installed on your system, Windows NT cannot recognize the device until you have installed and configured the appropriate driver. If a device is listed in the Hardware Compatibility List, a driver is usually included with Windows NT. Drivers are installed when you run the Setup program (for a manufacturer's supplied driver) or by using Devices in Control Panel. See also Hardware Compatibility List (HCL).

DHCP

See Dynamic Host Configuration Protocol.

DHCP Relay Agent

The component responsible for relaying DHCP and BOOTP broadcast messages between a DHCP server and a client across an IP router. See also Bootstrap protocol (BOOTP); Dynamic Host Configuration Protocol (DHCP).

dialog box

A window that is displayed to request or supply information. Many dialog boxes have options you must select before Windows NT can carry out a command.

dial-up line

A standard dial-up connection such as telephone and ISDN lines.

dial-up networking

The client version of Windows NT Remote Access Service (RAS), enabling users to connect to remote networks.

directory

Part of a structure for organizing your files on a disk, a directory (also called a folder) is represented by the folder icon in Windows NT, Windows 95, and on Macintosh computers. A directory can contain files and other directories, called subdirectories or folders within folders.

With Services for Macintosh, directories on the computer running Windows NT Server appear to Macintosh users as volumes and folders if they are designated as Macintosh accessible.

See also directory tree; folder.

directory database

A database of security information such as user account names and passwords, and the security policy settings. For Windows NT Workstation, the directory database is managed by using User Manager. For a Windows NT Server domain, it is managed by using User Manager for Domains. (Other Windows NT documents may refer to the directory database as the "Security Accounts Manager (SAM) database.") See also Windows NT Server Directory Services.

directory replication

The copying of a master set of directories from a server (called an export server) to specified servers or workstations (called import computers) in the same or other domains. Replication simplifies the task of maintaining identical sets of directories and files on multiple computers, because only a single master copy of the data must be maintained. Files are replicated when they are added to an exported directory and every time a change is saved to the file. See also Directory Replicator service.

Directory Replicator service

Replicates directories, and the files in those directories, between computers. See also directory replication.

Directory Service Manager for NetWare (DSMN)

A component of Windows NT Server. Enables network administrators to add NetWare servers to Windows NT Server domains and to manage a single set of user and group accounts that are valid at multiple servers running either Windows NT Server or NetWare.

directory services

See Windows NT Server Directory Services.

directory tree

A graphical display of a disk's directory hierarchy. The directories and folders on the disk are shown as a branching structure. The top-level directory is the root directory.

disabled user account

A user account that does not permit logons. The account appears in the user account list of the User Manager or User Manager for Domains window and can be re-enabled at any time. See also user account.

discovery

A process by which the Windows NT Net Logon service attempts to locate a domain controller running Windows NT Server in the trusted domain. Once a domain controller has been discovered, it is used for subsequent user account authentication.

discretionary access control

Allows the network administrator to allow some users to connect to a resource or perform an action while preventing other users from doing so. See also discretionary access control list (DACL); system access control list (SACL).

discretionary access control list (DACL)

The discretionary ACL is controlled by the owner of an object and specifies the access particular users or groups can have to that object. See also system access control list (SACL).

disjoint networks

Networks that are not connected to each other.

disk configuration information

The Windows NT Registry includes the following information on the configuration of your disk(s): assigned drive letters, stripe sets, mirror sets, volume sets, and stripe sets with parity. Disk configuration can be changed by using Disk Administrator. If you choose to create an Emergency Repair disk, disk configuration information will be stored there, as well as in the Registry.

display filter

Functions like a database query, allowing you to single out specific types of information. Because a display filter operates on data that has already been captured, it does not affect the contents of the Network Monitor capture buffer. See also capture buffer.

display password

Required to be able to open previously saved capture (.cap) files in Network Monitor.

Distributed Component Object Model (DCOM)

Use the DCOM Configuration tool to integrate client/server applications across multiple computers. DCOM can also be used to integrate robust Web browser applications. See also DCOM Configuration tool.

distributed server system

In Windows NT, a system in which individual departments or workgroups set up and maintain their own remote access domains.

DLL

See dynamic-link library.

DNS

See Domain Name System.

DNS name servers

In the DNS client/server model, the servers containing information about a portion of the DNS database, which makes computer names available to client resolvers querying for name resolution across the Internet. See also Domain Name System (DNS).

DNS service

The service that provides domain name resolution. See also DNS name servers.

document

A self-contained file created with an application and, if saved on disk, given a unique filename by which it can be retrieved. A document can be a text file, a spreadsheet, or an image file, for example.

document file

A file that is associated with an application. When you open a document file, the application starts and loads the file. See also associate.

Document file icon

Represents a file that is associated with an application. When you double-click a document file icon, the application starts and loads the file. See also associate.

document icon

Located at the left of a document window title bar, the document icon represents the open document. Clicking the document icon opens the window menu. Also known as the control menu box.

domain

In Windows NT, a collection of computers, defined by the administrator of a Windows NT Server network, that share a common directory database. A domain provides access to the centralized user accounts and group accounts maintained by the domain administrator. Each domain has a unique name. See also directory database; user account; workgroup.

domain controller

In a Windows NT Server domain, refers to the computer running Windows NT Server that manages all aspects of user-domain interactions, and uses information in the directory database to authenticate users logging on to domain accounts. One shared directory database is used to store security and user account information for the entire domain. A domain has one primary domain controller (PDC) and one or more backup domain controllers (BDCs). See also backup domain controller (BDC); directory database; member server; primary domain controller (PDC).

domain database

See directory database.

domain model

A grouping of one or more domains with administration and communication links between them that are arranged for the purpose of user and resource management.

domain name

Part of the Domain Name System (DNS) naming structure, a domain name is the name by which a domain is known to the network. Domain names consist of a sequence of labels separated by periods. See also Domain Name System (DNS); fully qualified domain name (FQDN).

domain name space

The database structure used by the Domain Name System (DNS). See also Domain Name System (DNS).

Domain Name System (DNS)

Sometimes referred to as the BIND service in BSD UNIX, DNS offers a static, hierarchical name service for TCP/IP hosts. The network administrator configures the DNS with a list of host names and IP addresses, allowing users of workstations configured to query the DNS to specify remote systems by host names rather than IP addresses. For example, a workstation configured to use DNS name resolution could use the command ping remotehost rather than ping 172.16.16.235 if the mapping for the system named remotehost was contained in the DNS database. DNS domains should not be confused with Windows NT networking domains. See also IP address; ping.

domain synchronization

See synchronize.

dots per inch (DPI)

The standard used to measure print device resolution. The greater the DPI, the better the resolution.

double-click

To rapidly press and release a mouse button twice without moving the mouse. Double-clicking carries out an action, such as starting an application.

down level

A term that refers to earlier operating systems, such as Windows for Workgroups or LAN Manager, that can still interoperate with Windows NT Workstation or Windows NT Server.

downloaded fonts

Fonts that you send to your printer either before or during the printing of your documents. When you send a font to your printer, it is stored in printer memory until it is needed for printing. See also font; font types.

DPI

See dots per inch.

drag

To move an item on the screen by selecting the item and then pressing and holding down the mouse button while moving the mouse. For example, you can move a window to another location on the screen by dragging its title bar.

drive icon

An icon in the All Folders column in Windows NT Explorer or the Names Column in My Computer that represents a disk drive on your system. Different icons depict floppy disk drives, hard disk drives, network drives, RAM drives, and CD-ROM drives.

driver

See device driver.

drop folder

In the Macintosh environment this refers to a folder for which you have the Make Changes permission but not the See Files or See Folders permission. You can copy files into a drop folder, but you cannot see what files and subfolders the drop folder contains.

DSDM

Acronym for DDE share database manager. See also dynamic data exchange (DDE); Network DDE DSDM service.

DSMN

See Directory Service Manager for NetWare.

DSN

See Data Source Name.

DSR

Acronym for Data Set Ready signal, used in serial communications. A DSR is sent by a modem to the computer to which it is attached to indicate that it is ready to operate. DSRs are hardware signals sent over line 6 in RS-232-C connections.

DTE

See Data Terminal Equipment.

dual boot

A computer that can boot two different operating systems. See also multiple boot.

DWORD

A data type composed of hexadecimal data with a maximum allotted space of 4 bytes.

dynamic assignment

The automatic assignment of TCP/IP properties in a changing network.

dynamic data exchange (DDE)

A form of interprocess communication (IPC) implemented in the Microsoft Windows family of operating systems. Two or more programs that support dynamic data exchange (DDE) can exchange information and commands. See also interprocess communication (IPC).

Dynamic Host Configuration Protocol (DHCP)

A protocol that offers dynamic configuration of IP addresses and related information. DHCP provides safe, reliable, and simple TCP/IP network configuration, prevents address conflicts, and helps conserve the use of IP addresses through centralized management of address allocation. See also IP address.

dynamic-link library (DLL)

An operating system feature that allows executable routines (generally serving a specific function or set of functions) to be stored separately as files with .dll extensions and to be loaded only when needed by the program that calls them.

dynamic routing

Dynamic routing automatically updates the routing tables, reducing administrative overhead (but increasing traffic in large networks). See also routing table.

dynamic web pages

Web pages that are derived or assembled only when the client requests them. Dynamic pages are used to deliver very current information, to deliver responses to forms and queries, and to provide a customized page. They are often associated with databases, such as SQL databases. See also static web pages.

E

EISA

See Extended Industry Standard Architecture.

embedded object

Presents information, created in another application, which has been pasted inside your document. Information in the embedded object does not exist in another file outside your document.

EMS

See Expanded Memory Specification.

encapsulated PostScript (EPS) file

A file that prints at the highest possible resolution for your printer. An EPS file may print faster than other graphical representations. Some Windows NT and non-Windows NT graphical applications can import EPS files. See also font types; PostScript printer; print processor.

encryption

The process of making information indecipherable to protect it from unauthorized viewing or use, especially during transmission or when it is stored on a transportable magnetic medium.

enterprise server

Refers to the server to which multiple primary domain controllers (PDCs) in a large organization will replicate. See also primary domain controller (PDC).

environment variable

A string consisting of environment information, such as a drive, path, or filename, associated with a symbolic name that can be used by Windows NT. To define environment variables, use System in Control Panel or use the Set command from the Windows NT command prompt.

EPS

See encapsulated PostScript file.

error logging

The process by which errors that cannot readily be corrected by the majority of end users are written to a file instead of being displayed on the screen. System administrators, support technicians, and users can use this log file to monitor the condition of the hardware in a computer running Windows NT to tune the configuration of the computer for better performance, and to debug problems as they occur.

event

Any significant occurrence in the system or an application that requires users to be notified, or an entry to be added to a log.

Event Log service

Records events in the system, security, and application logs. The Event Log service is located in Event Viewer.

exception

A synchronous error condition resulting from the execution of a particular computer instruction. Exceptions can be either hardware-detected errors, such as division by zero, or software-detected errors, such as a guard-page violation.

Executive

The Executive is the part of the Windows NT operating system that runs in Kernel mode. Kernel mode is a privileged processor mode in which a thread has access to system memory and to hardware. (In contrast, User mode is a nonprivileged processor mode in which a thread can only access system resources by calling system services.) The Windows NT Executive provides process structure, thread scheduling, interprocess communication, memory management, object management, object security, interrupt processing, I/O capabilities, and networking. See also Hardware Abstraction Layer (HAL); Kernel.

Executive messages

Two types of character-mode messages occur when the Windows NT Kernel detects an inconsistent condition from which it cannot recover: STOP messages and hardware-malfunction messages.

Character-mode STOP messages are always displayed on a full character-mode screen rather than in a Windows-mode message box. They are also uniquely identified by a hexadecimal number and a symbolic string.

Character-mode hardware-malfunction messages are caused by a hardware condition detected by the processor.

The Executive displays a Windows-mode STATUS message box when it detects conditions within a process (generally, an application) that you should know about.

expand

To show hidden directory levels in the directory tree. With My Computer or Windows NT Explorer, directories that can expand have plus-sign icons which you click to expand.

expanded memory

A type of memory, up to 8 megabytes, that can be added to an 8086 or 8088 computer, or to an 80286, 80386, 80486, or Pentium computer. The use of expanded memory is defined by the Expanded Memory Specification (EMS). Note: Windows NT requires an 80486 or higher computer.

Expanded Memory Specification (EMS)

Describes a technique for adding memory to IBM PC systems. EMS bypasses the limits on the maximum amount of usable memory in a computer system by supporting memory boards containing a number of 16K banks of RAM that can be enabled or disabled by software. See also memory.

Explorer

See Windows NT Explorer.

export path

In directory replication, a path from which subdirectories, and the files in those subdirectories, are automatically exported from an export server. See also directory replication.

export server

In directory replication, a server from which a master set of directories is exported to specified servers or workstations (called import computers) in the same or other domains. See also directory replication.

Extended Industry Standard Architecture (EISA)

A 32-bit bus standard introduced in 1988 by a consortium of nine computer industry companies. EISA maintains compatibility with the earlier Industry Standard Architecture (ISA) but provides for additional features.

extended memory

Memory beyond one megabyte in 80286, 80386, 80486, and Pentium computers. Note: Windows NT requires an 80486 or higher computer.

extended partition

Created from free space on a hard disk, an extended partition can be subpartitioned into zero or more logical drives. Only one of the four partitions allowed per physical disk can be an extended partition, and no primary partition needs to be present to create an extended partition. See also free space; logical drive; primary partition.

extensible counters

Performance Monitor counters that are not installed with Windows NT. Extensible counters typically are installed independently. Extensible counters should be monitored to make certain that they are working properly.

extension

A filename extension usually indicates the type of file or directory, or the type of application associated with a file. In MS-DOS, this includes a period and up to three characters at the end of a filename. Windows NT supports long filenames, up to the filename limit of 255 characters.

extension-type association

The association of an MS-DOS filename extension with a Macintosh file type and file creator. Extension-type associations allow users of the PC and Macintosh versions of the same application to share the same data files on the server. Services for Macintosh has many predefined extension-type associations. See also name mapping.

external command

A command that is stored in its own file and loaded from disk when you use the command.

F

family set

A collection of related tapes containing several backup sets. See also backup set.

FAT

See file allocation table.

fault tolerance

Ensures data integrity when hardware failures occur. In Windows NT, fault tolerance is provided by the Ftdisk.sys driver. In Disk Administrator, fault tolerance is provided using mirror sets, stripe sets with parity, and volume sets. See also mirror set; stripe sets with parity; volume set.

FCB

See file control block.

Fiber Distributed Data Interface (FDDI)

A type of network media designed to be used with fiber-optic cabling. See also LocalTalk; Token Ring.

file

A collection of information that has been given a name and is stored on a disk. This information can be a document or an application.

file allocation table (FAT)

A table or list maintained by some operating systems to keep track of the status of various segments of disk space used for file storage. Also referred to as the FAT file system.

File and Print Services for NetWare (FPNW)

A Windows NT Server component that enables a computer running Windows NT Server to provide file and print services directly to NetWare-compatible client computers.

file control block (FCB)

A small block of memory temporarily assigned by a computer's operating system to hold information about a file that has been opened for use. An FCB typically contains such information as the file's identification, its location on disk, and a pointer that marks the user's current (or last) position in the file.

file creator

A four-character sequence that tells the Macintosh Finder the name of the application that created a file. With Services for Macintosh, you can create extension-type associations that map PC filename extensions with Macintosh file creators and file types. These associations allow both PC and Macintosh users to share the same data files on the server. See also extension-type association.

file fork

One of two subfiles of a Macintosh file. When Macintosh files are stored on a computer running Windows NT Server, each fork is stored as a separate file. Each fork can be independently opened by a Macintosh user.

filename

The name of a file. MS-DOS supports the 8.3 naming convention of up to eight characters followed by a period and a three-character extension. Windows NT supports the FAT and NTFS file systems with filenames up to 255 characters. Since MS-DOS cannot recognize long filenames, Windows NT Server automatically translates long names of files and folders to 8.3 names for MS-DOS users. See also long name; name mapping; short name.

filename extension

The characters that follow the period in a filename, following the FAT naming conventions. Filename extensions can have as many as three characters and are often used to identify the type of file and the application used to create the file (for example, spreadsheet files created by Microsoft Excel have the extension .xls). With Services for Macintosh, you can create extension-type associations that map PC filename extensions with Macintosh file creators and types.

File Replication service

A Windows NT service that allows specified file(s) to be replicated to remote systems, ensuring that copies on each system are kept in synchronization. The system that maintains the master copy is called the exporter, and the systems that receive updates are known as importers.

File Server for Macintosh service

A Services for Macintosh service that enables Macintosh clients and PC clients to share files. Also called MacFile.

file sharing

The ability for a computer running Windows NT to share parts (or all) of its local file system(s) with remote computers. An administrator creates share points by using the file sharing command in My Computer or Windows NT Explorer or by using the net share command from the command prompt.

file system

In an operating system, the overall structure in which files are named, stored, and organized. NTFS and FAT are types of file systems.

file transfer protocol (FTP)

A service supporting file transfers between local and remote systems that support this protocol. FTP supports several commands that allow bidirectional transfer of binary and ASCII files between systems. The FTP Server service is part of the Internet Information Server. The FTP client is installed with TCP/IP connectivity utilities.

file type

In the Macintosh environment, this refers to a four-character sequence that identifies the type of a Macintosh file. The file type and file creator are used by the Macintosh Finder to determine the appropriate desktop icon for that file.

find tab

Displays the words you can use to search for related topics. Use this tab to look for topics related to a particular word. It is located in the Help button bar near the top of the Help window.

firewall

A system or combination of systems that enforces a boundary between two or more networks and keeps intruders out of private networks. Firewalls serve as virtual barriers to passing packets from one network to another.

flat name space

A naming system in which computer names are created from a short sequence of characters without any additional structure superimposed.

floppy disk

A disk that can be inserted in and removed from a disk drive. Floppies are most commonly available in a 3.5 or 5.25 inch format.

flow control

An exchange of signals, over specific wires, in which each device signals its readiness to send or receive data.

folder

A grouping of files or other folders, graphically represented by a folder icon, in both the Windows NT and Macintosh environments. A folder is analogous to a PC's file system directory, and many folders are, in fact, directories. A folder may contain other folders as well as file objects. See also directory.

font

A graphic design applied to a collection of numbers, symbols, and characters. A font describes a certain typeface along with other qualities such as size, spacing, and pitch. See also font set; font types.

font set

A collection of font sizes for one font, customized for a particular display and printer. Font sets determine what text looks like on the screen and when printed. See also font.

font types:

device fonts

Reside in the hardware of your print device. They can be built into the print device itself or can be provided by a font cartridge or font card.

downloadable soft fonts

Fonts that are stored on disk and downloaded as needed to the print device.

plotter fonts

A font created by a series of dots connected by lines. Plotter fonts can be scaled to any size and are most often printed on plotters. Some dot-matrix printers also support plotter fonts.

PostScript fonts

Fonts that are defined in terms of the PostScript page-description language rules from Adobe Systems. When a document displayed in a screen font is sent to a PostScript printer, the printer uses the PostScript version if the font exists. If the font doesn't exist but a version is installed on the computer, that font is downloaded. If there is no PostScript font installed in either the printer or the computer, the bitmapped font is translated into PostScript and the printer prints text using the bitmapped font.

raster fonts

Fonts that are stored as bitmaps. If a print device does not support raster fonts, it will not print them. Raster fonts cannot be scaled or rotated.

screen fonts

Windows NT fonts that can be translated for output to the print device. Most screen fonts (including TrueType fonts) can be printed as well.

TrueType fonts

Device-independent fonts that can be reproduced on all print devices. TrueType fonts are stored as outlines and can be scaled and rotated.

vector fonts

Fonts that are useful on devices such as pen plotters that cannot reproduce bitmaps. They can be scaled to any size or aspect ratio. (See also plotter fonts, earlier in this entry.)

fork

See data fork; file fork; resource fork.

FPNW

See File and Print Services for NetWare.

FQDN

See fully qualified domain name.

frame

In synchronous communication, a package of information transmitted as a single unit from one device to another. See also capture.

Frame Relay

A synchronous High-level Data Link Control (HDLC) protocol–based network that sends data in HDLC packets. See also High-level Data Link Control (HDLC).

framing rules

Are established between a remote computer and the server, allowing continued communication (frame transfer) to occur. See also frame.

free space

Free space is an unused and unformatted portion of a hard disk that can be partitioned or subpartitioned. Free space within an extended partition is available for the creation of logical drives. Free space that is not within an extended partition is available for the creation of a partition, with a maximum of four partitions allowed per disk. See also extended partition; logical drive; primary partition.

FTP

See file transfer protocol.

full name

A user's complete name, usually consisting of the last name, first name, and middle initial. The full name is information that can be maintained by User Manager and User Manager for Domains as part of the information identifying and defining a user account. See also user account.

full-screen application

A non–Windows NT application that is displayed in the entire screen, rather than a window, when running in the Windows NT environment.

full synchronization

Occurs when a copy of the entire database directory is sent to a backup domain controller (BDC). Full synchronization is performed automatically when changes have been deleted from the change log before replication takes place, and when a new BDC is added to a domain. See also backup domain controller (BDC); directory database.

fully qualified domain name (FQDN)

Part of the TCP/IP naming convention known as the Domain Name System, DNS computer names consist of two parts: host names with their domain names appended to them. For example, a host with host name corp001 and DNS domain name trey-research.com has an FQDN of corp001.trey-research.com. (DNS domains should not be confused with Windows NT networking domains.) See also Domain Name System (DNS).

G

gateway

Describes a system connected to multiple physical TCP/IP networks, capable of routing or delivering IP packets between them. A gateway translates between different transport protocols or data formats (for example IPX and IP) and is generally added to a network primarily for its translation ability. Also referred to as an IP router. See also IP address; IP router.

Gateway Service for NetWare

Included with Windows NT Server, enables a computer running Windows NT Server to connect to NetWare servers. Creating a gateway enables computers running only Microsoft client software to access NetWare resources through the gateway. See also gateway.

General MIDI

A MIDI specification controlled by the MIDI Manufacturers Association (MMA). The specification provides guidelines that authors of MIDI files can use to create files that sound the same across a variety of different synthesizers.

global account

For Windows NT Server, a normal user account in a user's domain. Most user accounts are global accounts. If there are multiple domains in the network, it is best if each user in the network has only one user account in only one domain, and each user's access to other domains is accomplished through the establishment of domain trust relationships. See also local account; trust relationship.

global group

For Windows NT Server, a group that can be used in its own domain, member servers and workstations of the domain, and trusting domains. In all those places it can be granted rights and permissions and can become a member of local groups. However, it can only contain user accounts from its own domain. Global groups provide a way to create handy sets of users from inside the domain, available for use both in and out of the domain.

Global groups cannot be created or maintained on computers running Windows NT Workstation. However, for Windows NT Workstation computers that participate in a domain, domain global groups can be granted rights and permissions at those workstations, and can become members of local groups at those workstations. See also domain; group; local group; trust relationship.

globally unique identifier (GUID)

See universally unique identifier (UUID).

Gopher

A hierarchical system for finding and retrieving information from the Internet or an intranet. Similar to FTP, Gopher uses a menu system and enables links to other servers.

group

In User Manager or User Manager for Domains, an account containing other accounts that are called members. The permissions and rights granted to a group are also provided to its members, making groups a convenient way to grant common capabilities to collections of user accounts. For Windows NT Workstation, groups are managed with User Manager. For Windows NT Server, groups are managed with User Manager for Domains. See also built-in groups; global group; local group; user account.

group account

A collection of user accounts. Giving a user account membership in a group gives that user all the rights and permissions granted to the group. See also local account; user account.

group category

One of three categories of users to which you can assign Macintosh permissions for a folder. The permissions assigned to the group category are available to the group associated with the folder.

group memberships

The groups to which a user account belongs. Permissions and rights granted to a group are also provided to its members. In most cases, the actions a user can perform in Windows NT are determined by the group memberships of the user account the user is logged on to. See also group.

group name

A unique name identifying a local group or a global group to Windows NT. A group's name cannot be identical to any other group name or user name of its own domain or computer. See also global group; local group.

guest

Users of Services for Macintosh who do not have a user account or who do not provide a password are logged on as a guest, using a user account with guest privileges. When a Macintosh user assigns permissions to everyone, those permissions are given to the group's guests and users.

guest account

On computers running Windows NT Workstation or Windows NT Server, a built-in account used for logons by people who do not have a user account on the computer or domain or in any of the domains trusted by the computer's domain.

Guest privilege

One of three privilege levels that you can assign to a Windows NT user account. The guest account used for Macintosh guest logons must have the Guest privilege. See also Administrator privilege; user account; User privilege.

GUID

Acronym for globally unique identifier. See universally unique identifier (UUID).

H

HAL

See Hardware Abstraction Layer.

handle

A handle is a value used to uniquely identify a resource so that a program can access it.

In the Registry, each of the first-level key names begins with HKEY_ to indicate to software developers that this is a handle that can be read by a program.

handshaking

Refers to flow control in serial communication, which defines a method for the print device to tell Windows NT that its buffer is full. See also buffer.

Hardware Abstraction Layer (HAL)

A thin layer of software provided by the hardware manufacturer that hides, or abstracts, hardware differences from higher layers of the operating system.

Through the filter provided by the HAL, different types of hardware all look alike to the rest of the operating system. This allows Windows NT to be portable from one hardware platform to another. The HAL also provides routines that allow a single device driver to support the same device on all platforms.

The HAL works closely with the Kernel.

See also Executive; Kernel.

Hardware Compatibility List (HCL)

The Windows NT Hardware Compatibility List lists the devices supported by Windows NT. The latest version of the HCL can be downloaded from the Microsoft Web Page (microsoft.com) on the Internet.

HCL

See Hardware Compatibility List.

HDLC

See High-level Data Link Control.

heterogeneous environment

An internetwork with servers and workstations running different operating systems, such as Windows NT, Macintosh, or Novell NetWare, using a mix of different transport protocols.

hexadecimal

A base-16 number system that consists of the digits 0 through 9 and the uppercase and lowercase letters A (equivalent to decimal 10) through F (equivalent to decimal 15).

High-level Data Link Control (HDLC)

A protocol that governs information transfer. Under the HDLC protocol, messages are transmitted in units called frames, each of which can contain a variable amount of data but which must be organized in a particular way.

high memory area (HMA)

The first 64K of extended memory (often referred to as HMA). See also memory.

High-Performance File System (HPFS)

The file system designed for the OS/2 version 1.2 operating system.

hive

A section of the Registry that appears as a file on your hard disk. The Registry subtree is divided into hives (named for their resemblance to the cellular structure of a beehive). A hive is a discrete body of keys, subkeys, and values that is rooted at the top of the Registry hierarchy. A hive is backed by a single file and a .log file, which are in the Systemroot\System32\Config or the Systemroot\Profiles\Username folder. By default, most hive files (Default, SAM, Security, and System) are stored in the Systemroot\System32\Config folder.

The Systemroot\Profiles folder contains the user profile for each user of the computer. Because a hive is a file, it can be moved from one system to another but can only be edited by using a Registry editor.

HMA

See high memory area.

h-node

A NetBIOS implementation that uses the p-node protocol first, then the b-node protocol if the name service is unavailable. For registration, it uses the b-node protocol, then the p-node protocol. See also NetBIOS; p-node; registration.

home directory

A directory that is accessible to the user and contains files and programs for that user. A home directory can be assigned to an individual user or can be shared by many users.

home page

The initial page of information for a collection of pages. The starting point for a Web site or section of a Web site is often referred to as the home page. Individuals also post pages that are called home pages.

hop

Refers to the next router. In IP routing, packets are always forwarded one router at a time. Packets often hop from router to router before reaching their destination. See also IP address; packet; router.

host

Any device that is attached to the network and uses TCP/IP. See also Transmission Control Protocol/Internet Protocol (TCP/IP).

host group

A set of zero or more hosts identified by a single IP destination address. See also host; IP address.

host ID

The portion of the IP address that identifies a computer within a particular network ID. See also IP address; network ID.

host name

The name of a device on a network. For a device on a Windows or Windows NT network, this can be the same as the computer name, but it may not be. The host name must be in the host table or be known by a DNS server for that host to be found by another computer attempting to communicate with it. See also Domain Name System (DNS); host table.

HOSTS file

A local text file in the same format as the 4.3 Berkeley Software Distribution (BSD) UNIX \etc\hosts file. This file maps host names to IP addresses. In Windows NT, this file is stored in the \Systemroot\System32\Drivers\Etc directory. See also IP address.

host table

The HOSTS and LMHOSTS files, which contain mappings of known IP addresses mapped to host names.

HPFS

See High-Performance File System.

HTML

See Hypertext Markup Language.

HTTP

See Hypertext Transport Protocol.

HTTP keep-alives

An optimizing feature of the HTTP service. HTTP keep-alives maintain a connection even after the initial connection request is completed. This keeps the connection active and available for subsequent requests. HTTP keep-alives were implemented to avoid the substantial cost of establishing and terminating connections. Both the client and the server must support keep-alives. Keep-alives are supported by Internet Information Server version 1.0 and later and by Internet Explorer version 2.0 and later. See also TCP/IP keep-alives.

hue

The position of a color along the color spectrum. For example, green is between yellow and blue. To set this attribute, use Desktop in Control Panel.

hyperlink

A way of jumping to another place on the Internet. Hyperlinks usually appear in a different format from regular text. You initiate the jump by clicking the link.

Hypertext Markup Language (HTML)

A simple markup language used to create hypertext documents that are portable from one platform to another. HTML files are simple ASCII text files with codes embedded (indicated by markup tags) to indicate formatting and hypertext links. HTML is used for formatting documents on the World Wide Web.

Hypertext Transport Protocol (HTTP)

The underlying protocol by which WWW clients and servers communicate. HTTP is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

I

ICMP

See Internet Control Message Protocol.

icon

A graphical representation of an element in Windows NT, such as a disk drive, directory, group, application, or document. Click the icon to enlarge an application icon to a window when you want to use the application. Within applications, there are also toolbar icons for commands such as cut, copy, and paste.

IDC

See Internet Database Connector.

IDE

See integrated device electronics.

IETF

See Internet Engineering Task Force.

IGMP

See Internet Group Management Protocol.

IIS

See Internet Information Server.

IIS object cache

An area of virtual memory that the IIS process uses to store frequently used objects, such as open file handles and directory listings. The IIS object cache is part of the working set of the IIS process, Inetinfo.exe, and it can be paged to disk.

IMC

See Internet Mail Connector.

impersonation

Impersonation occurs when Windows NT Server allows one process to take on the security attributes of another.

import

To create a package by inserting an existing file into Object Packager. When you import a file, the icon of the application you used to create the file appears in the Appearance window, and the name of the file appears in the Contents window. See also package.

import computers

In directory replication, the servers or workstations that receive copies of the master set of directories from an export server. See also directory replication; export server.

import path

In directory replication, the path to which imported subdirectories, and the files in those subdirectories, will be stored on an import computer. See also directory replication; import computers.

Inetinfo

A process containing the FTP, Gopher, and HTTP services. This process is about 400K in size. In addition to the FTP, Gopher, and HTTP services, this process contains the shared thread pool, cache, logging, and SNMP services of Internet Information Server.

input/output activity (I/O)

Read or write actions that your computer performs. Your computer performs a "read" when you type information on your keyboard or you select and choose items by using your mouse. Also, when you open a file, your computer reads the disk on which the file is located to find and open it.

Your computer performs a "write" whenever it stores, sends, prints, or displays information. For example, your computer performs a write when it stores information on a disk, displays information on your screen, or sends information through a modem or to a printer. See also I/O addresses.

input/output control (IOCTL)

An IOCTL command enables a program to communicate directly with a device driver. This is done, for example, by sending a string of control information recognized by the driver. None of the information passed from the program to the device driver is sent to the device itself (in other words, the control string sent to a printer driver is not displayed on the printer).

insertion point

The place where text will be inserted when you type. The insertion point usually appears as a flashing vertical bar in an application's window or in a dialog box.

integrated device electronics (IDE)

A type of disk-drive interface in which the controller electronics reside on the drive itself, eliminating the need for a separate adapter card.

Integrated Services Digital Network (ISDN)

A type of phone line used to enhance WAN speeds, ISDN lines can transmit at speeds of 64 or 128 kilobits per second, as opposed to standard phone lines, which typically transmit at only 9600 bits per second (bps). An ISDN line must be installed by the phone company at both the server site and the remote site. See also bits per second (bps).

interactive logon

A network logon from a computer keyboard, when the user types information in the Logon Information dialog box displayed by the computer's operating system. See also remote logon.

intermediary devices

Microsoft RAS supports various kinds of intermediary devices (security hosts and switches) between the remote access client and the remote access server. These devices include a modem-pool switch or security host. See also Remote Access Service (RAS).

internal command

Commands that are stored in the file Cmd.exe and that reside in memory at all times.

internet

In Windows NT, a collection of two or more private networks, or private inter-enterprise TCP/IP networks.

In Macintosh terminology, refers to two or more physical networks connected by routers, which maintain a map of the physical networks on the internet and forward data received from one physical network to other physical networks. Network users in an internet can share information and network devices. You can use an internet with Services for Macintosh by connecting two or more AppleTalk networks to a computer running Windows NT Server.

Internet

The global network of networks. See also World Wide Web (WWW).

Internet Assigned Numbers Authority (IANA)

The central coordinator for the assignment of unique parameter values for Internet protocols. IANA is chartered by the Internet Society (ISOC) and the Federal Network Council (FNC) to act as the clearinghouse to assign and coordinate the use of numerous Internet protocol parameters. Contact IANA at http://www.iana.org/iana/.

Internet Assistant

Several Internet Assistant add-on software components are available for Microsoft Office products. Each Internet Assistant adds functionality that is relevant to creating content for the Internet. For example, Internet Assistant for Microsoft Word enables Word to create HTML documents from within Microsoft Word.

Internet Control Message Protocol (ICMP)

A maintenance protocol in the TCP/IP suite, required in every TCP/IP implementation, that allows two nodes on an IP network to share IP status and error information. ICMP is used by the ping utility to determine the readability of a remote system. See also ping; Transmission Control Protocol/Internet Protocol (TCP/IP).

Internet Database Connector (IDC)

Provides access to databases for Internet Information Server by using ODBC. The Internet Database Connector is contained in Httpodbc.dll, which is an Internet Server API DLL.

Internet Engineering Task Force (IETF)

A consortium that introduces procedures for new technology on the Internet. IETF specifications are released in documents called Requests for Comments (RFCs). See also Requests for Comments (RFCs).

Internet Group Management Protocol (IGMP)

A protocol used by workgroup software products and supported by Microsoft TCP/IP.

Internet group name

A name known by a DNS server that includes a list of the specific addresses of systems that have registered the name. See also Domain Name System (DNS).

Internet Information Server (IIS)

A network file and application server that supports multiple protocols. Primarily, Internet Information Server transmits information in Hypertext Markup Language (HTML) pages by using the Hypertext Transport Protocol (HTTP).

Internet Mail Connector (IMC)

The Internet Mail Connector is a component of Microsoft Exchange Server that runs as a Windows NT Server service. You can use the Internet Mail Connector to exchange information with other systems that use the Simple Mail Transfer Protocol (SMTP).

Internet Network Information Center (InterNIC)

The coordinator for DNS registration. To register domain names and obtain IP addresses, contact InterNIC at http://internic.net.

Internet Protocol (IP)

The messenger protocol of TCP/IP, responsible for addressing and sending TCP packets over the network. IP provides a best-effort, connectionless delivery system that does not guarantee that packets arrive at their destination or that they are received in the sequence in which they were sent. See also packet; Transmission Control Protocol (TCP); Transmission Control Protocol/Internet Protocol (TCP/IP).

Internet Protocol Control Protocol (IPCP)

Specified by RFC 1332. Responsible for configuring, enabling, and disabling the IP protocol modules on both ends of the point-to-point (PPP) link. See also Point-to-Point Protocol (PPP); Requests for Comments (RFCs).

Internet Relay Chat (IRC)

A protocol that enables two or more people, each in remote locations, who are connected to an IRC server to hold real-time conversations. IRC is defined in RFC 1459.

Internet router

A device that connects networks and directs network information to other networks, usually choosing the most efficient route through other routers. See also router.

Internet Server Application Programming Interface (ISAPI)

An API for developing extensions to the Microsoft Internet Information Server and other HTTP servers that support ISAPI. See also application programming interface (API).

Internet service provider (ISP)

A company or educational institution that enables remote users to access the Internet by providing dial-up connections or installing leased lines.

internetworks

Networks that connect local area networks (LANs) together.

interprocess communication (IPC)

The ability, provided by a multitasking operating system, of one task or process to exchange data with another. Common IPC methods include pipes, semaphores, shared memory, queues, signals, and mailboxes. See also named pipe; queue.

interrupt

An asynchronous operating system condition that disrupts normal execution and transfers control to an interrupt handler. Interrupts can be issued by both software and hardware devices requiring service from the processor. When software issues an interrupt, it calls an interrupt service routine (ISR). When hardware issues an interrupt, it signals an interrupt request (IRQ) line.

interrupt moderation

A Windows NT performance optimizing feature that diverts interrupts from the network adapters when the rate of interrupts is very high. The system accumulates the interrupts in a buffer for later processing. Standard interrupt processing is resumed when the interrupt rate returns to normal.

interrupt request line (IRQ)

A hardware line over which devices can send signals to get the attention of the processor when the device is ready to accept or send information. Typically, each device connected to the computer uses a separate IRQ.

intranet

A TCP/IP network that uses Internet technology. May be connected to the Internet. See also Internet; Transmission Control Protocol/Internet Protocol (TCP/IP).

I/O addresses

Locations within the input/output address space of your computer, used by a device such as a printer or modem. See also input/output activity (I/O).

IOCTL

See input/output control.

IP

See Internet Protocol.

IP address

Used to identify a node on a network and to specify routing information. Each node on the network must be assigned a unique IP address, which is made up of the network ID, plus a unique host ID assigned by the network administrator. This address is typically represented in dotted-decimal notation, with the decimal value of each octet separated by a period (for example, 138.57.7.27).

In Windows NT, the IP address can be configured statically on the client or configured dynamically through DHCP. See also Dynamic Host Configuration Protocol (DHCP); node; octet.

IPC

See interprocess communication.

IPCP

See Internet Protocol Control Protocol.

IP datagrams

The basic Internet Protocol (IP) information unit. See also datagram; Internet Protocol (IP).

IP router

A system connected to multiple physical TCP/IP networks that can route or deliver IP packets between the networks. See also packet; routing; Transmission Control Protocol/Internet Protocol (TCP/IP).

IPX

See IPX/SPX.

IPX/SPX

Acronym for Internetwork Packet Exchange/Sequenced Packet Exchange, which is a set of transport protocols used in Novell NetWare networks. Windows NT implements IPX through NWLink.

IRC

See Internet Relay Chat.

IRQ

See interrupt request line.

ISAPI

See Internet Server Application Programming Interface.

ISDN

See Integrated Services Digital Network.

ISDN interface card

Similar in function to a modem, an ISDN card is hardware that enables a computer to connect to other computers and networks on an Integrated Services Digital Network.

ISO

Abbreviation for the International Standards Organization, an international association of member countries, each of which is represented by its leading standard-setting organization—for example ANSI (American National Standards Institute) for the United States. The ISO works to establish global standards for communications and information exchange.

ISP

See Internet service provider.

iteration

One of the three key concepts in DNS name resolution. A local name server keeps the burden of processing on itself and passes only iterative resolution requests to other name servers. An iterative resolution request tells the name server that the requester expects the best answer the name server can provide without help from others. If the name server has the requested data, it returns it, otherwise it returns pointers to name servers that are more likely to have the answer. See also Domain Name System (DNS).

In programming, iteration is the art of executing one or more statements or instructions repeatedly.

J

jump

Text, graphics, or parts of graphics that provide links to other Help topics or to more information about the current topic. The pointer changes shape whenever it is over a jump. If you click a jump that is linked to another topic, that topic appears in the Help window. If you click a jump that is linked to more information, the information appears in a pop-up window on top of the main Help window.

K

keep-alives

See HTTP keep-alives; TCP/IP keep-alives.

Kermit

Protocol for transferring binary files that is somewhat slower than XModem/CRC. However, Kermit allows you to transmit and receive either seven or eight data bits per character. See also XModem/CRC.

Kernel

The Windows NT Kernel is the part of the Windows NT Executive that manages the processor. It performs thread scheduling and dispatching, interrupt and exception handling, and multiprocessor synchronization. The Kernel synchronizes activities among Executive-level subcomponents, such as I/O Manager and Process Manager. It also provides primitive objects to the Windows NT Executive, which uses them to create User-mode objects. The Kernel works closely with the Hardware Abstraction Layer (HAL). See also Executive; Hardware Abstraction Layer (HAL).

Kernel debugger

The Windows NT Kernel debugger (KD) is a 32-bit application that is used to debug the Kernel and device drivers, and to log the events leading up to a Windows NT Executive STOP, STATUS, or hardware-malfunction message.

The Kernel debugger runs on another Windows NT host computer that is connected to your Windows NT target computer. The two computers send debugging (troubleshooting) information back and forth through a communications port that must be running at the same baud rate on each computer.

Kernel driver

A driver that accesses hardware. See also device driver.

key

A folder that appears in the left pane of a Registry editor window. A key can contain subkeys and value entries. For example: Environment is a key of HKEY_CURRENT_USER. See also subkey.

keyboard buffer

A temporary storage area in memory that keeps track of keys you typed, even if the computer did not immediately respond to the keys when you typed them.

key map

A mapping assignment that translates key values on synthesizers that do not conform to General MIDI standards. Key maps ensure that the appropriate percussion instrument is played or the appropriate octave for a melodic instrument is played when a MIDI file is played. See also Musical Instrument Digital Interface (MIDI).

kiosk

A computer, connected to the Internet, made available to users in a commonly accessible location.

L

LAN

See local area network.

LastKnownGood (LKG) control set

The most recent control set that correctly started the system and resulted in a successful startup. The control set is saved as the LKG control set when you have a successful logon. See also current control set.

lease

In Windows NT, the network administrator controls how long IP addresses are assigned by specifying lease durations that specify how long a computer can use an assigned IP address before having to renew the lease with the DHCP server. See also Dynamic Host Configuration Protocol (DHCP); IP address.

leased line

A high-capacity line (most often a telephone line) dedicated to network connections.

license group

License groups show a relationship (also known as a mapping) between users and computers. A license group comprises a single descriptive name for the group, a specified number of Per-Seat licenses assigned to the group, and a specific list of users who are members of the group.

line printer daemon (LPD)

A line printer daemon (LPD) service on the print server receives documents (print jobs) from line printer remote (LPR) utilities running on client systems.

linked object

A representation or placeholder for an object that is inserted into a destination document. The object still exists in the source file and, when it is changed, the linked object is updated to reflect these changes.

list box

In a dialog box, a type of box that lists available choices—for example, a list of all files in a directory. If all the choices do not fit in the list box, there is a scroll bar.

LMHOSTS file

A local text file that maps IP addresses to the computer names of Windows NT networking computers outside the local subnet. In Windows NT, this file is stored in the \Systemroot \System32\Drivers\Etc directory. See also IP address; subnet.

local account

For Windows NT Server, a user account provided in a domain for a user whose global account is not in a trusted domain. Not required where trust relationships exist between domains. See also global account; trust relationship; user account.

local area network (LAN)

A group of computers and other devices dispersed over a relatively limited area and connected by a communications link that enables any device to interact with any other on the network.

local group

For Windows NT Workstation, a group that can be granted permissions and rights only for its own workstation. However, it can contain user accounts from its own computer and (if the workstation participates in a domain) user accounts and global groups both from its own domain and from trusted domains.

For Windows NT Server, a group that can be granted permissions and rights only for the domain controllers of its own domain. However, it can contain user accounts and global groups both from its own domain and from trusted domains.

Local groups provide a way to create handy sets of users from both inside and outside the domain, to be used only at domain controllers of the domain. See also global group; group; trust relationship.

local guest logon

Takes effect when a user logs on interactively at a computer running Window NT Workstation or at a member server running Windows NT Server, and specifies Guest as the user name in the Logon Information dialog box. See also interactive logon.

Local Mail Delivery Agent

The component of the SMTP server that processes messages that have been received by the SMTP server and downloads the messages to the user's local computer.

local printer

A printer that is directly connected to one of the ports on your computer. See also port.

LocalTalk

The name given by Apple Computer to the Apple networking hardware built into every Macintosh. LocalTalk includes the cables and connector boxes that connect components and network devices that are part of the AppleTalk network system. LocalTalk was formerly known as the AppleTalk Personal Network.

local user profiles

User profiles that are created automatically on the computer at logon the first time a user logs on to a computer running Windows NT Workstation or Windows NT Server.

lock

A method used to manage certain features of subdirectory replication by the export server. You can lock a subdirectory to prevent it from being exported to any import computers, or use locks to prevent imports to subdirectories on an import computer. See also directory replication; export server; import computers; subtree.

log books

Kept by the system administrator to record the backup methods, dates, and contents of each tape in a backup set. See also backup set; backup types.

log files

Created by Windows NT Backup and contain a record of the date the tapes were created and the names of files and directories successfully backed up and restored. Performance Monitor also creates log files.

logical drive

A subpartition of an extended partition on a hard disk. See also extended partition.

Logical Unit (LU)

A preset unit containing all the configuration information needed for a user or a program to establish a session with a host or peer computer. See also host; peer.

log off

To stop using the network and remove your user name from active use until you log on again.

log on

To provide a user name and password that identifies you to the network.

logon hours

For Windows NT Server, a definition of the days and hours during which a user account can connect to a server. When a user is connected to a server and the logon hours are exceeded, the user will either be disconnected from all server connections or allowed to remain connected but denied any new connections.

logon script

A file that can be assigned to user accounts. Typically a batch program, a logon script runs automatically every time the user logs on. It can be used to configure a user's working environment at every logon, and it allows an administrator to affect a user's environment without managing all aspects of it. A logon script can be assigned to one or more user accounts. See also batch program.

logon script path

When a user logs on, the computer authenticating the logon locates the specified logon script (if one has been assigned to that user account) by following that computer's local logon script path (usually C:\Winnt\System32\Repl\Imports\Scripts). See also authentication; logon script.

logon workstations

In Windows NT Server, the computers from which a user is allowed to log on.

long name

A folder name or filename longer than the 8.3 filename standard (up to eight characters followed by a period and a three-character extension) of the FAT file system. Windows NT Server automatically translates long names of files and folders to 8.3 names for MS-DOS users.

Macintosh users can assign long names to files and folders on the server, and by using Services for Macintosh, you can assign long names to Macintosh-accessible volumes when you create them. See also file allocation table (FAT); filename; name mapping; short name.

loopback address

The IP address 127.0.0.1, which has been specified by the Internet Engineering Task Force as the IP address to use in conjunction with a loopback driver to route outgoing packets back to the source computer. See also loopback driver.

loopback driver

A network driver that allows the packets to bypass the network adapter completely and be returned directly to the computer that is performing the test. See also loopback address.

LPD

See line printer daemon.

LPR

Acronym for line printer remote. See also line printer daemon.

LU

See Logical Unit.

luminosity

The brightness of a color on a scale from black to white on your monitor.

M

MAC

See media access control.

MAC address

A unique 48-bit number assigned to the network adapter by the manufacturer. MAC addresses (which are physical addresses) are used for mapping in TCP/IP network communication. See also Address Resolution Protocol (ARP); ARP request packet; media access control (MAC).

MacFile

See File Server for Macintosh service.

MacFile menu

The menu that appears in Windows NT Server when Services for Macintosh is set up. You can create Macintosh-accessible volumes, and set permissions and other options by using commands on this menu.

Macintosh-accessible volume

Storage space on the server used for folders and files of Macintosh users. A Macintosh-accessible volume is equivalent to a shared directory for PC users. Each Macintosh-accessible volume on a computer running Windows NT Server will correspond to a directory. Both PC users and Macintosh users can be given access to files located in a directory that is designated as both a shared directory and a Macintosh-accessible volume.

Macintosh-style permissions

Directory and volume permissions that are similar to the access privileges used on a Macintosh.

MacPrint

See Print Server for Macintosh.

Mac volume

See Macintosh-accessible volume.

Mail Server (MailSrv)

The MailSrv utility no longer ships with the Windows NT Server Resource Kit.

Make Changes

The Macintosh-style permission that gives users the right to make changes to a folder's contents; for example, modifying, renaming, moving, creating, and deleting files. When Services for Macintosh translates access privileges into Windows NT Server permissions, a user who has the Make Changes privilege is given Write and Delete permissions.

management information base (MIB)

A set of objects that represent various types of information about a device, used by SNMP to manage devices. Because different network-management services are used for different types of devices or protocols, each service has its own set of objects. The entire set of objects that any service or protocol uses is referred to as its MIB. See also Simple Network Management Protocol (SNMP).

mandatory user profile

A profile that is downloaded to the user's desktop each time he or she logs on. A mandatory user profile is created by an administrator and assigned to one or more users to create consistent or job-specific user profiles. They cannot be changed by the user and remain the same from one logon session to the next. See also roaming user profile; user profile.

mapping

In TCP/IP, refers to the relationship between a host or computer name and an IP address, used by DNS and NetBIOS servers on TCP/IP networks.

In Windows NT Explorer, refers to mapping a driver letter to a network drive.

In Windows NT License Manager, refers to the relationship between users and computers in license groups. See also Domain Name System (DNS); IP address; license group.

mapping file

A file defining exactly which users and groups are to be migrated from NetWare to Windows NT Server, and what new user names and passwords are to be assigned to the migrated users.

Master Boot Record

The most important area on a hard disk, the data structure that starts the process of booting the computer.

The Master Boot Record contains the partition table for the disk and a small amount of executable code. On x86-based computers, the executable code examines the partition table and identifies the system (or bootable) partition, finds the system partition's starting location on the disk, and loads an image of its Partition Boot Sector into memory. The Master Boot Record then transfers execution to the Partition Boot Sector. See also Partition Table.

master browser

A kind of network name server which keeps a browse list of all the servers and domains on the network. Also referred to as browse master. See also browse; Windows NT browser system.

master domain

In the master domain model, the domain that is trusted by all other domains on the network and acts as the central administrative unit for user and group accounts.

maximize

To enlarge a window to its maximum size by using the Maximize button (at the right of the title bar) or the Maximize command on the window menu.

Maximize button

The small button containing a window icon at the right of the title bar. Mouse users can click the Maximize button to enlarge a window to its maximum size. Keyboard users can use the Maximize command on the window menu.

maximum password age

The period of time a password can be used before the system requires the user to change it. See also account policy.

MCI

See Media Control Interface.

media access control (MAC)

A layer in the network architecture that deals with network access and collision detection.

media access control (MAC) driver

See network card driver.

Media Control Interface (MCI)

A standard control interface for multimedia devices and files. Using MCI, a multimedia application can control a variety of multimedia devices and files.

member server

A computer that runs Windows NT Server but is not a primary domain controller (PDC) or backup domain controller (BDC) of a Windows NT domain. Member servers do not receive copies of the directory database. Also called a stand-alone server. See also backup domain controller (BDC); directory database; primary domain controller (PDC).

memory

A temporary storage area for information and applications. See also expanded memory; extended memory.

menu

A list of available commands in an application window. Menu names appear in the menu bar near the top of the window. The window menu, represented by the program icon at the left end of the title bar, is common to all applications for Windows NT. To open a menu, click the menu name.

menu bar

The horizontal bar containing the names of all the application's menus. It appears below the title bar.

Messenger service

Sends and receives messages sent by administrators or by the Alerter service. See also Alerter service.

MIB

See management information base.

Microsoft dbWeb

A database publishing gateway provided in the Windows NT Server Resource Kit. dbWeb can run under Internet Information Server to provide public access to private enterprise ODBC sources as specified by an administrator of the private enterprise.

MIDI

See Musical Instrument Digital Interface.

MIDI setup

Specifies the type of MIDI device you are using, the channel and patch settings needed to play MIDI files, and the port your device is using. See also Musical Instrument Digital Interface (MIDI).

Migration Tool for NetWare

Included with Windows NT, it enables you to easily transfer user and group accounts, volumes, folders, and files from a NetWare server to a computer running Windows NT Server.

MIME

See Multipurpose Internet Mail Extensions.

minimize

To reduce a window to a button on the taskbar by using the Minimize button (at the right of the title bar) or the Minimize command on the Control menu. See also maximize.

Minimize button

The small button containing a short line at the right of the title bar. Mouse users can click the Minimize button to reduce a window to a button on the taskbar. Keyboard users can use the Minimize command on the Control menu.

minimum password age

The period of time a password must be used before the user can change it. See also account policy.

minimum password length

The fewest characters a password can contain. See also account policy.

mirror set

A fully redundant or shadow copy of data. Mirror sets provide an identical twin for a selected disk; all data written to the primary disk is also written to the shadow or mirror disk. This enables you to have instant access to another disk with a redundant copy of the information on a failed disk. Mirror sets provide fault tolerance. See also fault tolerance.

m-node

A NetBIOS implementation that uses the b-node protocol first, then the p-node protocol if the broadcast fails to resolve a name to an IP address. See also IP address; network basic input/output system (NetBIOS); p-node.

modem

Short for modulator/demodulator, a communications device that enables a computer to transmit information over a standard telephone line.

MPR

See MultiProtocol Routing.

MS-DOS–based application

An application that is designed to run with MS-DOS, and therefore may not be able to take full advantage of all Windows NT features.

multicast datagram

IP multicasting is the transmission of an IP datagram to a host group (a set of zero or more hosts identified by a single IP destination address.) An IP datagram sent to one host is called a unicast datagram. An IP datagram sent to all hosts is called a broadcast datagram. See also broadcast datagram; host; IP address.

multihomed computer

A system that has multiple network adapters, or that has been configured with multiple IP addresses for a single network adapter. See also IP address; network adapter.

multihomed system

A system with multiple network adapters attached to separate physical networks.

multilink dialing

Multilink combines multiple physical links into a logical "bundle." This aggregate link increases your bandwidth. See also bandwidth.

multiple boot

A computer that runs two or more operating systems. For example, Windows 95, MS-DOS, and Windows NT operating systems can be installed on the same computer. When the computer is started, any one of the operating systems can be selected. Also known as dual boot.

multiport serial adapter

A communications device that enables a computer to simultaneously transmit information over standard telephone lines to multiple computers. Similar to multiple modems contained in one device. See also modem.

MultiProtocol Routing (MPR)

Enables routing over IP and IPX networks by connecting LANs or by connecting LANs to WANs. See also IPX/SPX; local area network (LAN); wide area network (WAN).

Multipurpose Internet Mail Extensions (MIME)

A standard mechanism for specifying and describing the format of Internet message bodies. MIME enables the exchanging of objects, different character sets, and multimedia in e-mail on different computer systems. Defined in RFC 1521.

Musical Instrument Digital Interface (MIDI)

An interface that enables several devices, instruments, or computers to send and receive messages for the purpose of creating music, sound, or lighting.

N

named pipe

An interprocess communication mechanism that allows one process to communicate with another local or remote process.

name mapping

Is provided by Windows NT Server and Windows NT Workstation to ensure access by MS-DOS users to NTFS and FAT volumes (which can have share names of up to 255 characters, as opposed to MS-DOS, which is restricted to eight characters followed by a period and a three-character extension). With name mapping, each file or directory with a name that does not conform to the MS-DOS 8.3 standard is automatically given a second name that does. MS-DOS users connecting the file or directory over the network see the name in the 8.3 format; Windows NT Workstation and Windows NT Server users see the long name. See also Domain Name System (DNS); long name; Windows Internet Name Service (WINS).

name resolution service

TCP/IP internetworks require a name resolution service to convert computer names to IP addresses and IP addresses to computer names. (People use "friendly" names to connect to computers; programs use IP addresses.) See also IP address; Transmission Control Protocol/Internet Protocol (TCP/IP).

NDIS

See network device interface specification.

NDS

See NetWare Directory Services.

NetBEUI

A network protocol usually used in small, department-size local area networks of 1 through 200 clients. It can use Token Ring source routing as its only method of routing. See also router; Token Ring.

NetBIOS

See network basic input/output system.

NetBT

Short for NetBIOS over TCP/IP. The session-layer network service that performs name-to-IP address mapping for name resolution. See also IP address; name resolution service; network basic input/output system (NetBIOS); Transmission Control Protocol/Internet Protocol (TCP/IP).

Net Logon service

For Windows NT Server, performs authentication of domain logons, and keeps the domain's directory database synchronized between the primary domain controller (PDC) and the other backup domain controllers (BDCs) of the domain. See also backup domain controller (BDC); directory database; primary domain controller (PDC).

NetWare Directory Services (NDS)

A NetWare service that runs on NetWare servers. The service enables the location of resources on the network.

network adapter

An expansion card or other device used to connect a computer to a local area network (LAN). Also called a network card; network adapter card; adapter card; network interface card (NIC).

network adapter card

See network adapter.

network administrator

A person responsible for planning, configuring, and managing the day-to-day operation of the network. This person may also be referred to as a system administrator.

network basic input/output system (NetBIOS)

An application programming interface (API) that can be used by applications on a local area network. NetBIOS provides applications with a uniform set of commands for requesting the lower-level services required to conduct sessions between nodes on a network and to transmit information back and forth. See also application programming interface (API).

network card

See network adapter.

network card driver

A network device driver that works directly with the network card, acting as an intermediary between the card and the protocol driver. With Services for Macintosh, the AppleTalk Protocol stack on the server is implemented as a protocol driver and is bound to one or more network drivers.

Network DDE DSDM service

The Network DDE DSDM (DDE share database manager) service manages shared DDE conversations. It is used by the Network DDE service. See also dynamic data exchange (DDE).

Network DDE service

The Network DDE (dynamic data exchange) service provides a network transport and security for DDE conversations. See also dynamic data exchange (DDE).

network device driver

Software that coordinates communication between the network adapter and the computer's hardware and other software, controlling the physical function of the network adapters.

network device interface specification (NDIS)

In Windows networking, the Microsoft/3Com specification for the interface of network device drivers. All transport drivers call the NDIS interface to access network cards. With Services for Macintosh, the AppleTalk Protocol stack on the server is implemented as an NDIS-compliant protocol and is bound to an NDIS network driver. All network drivers and protocol drivers shipped with Windows NT Workstation and Windows NT Server conform to NDIS.

network directory

See shared directory.

network driver

See network device driver.

network driver interface specification

See network device interface specification (NDIS).

Network File System (NFS)

A service for distributed computing systems that provides a distributed file system, eliminating the need for keeping multiple copies of files on separate computers.

network ID

The portion of the IP address that identifies a group of computers and devices located on the same logical network.

Network Information Service (NIS)

A service for distributed computing systems that provides a distributed database system for common configuration files.

network interface card (NIC)

See network adapter.

Network News Transfer Protocol (NNTP)

The protocol used to distribute network news messages to NNTP servers and to NNTP clients (news readers) on the Internet. NNTP provides for the distribution, inquiry, retrieval, and posting of news articles by using a reliable stream-based transmission of news on the Internet. NNTP is designed so that news articles are stored on a server in a central database, thus enabling a user to select specific items to read. Indexing, cross-referencing, and expiration of aged messages are also provided. Defined in RFC 977.

network number

In the Macintosh environment, the network number (also referred to as the network range) is the address or range of addresses assigned to the network, which is used by AppleTalk routers to route information to the appropriate network. Each physical network can have a range of network numbers.

network protocol

Software that enables computers to communicate over a network. TCP/IP is a network protocol, used on the Internet. See also Transmission Control Protocol/Internet Protocol (TCP/IP).

network range

In the Macintosh environment, a range of network numbers (routing addresses) associated with a physical network in Phase 2. Apple manuals sometimes refer to a network range as a cable range. See also network number; routing.

network sniffer

A hardware and software diagnostic tool that can also be used to decipher passwords, which may result in unauthorized access to network accounts. Clear-text passwords are susceptible to network sniffers.

NFS

See Network File System.

NIC

Acronym for network interface card. See network adapter.

NIS

See Network Information Service.

NNTP

See Network News Transfer Protocol.

node

In the PC environment, a node is any device that is attached to the internetwork and uses TCP/IP. (A node can also be referred to as a host.) In the Macintosh environment, a node is an addressable entity on a network. Each Macintosh client is a node.

nonpaged memory

Memory that cannot be paged to disk. See also memory; paging file.

non–Windows NT application

Refers to an application that is designed to run with Windows 3.x, MS-DOS, OS/2, or POSIX, but not specifically with Windows NT, and that may not be able to take full advantage of all Windows NT features (such as memory management). See also POSIX.

NT

See Windows NT Server; Windows NT Workstation.

NT file system

See Windows NT file system.

NTFS

See Windows NT file system.

NWLink IPX\SPX Compatible Transport

A standard network protocol that supports routing, and can support NetWare client/server applications, where NetWare-aware Sockets-based applications communicate with IPX\SPX Sockets-based applications. See also IPX/SPX; Sockets.

O

object

Any piece of information, created by using a Windows-based application, that can be linked or embedded into another document. See also embedded object; linked object.

object-cache scavenger

A component of the IIS process that periodically flushes from the cache objects that have changed or that have not been referenced in its last timed interval. The default time interval for the object-cache scavenger is 30 seconds.

octet

In programming, an octet refers to eight bits or one byte. IP addresses, for example, are typically represented in dotted-decimal notation, that is, with the decimal value of each octet of the address separated by a period. See also IP address.

ODBC

See Open Database Connectivity.

offset

When specifying a filter in Windows NT Network Monitor based on a pattern match (which limits the capture to only those frames containing a specific pattern of ASCII or hexadecimal data), you must specify where the pattern occurs in the frame. This number of bytes (from the beginning or end of the frame) is known as an offset. See also frame; hexadecimal.

OLE

A way to transfer and share information between applications. See also ActiveX; embedded object; linked object.

one-way trust relationship

One domain (the trusting domain) "trusts" the domain controllers in the other domain (the trusted domain) to authenticate user accounts from the trusted domain to use resources in the trusting domain. See also trust relationship; user account.

opcode

Operation code; a code, usually a number, that specifies an operation to be performed. An opcode is often the first component in a contiguous block of data; it indicates how other data in the block should be interpreted.

open

To display the contents of a directory, a document, or a data file in a window.

Open Database Connectivity (ODBC)

ODBC is an application programming interface that enables applications to access data from a variety of existing data sources.

Open Systems Interconnection model (OSI)

TCP/IP protocols map to a four-layered conceptual model consisting of Application, Transport, Internet, and Network Interface. Each layer in this TCP/IP model corresponds to one or more layers of the International Standards Organization (ISO) seven-layer OSI model consisting of Application, Presentation, Session, Transport, Network, Data-link, and Physical. See also ISO.

orphan

A member of a mirror set or a stripe set with parity that has failed in a severe manner, such as in a loss of power or a complete head crash. When this happens, the fault-tolerance driver determines that it can no longer use the orphaned member and directs all new reads and writes to the remaining members of the fault-tolerance volume. See also fault tolerance; mirror set; stripe sets with parity.

orphaned member

See orphan.

OSI

See Open Systems Interconnection model.

owner

In Windows NT, every file and directory on an NTFS volume has an owner, who controls how permissions are set on the file or directory and who can grant permissions to others.

In the Macintosh environment, an owner is the user responsible for setting permissions for a folder on a server. A Macintosh user who creates a folder on the server automatically becomes the owner of the folder. The owner can transfer ownership to someone else. Each Macintosh-accessible volume on the server also has an owner.

owner category

In the Macintosh environment, this refers to the user category to which you assign permissions for the owner of a folder or a Macintosh volume. See also Macintosh-accessible volume.

P

package

An icon that represents an embedded or linked object. When you choose the package, the application used to create the object either plays the object (for example, a sound file) or opens and displays the object. See also embedded object; linked object.

packet

A transmission unit of fixed maximum size that consists of binary information representing both data and a header containing an ID number, source and destination addresses, and error-control data.

packet assembler/disassembler (PAD)

A connection used in X.25 networks. X.25 PAD boards can be used in place of modems when provided with a compatible COM driver. See also X.25.

packet header

The part of a packet that contains an identification number, source and destination addresses, and—sometimes—error-control data. See also packet.

PAD

See packet assembler/disassembler.

page fault

In the processor, a page fault occurs when a process refers to a virtual memory page that is not in its working set in main memory.

A hard page fault occurs when data that a program needs is not found in its working set (the physical memory visible to the program) or elsewhere in physical memory, and must be retrieved from disk.

A page fault will not cause the page to be fetched from disk if that page is on the standby list, and hence already in main memory, or if it is in use by another process with which the page is shared. In this case, a soft page fault occurs.

paging file

A special file on a PC hard disk. With virtual memory under Windows NT, some of the program code and other information is kept in RAM while other information is temporarily swapped into virtual memory. When that information is required again, Windows NT pulls it back into RAM and, if necessary, swaps other information to virtual memory. Also called a swap file.

PAP

See Password Authentication Protocol.

parity

Redundant information that is associated with a block of information. In Windows NT Server, stripe sets with parity means that there is one additional parity stripe per row. Therefore, you must use at least three, rather than two, disks to allow for this extra parity information. Parity stripes contain the XOR (the Boolean operation called exclusive OR) of the data in that stripe. Windows NT Server, when regenerating a failed disk, uses the parity information in those stripes in conjunction with the data on the good disks to recreate the data on the failed disk. See also fault tolerance; stripe set; stripe sets with parity.

partial synchronization

The automatic, timed delivery to all domain BDCs (backup domain controllers) of only those directory database changes that have occurred since the last synchronization. See also backup domain controller (BDC); synchronize.

partition

A partition is a portion of a physical disk that functions as though it were a physically separate unit. See also extended partition; system partition.

Partition Table

An area of the Master Boot Record that the computer uses to determine how to access the disk. The Partition Table can contain up to four partitions for each physical disk. See also Master Boot Record.

pass-through authentication

When the user account must be authenticated, but the computer being used for the logon is not a domain controller in the domain where the user account is defined, nor is it the computer where the user account is defined, the computer passes the logon information through to a domain controller (directly or indirectly) where the user account is defined. See also domain controller; user account.

password

A security measure used to restrict logons to user accounts and access to computer systems and resources. A password is a unique string of characters that must be provided before a logon or an access is authorized. For Windows NT, a password for a user account can be up to 14 characters, and is case-sensitive. There are four user-defined parameters to be entered in the Account Policy dialog box in User Manager or User Manager for Domains: maximum password age, minimum password age, minimum password length, and password uniqueness.

With Services for Macintosh, each Macintosh user must type a user password when accessing the Windows NT Server. You can also assign each Macintosh-accessible volume a volume password if you want, which all users must type to access the volume. See also account policy.

Password Authentication Protocol (PAP)

A type of authentication that uses clear-text passwords and is the least sophisticated authentication protocol.

password uniqueness

The number of new passwords that must be used by a user account before an old password can be reused. See also account policy; password.

patch map

The part of a channel-map entry that translates instrument sounds, volume settings, and (optionally) key values for a channel.

path

A sequence of directory (or folder) names that specifies the location of a directory, file, or folder within the directory tree. Each directory name and filename within the path (except the first) must be preceded by a backslash (\). For example, to specify the path of a file named Readme.wri located in the Windows directory on drive C, you type c:\windows\readme.wri.

PC

Any personal computer (such as an IBM PC or compatible) using the MS-DOS, OS/2, Windows, Windows for Workgroups, Windows 95, Windows NT Workstation, or Windows NT Server operating systems.

PCMCIA

See Personal Computer Memory Card International Association.

peer

Any of the devices on a layered communications network that operate on the same protocol level.

Peer Web Services

A collection of services that enable the user of a computer running Windows NT Workstation to publish a personal Web site from the desktop. The services include the WWW service, the FTP service, and the Gopher service.

pel

Also known as a pixel, which is short for picture element, the smallest graphic unit that can be displayed on the screen.

Perl

Practical Extraction and Report Language. A scripting (programming) language that is frequently used for CGI scripts.

permissions

Windows NT Server settings you set on a shared resource that determine which users can use the resource and how they can use it. See also access permission.

Services for Macintosh automatically translates between permissions and Macintosh access privileges, so that permissions set on a directory (volume) are enforced for Macintosh users, and access privileges set by Macintosh users are enforced for PC users connected to the computer running Windows NT Server.

Personal Computer Memory Card International Association (PCMCIA)

A standard for removable peripheral devices (called PC cards) about the size of a credit card, which plug into a special 68-pin connector found most commonly in portable computers. Currently available PCMCIA cards include memory, hard disk, modem, fax, network, and wireless communication devices.

personal group

In the Start menu on the Programs list, a program group you have created that contains program items. Personal groups are stored with your logon information and each time you log on, your personal groups appear. See also group.

Physical Unit (PU)

A network-addressable unit that provides the services needed to use and manage a particular device, such as a communications link device. A PU is implemented with a combination of hardware, software, and microcode.

PIF

See program information file.

ping

A command used to verify connections to one or more remote hosts. The ping utility uses the ICMP echo request and echo reply packets to determine whether a particular IP system on a network is functional. The ping utility is useful for diagnosing IP network or router failures. See also Internet Control Message Protocol (ICMP); router.

pipe

An interprocess communication mechanism. Writing to and reading from a pipe is much like writing to and reading from a file, except that the two processes are actually using a shared memory segment to communicate data. See also named pipe.

pixel

See pel.

plotter font

See font types.

p-node

A NetBIOS implementation that uses point-to-point communications with a name server to resolve names as IP addresses. See also h-node; IP address; network basic input/output system (NetBIOS).

pointer

The arrow-shaped cursor on the screen that follows the movement of a mouse (or other pointing device) and indicates which area of the screen will be affected when you press the mouse button. The pointer changes shape during certain tasks.

Point-to-Point Protocol (PPP)

A set of industry-standard framing and authentication protocols that is part of Windows NT RAS to ensure interoperability with third-party remote access software. PPP negotiates configuration parameters for multiple layers of the OSI model. See also Open Systems Interconnection model (OSI).

Point-to-Point Tunneling Protocol (PPTP)

PPTP is a new networking technology that supports multiprotocol virtual private networks (VPNs), enabling remote users to access corporate networks securely across the Internet by dialing into an Internet service provider (ISP) or by connecting directly to the Internet. See also virtual private network (VPN).

POP

See Post Office Protocol.

pop-up menu

See window menu.

port

A location used to pass data in and out of a computing device. This term can refer to an adapter card connecting a server to a network, a serial 232 port, a TCP/IP port, or a printer port.

port ID

The method TCP and UDP use to specify which application running on the system is sending or receiving the data. See also Transmission Control Protocol (TCP); User Datagram Protocol (UDP).

POSIX

Acronym for Portable Operating System Interface, an IEEE (Institute of Electrical and Electronics Engineers) standard that defines a set of operating-system services. Programs that adhere to the POSIX standard can be easily ported from one system to another.

Post Office Protocol (POP)

The Post Office Protocol version 3 (POP3) is a protocol that permits a workstation to dynamically access a mail drop on a server in a useful fashion. Usually, this means that a POP3 server is used to allow a workstation to retrieve mail that an SMTP server is holding for it. POP3 is specified in RFC 1725.

PostScript printer

A printer that uses the PostScript page description language to create text and graphics on the output medium, such as paper or overhead transparency. Examples of PostScript printers include the Apple LaserWriter, the NEC LC-890, and the QMS PS-810. See also font types.

POTS

Acronym for plain-old telephone service. Also an acronym for point of termination station, which refers to where a telephone call terminates.

power conditioning

A feature of an uninterruptible power supply (UPS) that removes spikes, surges, sags, and noise from the power supply. See also uninterruptible power supply (UPS).

PPP

See Point-to-Point Protocol.

PPTP

See Point-to-Point Tunneling Protocol.

predefined key

The key represented by a Registry window, the name of which appears in the window's title bar. See also key; Registry.

primary domain controller (PDC)

In a Windows NT Server domain, the computer running Windows NT Server that authenticates domain logons and maintains the directory database for a domain. The PDC tracks changes made to accounts of all computers on a domain. It is the only computer to receive these changes directly. A domain has only one PDC. See also directory database.

primary group

The group with which a Macintosh user usually shares documents stored on a server. You specify a user's primary group in the user's account. When a user creates a folder on the server, the user's primary group is set as the folder's associated group (by default).

primary partition

A partition is a portion of a physical disk that can be marked for use by an operating system. There can be up to four primary partitions (or up to three, if there is an extended partition) per physical disk. A primary partition cannot be subpartitioned. See also extended partition; partition.

print device

Refers to the actual hardware device that produces printed output.

printer

Refers to the software interface between the operating system and the print device. The printer defines where the document will go before it reaches the print device (to a local port, to a file, or to a remote print share), when it will go, and various other aspects of the printing process.

printer driver

A program that converts graphics commands into a specific printer language, such as PostScript or PCL. See also font types.

printer fonts

Fonts that are built into your printer. These fonts are usually located in the printer's read-only memory (ROM). See also font; font types.

printer permissions

Specify the type of access a user or group has to use the printer. The printer permissions are No Access, Print, Manage Documents, and Full Control.

printer window

Shows information for one of the printers that you have installed or to which you are connected. For each printer, you can see what documents are waiting to be printed, who owns them, how large they are, and other information.

printing pool

Consists of two or more identical print devices associated with one printer.

print job

In the Macintosh environment, a document or image sent from a client to a printer.

print processor

A PostScript program that understands the format of a document's image file and how to print the file to a specific printer or class of printers. See also encapsulated PostScript (EPS) file.

print server

Refers to the computer that receives documents from clients.

Print Server for Macintosh

A Services for Macintosh service that enables Macintosh clients to send documents to printers attached to a computer running Windows NT; enables PC clients to send documents to printers anywhere on the AppleTalk network; and enables Macintosh users to spool their documents to the computer running Windows NT Server, thus freeing their clients to do other tasks. Also called MacPrint.

print sharing

The ability for a computer running Windows NT Workstation or Windows NT Server to share a printer on the network. This is done by using the Printers folder or the net share command.

print spooler

A collection of dynamic-link libraries (DLLs) that receive, process, schedule, and distribute documents.

private volume

A Macintosh-accessible volume that is accessible by only one Macintosh user. For a volume to be a private volume, the permissions on its root directory must give the volume's owner all three permissions (Make Changes, See Files, and See Folders), while giving the primary group and everyone categories no permissions at all. When a private volume's owner uses the Chooser to view the volumes available on the server, the private volume is listed; however, no other users can see the private volume when viewing the volumes available on the server. See also Macintosh-accessible volume.

privilege level

One of three settings (User, Administrator, or Guest) assigned to each user account. The privilege level a user account has determines the actions that the user can perform on the network. See also Administrator privilege; Guest privilege; user account; User privilege.

process

When a program runs, a Windows NT process is created. A process is an object type which consists of an executable program, a set of virtual memory addresses, and one or more threads.

processor affinity mask

A Windows NT bit mask that associates processors with network adapters. All deferred procedure calls (DPCs) originating from the network adapter are handled by its associated processor.

program file

A file that starts an application or program. A program file has an .exe, .pif, .com, or .bat filename extension.

program group

On the Start menu, a collection of applications. Grouping your applications makes them easier to find when you want to start them. See also common group; personal group.

program icon

Located at the left of the window title bar, the program icon represents the program being run. Clicking the program icon opens the window menu.

program information file (PIF)

A PIF provides information to Windows NT about how best to run MS-DOS–based applications. When you start an MS-DOS–based application, Windows NT looks for a PIF to use with the application. PIFs contain such items as the name of the file, a start-up directory, and multitasking options.

program item

An application, accessory, or document represented as an icon in the Start menu or on the desktop.

promiscuous mode

A state of a network card in which it passes on to the networking software all the frames that it detects on the network, regardless of the frames' destination address. See also frame; network adapter.

propagate

Copy. For example, NetWare user accounts are propagated to the Windows NT primary domain controller when using Directory Service Manager for NetWare (DSMN).

property

In Windows NT Network Monitor, a property refers to a field within a protocol header. A protocol's properties, collectively, indicate the purpose of the protocol.

protocol

A set of rules and conventions for sending information over a network. These rules govern the content, format, timing, sequencing, and error control of messages exchanged among network devices.

protocol driver

A network device driver that implements a protocol, communicating between Windows NT Server and one or more network adapter card drivers. With Services for Macintosh, the AppleTalk Protocol stack is implemented as an NDIS-protocol driver, and is bound to one or more network adapter card drivers.

protocol parser

A dynamic-link library (DLL) that identifies the protocols used to send a frame onto the network. See also dynamic-link library (DLL); frame.

protocol properties

Refers to the elements of information that define a protocol's purpose. Because the purposes of protocols vary, properties differ from one protocol to another.

protocol stack

The implementation of a specific protocol family in a computer or other node on the network.

proxy

A computer that listens to name query broadcasts and responds for those names not on the local subnet. The proxy communicates with the name server to resolve names and then caches them for a time period. See also caching; Domain Name System (DNS); subnet.

PSTN

Acronym for public switched telephone network.

PU

See Physical Unit.

public key cryptography

A method of encrypting data transmissions to and from a server.

pull partner

A WINS server that pulls in replicas from its push partner by requesting it and then accepting the pushed replicas. See also Windows Internet Name Service (WINS).

push partner

A WINS server that sends replicas to its pull partner upon receiving a request from it. See also Windows Internet Name Service (WINS).

Q

queue

In Windows NT terminology, a queue refers to a group of documents waiting to be printed. (In NetWare and OS/2 environments, queues are the primary software interface between the application and print device; users submit documents to a queue. However, with Windows NT, the printer is that interface—the document is sent to a printer, not a queue.)

quick format

Deletes the file allocation table (FAT) and root directory of a disk but does not scan the disk for bad areas. This function is available in Disk Administrator or when checking disks for errors. See also file allocation table (FAT); root directory.

R

RAID

Acronym for Redundant Array of Inexpensive Disks. A method used to standardize and categorize fault-tolerant disk systems. Six levels gauge various mixes of performance, reliability, and cost. Windows NT includes three of the RAID levels: Level 0, Level 1, and Level 5.

RAM

An acronym for random-access memory. RAM can be read from or written to by the computer or other devices. Information stored in RAM is lost when you turn off the computer. See also memory.

RAS

See Remote Access Service.

recursion

One of the three key concepts in DNS name resolution. A resolver typically passes a recursive resolution request to its local name server, which tells the name server that the resolver expects a complete answer to the query, not just a pointer to another name server. Recursive resolution effectively puts the workload onto the name server and allows the resolver to be small and simple. See also Domain Name System (DNS); iteration.

reduce

To minimize a window to an icon by using the Minimize button or the Minimize command. A minimized application continues running, and you can click the icon on the toolbar to make it the active application.

reduced instruction set computing (RISC)

A type of microprocessor design that focuses on rapid and efficient processing of a relatively small set of instructions. RISC architecture limits the number of instructions that are built into the microprocessor, but optimizes each so that it can be carried out very rapidly—usually within a single clock cycle.

refresh

To update displayed information with current data.

registration

In Windows NT NetBT name resolution, registration is the process used to register a unique name for each computer (node) on the network. A computer typically registers itself when it starts.

Registry

The Windows NT Registry is a hierarchical database that provides a repository for information about a computer's configuration on Windows NT Workstation and about hardware and user accounts on Windows NT Server. It is organized in subtrees and their keys, hives, and value entries. See also hive; key; subtree; user account.

Registry size limit (RSL)

The total amount of space that can be consumed by Registry data is restricted by the Registry size limit, which is a kind of universal maximum for Registry space that prevents an application from filling the paged pool with Registry data. See also hive; paging file.

Remote Access Service (RAS)

A service that provides remote networking for telecommuters, mobile workers, and system administrators who monitor and manage servers at multiple branch offices. Users with RAS on a Windows NT–based computer can dial in to remotely access their networks for services such as file and printer sharing, electronic mail, scheduling, and SQL database access.

remote administration

Administration of one computer by an administrator located at another computer and connected to the first computer across the network.

remote logon

Occurs when a user is already logged on to a user account and makes a network connection to another computer. See also user account.

remote procedure call (RPC)

A message-passing facility that allows a distributed application to call services available on various machines in a network. Used during remote administration of computers. See also remote administration.

Remote Procedure Call service

See RPC service.

renew

Client computers are periodically required to renew their NetBIOS name registrations with the WINS server. When a client computer first registers with a WINS server, the WINS server returns a message that indicates when the client will need to renew its registration. See also network basic input/output system (NetBIOS); Windows Internet Name Service (WINS).

repeaters

The most basic LAN connection device, repeaters strengthen the physical transmission signal. A repeater simply takes the electrical signals that reach it and then regenerates them to full strength before passing them on. Repeaters generally extend a single network (rather than link two networks).

replication

See directory replication.

replicators

One of the Windows NT built-in local groups for workstations and member servers, used for directory replication functions. See also directory replication.

Requests for Comments (RFCs)

The official documents of the IETF (Internet Engineering Task Force) that specify the details for protocols included in the TCP/IP family. See also Internet Engineering Task Force (IETF); Transmission Control Protocol/Internet Protocol (TCP/IP).

resolution

In Windows NetBT name resolution, resolution is the process used to determine the specific address for a computer name.

resolvers

DNS clients that query DNS servers for name resolution on networks. See also Domain Name System (DNS).

resource

Any part of a computer system or a network, such as a disk drive, printer, or memory, that can be allotted to a program or a process while it is running, or shared over a local area network.

resource domain

A trusting domain that establishes a one-way trust relationship with the master (account) domain, enabling users with accounts in the master domain to use resources in all the other domains. See also domain; trust relationship.

resource fork

One of two forks that make up each Macintosh file. The resource fork holds Macintosh operating system resources, such as code, menu, font, and icon definitions. Resource forks have no relevance to PCs, so the resource forks of files on the server are never accessed by PC clients. See also data fork.

response

In Windows NT RAS, responses are strings expected from the device, which can contain macros.

RFC

See Requests for Comments.

right

See; permissions; user rights.

RIP

See routing information protocol.

RISC

See reduced instruction set computing.

roaming user profile

User profile that is enabled when an administrator enters a user profile path into the user account. The first time the user logs off, the local user profile is copied to that location. Thereafter, the server copy of the user profile is downloaded each time the user logs on (if it is more current than the local copy) and is updated each time the user logs off. See also user profile.

root directory

The top-level directory on a computer, a partition, or Macintosh-accessible volume. See also directory tree.

router

In the Windows NT environment, a router helps LANs and WANs achieve interoperability and connectivity and can link LANs that have different network topologies (such as Ethernet and Token Ring). Routers match packet headers to a LAN segment and choose the best path for the packet, optimizing network performance.

In the Macintosh environment, routers are necessary for computers on different physical networks to communicate with each other. Routers maintain a map of the physical networks on a Macintosh internet (network) and forward data received from one physical network to other physical networks. Computers running Windows NT Server with Services for Macintosh can act as routers, and you can also use third-party routing hardware on a network with Services for Macintosh. See also local area network (LAN); packet; wide area network (WAN).

routing

The process of forwarding packets to other routers until the packet is eventually delivered to a router connected to the specified destination. See also packet; router.

routing information protocol (RIP)

Enables a router to exchange routing information with a neighboring router. See also routing.

routing table

Controls the routing decisions made by computers running TCP/IP. Routing tables are built automatically by Windows NT based on the IP configuration of your computer. See also dynamic routing; routing; static routing; Transmission Control Protocol/Internet Protocol (TCP/IP).

RPC

See remote procedure call.

RPC Locator service

The Remote Procedure Call Locator service allows distributed applications to use the RPC Name service. The RPC Locator service manages the RPC Name service database.

The server side of a distributed application registers its availability with the RPC Locator service. The client side of a distributed application queries the RPC Locator service to find available compatible server applications. See also remote procedure call (RPC).

RPC service

The Remote Procedure Call service is the RPC subsystem for Microsoft Windows NT. The RPC subsystem includes the endpoint mapper and other miscellaneous RPC services. See also remote procedure call (RPC).

RSL

See Registry size limit.

S

SACL

See system access control list.

SAM

Acronym for Security Accounts Manager. See directory database; Windows NT Server Directory Services.

SAP

In the Windows environment, SAP is an acronym for Service Advertising Protocol, a service that broadcasts shared files, directories, and printers categorized first by domain or workgroup and then by server name.

In the context of routing and IPX, SAP is also an acronym for Service Advertising Protocol, used by servers to advertise their services and addresses on a network. Clients use SAP to determine what network resources are available.

In NetBEUI, SAP is an acronym for Service Access Point, in which each link-layer program identifies itself by registering a unique service access point.

Not to be confused with SAP financial database application software for the mainframe computer.

saturation

The purity of a color's hue, moving from gray to the pure color.

scavenging

Cleaning up the WINS database. See also Windows Internet Name Service (WINS).

Schedule service

Supports and is required for use of the at command. The at command can schedule commands and programs to run on a computer at a specified time and date.

schemas

Schemas control how and what information from a private database is available to visitors who use the Internet to access the public Microsoft dbWeb gateway to the private database. See also dbWeb Administrator.

Schema Wizard

Interactive tool in dbWeb Administrator that leads a user through creation of HTML pages or through implementing an ISAPI application.

screen buffer

The size reserved in memory for the command prompt display.

screen dump

See snapshot.

screen elements

The parts that make up a window or dialog box, such as the title bar, the Minimize and Maximize buttons, the window borders, and the scroll bars.

screen fonts

Fonts displayed on your screen. Soft-font manufacturers often provide screen fonts that closely match the soft fonts for your printer. This ensures that your documents look the same on the screen as they do when printed. See also font; font types.

screen saver

A moving picture or pattern that appears on your screen when you have not used the mouse or the keyboard for a specified period of time. To select a screen saver, either use Display in Control Panel or right-click on the desktop for properties.

scroll

To move through text or graphics (up, down, left, or right) in order to see parts of the file that cannot fit on the screen.

scroll arrow

An arrow on either end of a scroll bar that you use to scroll through the contents of the window or list box. Click the scroll arrow to scroll one screen at a time, or continue pressing the mouse button while pointing at the scroll arrow to scroll continuously.

scroll bar

A bar that appears at the right and/or bottom edge of a window or list box whose contents are not completely visible. Each scroll bar contains two scroll arrows and a scroll box, which enable you to scroll through the contents of the window or list box.

scroll box

In a scroll bar, a small box that shows the position of information currently visible in the window or list box relative to the contents of the entire window.

scroll buffer

The area in memory that holds information that does not fit on the screen. You can use the scroll bars to scroll through the information.

SCSI

See small computer system interface.

Search button

See find tab.

section header

In Windows NT RAS, a section header is a string, comprising up to 32 characters between square brackets, that identifies the specific device to which the section applies.

secure attention sequence

A series of keystrokes (CTRL+ALT+DEL) that will always display the Windows NT operating system logon screen.

secure communications channel

Created when computers at each end of a connection are satisfied that the computer on the other end has identified itself correctly by using its computer account. See also computer account.

Secure Sockets Layer (SSL)

A protocol that supplies secure data communication through data encryption and decryption. SSL enables communications privacy over networks by using a combination of public key cryptography and bulk data encryption.

security

A means of ensuring that shared files can be accessed only by authorized users.

Security Accounts Manager (SAM)

See directory database; Windows NT Server Directory Services.

security database

See directory database.

security host

A third-party authentication device that verifies whether a caller from a remote client is authorized to connect to the Remote Access server. This verification supplements security already authorized to connect to the Remote-Access server.

security ID (SID)

A unique name that identifies a logged-on user to the security system. Security IDs (SIDs) can identify one user or a group of users.

security identifier

See security ID (SID).

security log

Records security events. This helps track changes to the security system and identify any possible breaches of security. For example, depending on the Audit settings in User Manager or User Manager for Domains, attempts to log on to the local computer might be recorded in the security log. The security log contains both valid and invalid logon attempts as well as events related to resource use (such as creating, opening, or deleting files.) See also event.

security policies

For Windows NT Workstation, the security policies consist of the Account, User Rights, and Audit policies, and are managed by using User Manager.

For a Windows NT Server domain, the security policies consist of the Account, User Rights, Audit, and Trust Relationships policies, and are managed by using User Manager for Domains.

security token

See access token.

seed router

In the Macintosh environment, a seed router initializes and broadcasts routing information about one or more physical networks. This information tells routers where to send each packet of data. A seed router on an AppleTalk network initially defines the network number(s) and zone(s) for a network. Services for Macintosh servers can function as seed routers, and you can also use third-party hardware routers as seed routers. See also packet; router.

See Files

The Macintosh-style permission that give users the right to open a folder and see the files in the folder. For example, a folder that has See Files and See Folders Macintosh-style permissions is given the Windows NT-style R (Read) permission. See also permissions.

See Folders

The Macintosh-style permission that gives users the right to open a folder and see the files contained in that folder. See also permissions.

select

To mark an item so that a subsequent action can be carried out on that item. You usually select an item by clicking it with a mouse or pressing a key. After selecting an item, you choose the action that you want to affect the item.

selection cursor

The marking device that shows where you are in a window, menu, or dialog box and what you have selected. The selection cursor can appear as a highlight or as a dotted rectangle around text.

semaphore

Generally, semaphores are signaling devices or mechanisms. However, in Windows NT, system semaphores are objects used to synchronize activities on an interprocess level. For example, when two or more processes share a common resource such as a printer, video screen, or memory segment, semaphores are used to control access to those resources so that only one process can alter them at any particular time.

sequence number

The identifier with which TCP marks packets before sending them. The sequence numbers allow the receiving system to properly order the packets on the receiving system. See also packet; Transmission Control Protocol (TCP).

Serial Line Internet Protocol (SLIP)

An older industry standard that is part of Windows NT RAS to ensure interoperability with third-party remote access software.

server

In general, refers to a computer that provides shared resources to network users. See also member server.

server application

A Windows NT application that can create objects for linking or embedding into other documents. For distributed applications, the application that responds to a client application. See also client application; DCOM Configuration tool; Distributed Component Object Model (DCOM); embedded object; linked object.

Server Manager

In Windows NT Server, an application used to view and administer domains, workgroups, and computers.

Server Message Block (SMB)

A file-sharing protocol designed to allow systems to transparently access files that reside on remote systems.

Server service

Provides RPC (remote procedure call) support, and file, print, and named pipe sharing. See also named pipe; remote procedure call (RPC).

server zone

The AppleTalk zone on which a server appears. On a Phase 2 network, a server appears in the default zone of the server's default network. See also default network; default zone; desired zone; zone.

service

A process that performs a specific system function and often provides an application programming interface (API) for other processes to call. Windows NT services are RPC-enabled, meaning that their API routines can be called from remote computers. See also application programming interface (API); remote procedure call (RPC).

Service Access Point (SAP)

See SAP.

Service Advertising Protocol (SAP)

See SAP.

Services for Macintosh

See Windows NT Server Services for Macintosh.

session

A link between two network devices, such as a client and a server. A session between a client and server consists of one or more connections from the client to the server.

SFM

Acronym for Windows NT Services for Macintosh.

share

To make resources, such as directories and printers, available to others.

shared directory

A directory that network users can connect to.

shared network directory

See shared directory.

shared resource

Any device, data, or program that is used by more than one other device or program. For Windows NT, shared resources refer to any resource that is made available to network users, such as directories, files, printers, and named pipes. Also refers to a resource on a server that is available to network users. See also named pipe.

share name

A name that refers to a shared resource on a server. Each shared directory on a server has a share name, used by PC users to refer to the directory. Users of Macintosh use the name of the Macintosh-accessible volume that corresponds to a directory, which may be the same as the share name. See also Macintosh-accessible volume.

share permissions

Are used to restrict a shared resource's availability over the network to only certain users.

Shiva Password Authentication Protocol (SPAP)

A two-way (reversible) encryption mechanism employed by Shiva. Windows NT Workstation, when connecting to a Shiva LAN Rover, uses SPAP, as does a Shiva client connecting to a Windows NT Server. See also encryption.

shortcut key

A key or key combination, available for some commands, that you can press to carry out a command without first selecting a menu. Shortcut keys are listed to the right of commands on a menu.

short name

A valid 8.3 (up to eight characters followed by a period and a three-character extension) MS-DOS or OS/2 filename that the computer running Windows NT Server creates for every Macintosh folder name or filename on the server. PC users refer to files on the server by their short names; Macintosh users refer to them by their long names. See also long name; name mapping.

SID

See security ID.

silent mode

During IP routing in silent mode, the computer listens to RIP broadcasts and updates its route table but does not advertise its own routes. See also routing; routing information protocol (RIP); routing table.

simple device

A device that you use without specifying a related media file. An audio compact-disc player is a simple device.

Simple Mail Transfer Protocol (SMTP)

A member of the TCP/IP suite of protocols that governs the exchange of electronic mail between message transfer agents.

Simple Network Management Protocol (SNMP)

A protocol used by SNMP consoles and agents to communicate. In Windows NT, the SNMP service is used to get and set status information about a host on a TCP/IP network. See also Transmission Control Protocol/Internet Protocol (TCP/IP).

single user logon

Windows NT network users can connect to multiple servers, domains, and applications with a single network logon.

SLIP

See Serial Line Internet Protocol.

small computer system interface (SCSI)

A standard high-speed parallel interface defined by the American National Standards Institute (ANSI). A SCSI interface is used for connecting microcomputers to peripheral devices such as hard disks and printers, and to other computers and local area networks.

SMB

See Server Message Block.

SMS

See Systems Management Server.

SMTP

See Simple Mail Transfer Protocol.

SNA

See System Network Architecture.

snapshot

A copy of main memory or video memory at a given instant, sent to a printer or hard disk. A graphical image of the video screen can be saved by taking a snapshot of video memory, more commonly called a screen dump.

sniffer

See network sniffer.

Sniffer files

Files saved from Network General Sniffer, a third-party protocol analyzer. See also network sniffer.

SNMP

See Simple Network Management Protocol.

socket

A bidirectional pipe for incoming and outgoing data between networked computers. The Windows Sockets API is a networking API used by programmers creating TCP/IP-based sockets applications. See also application programming interface (API); named pipe.

Sockets

Windows Sockets is a Windows implementation of the widely used UC Berkeley sockets API. Microsoft TCP/IP, NWLink, and AppleTalk protocols use this interface. Sockets interfaces between programs and the transport protocol and works as a bidirectional pipe for incoming and outgoing data. See also application programming interface (API); named pipe; socket.

source directory

The directory that contains the file or files you intend to copy or move.

source document

The document where a linked or embedded object was originally created. See also embedded object; linked object.

SPAP

See Shiva Password Authentication Protocol.

special access permission

On NTFS volumes, a custom set of permissions. You can customize permissions on files and directories by selecting the individual components of the standard sets of permissions. See also access permission.

split bar

Divides Windows NT Explorer into two parts: The directory tree is displayed on the left, and the contents of the current directory are on the right. See also directory tree.

spoofing

Refers to a case where an Internet user mimics ("spoofs") the source IP address for an Internet server, proxy server, or firewall of a system to which it is trying to gain access.

spooler

Software that accepts documents sent by a user to be printed, and then stores those documents and sends them, one by one, to available printer(s). See also spooling.

spooling

A process on a server in which print documents are stored on a disk until a printing device is ready to process them. A spooler accepts each document from each client, stores it, then sends it to a printing device when it is ready.

SQL

Acronym for structured query language, a database programming language used for accessing, querying, and otherwise managing information in a relational database system.

SSL

See Secure Sockets Layer.

stabilize

During subdirectory replication, when a subdirectory is stabilized, the export server waits two minutes after changes before exporting the subdirectory. The waiting period allows time for subsequent changes to take place so that all intended changes are recorded before being replicated. See also directory replication; export server; subtree.

stand-alone server

See member server.

static mapping

A method provided on a WINS server to assign a static (unchanging) IP address to a client.

static object

Information that has been pasted into a document. Unlike embedded or linked objects, static objects cannot be changed from within the document. The only way you can change a static object is to delete it from the document, change it in the application used to create it, and paste it into the document again. See also embedded object; linked object.

static routing

Static routing limits you to fixed routing tables, as opposed to dynamically updating the routing tables. See also dynamic routing; routing table.

static web pages

Standard web pages that are created in advance and stored for later delivery to clients. See also dynamic web pages.

status bar

A line of information related to the application in the window. Usually located at the bottom of a window. Not all windows have a status bar.

STATUS message

A message displayed by the Executive in a Windows-mode message box when the Executive detects a condition within a process that you should know about.

STATUS messages can be divided into three types:

System-information messages. Just read the information in the message box and click OK. The Kernel continues running the process or thread.

Warning messages. Some advise you to take an action that will enable the Kernel to keep running the process or thread. Others warn you that, although the process or thread will continue running, the results might be incorrect.

Application-termination messages. These warn you that the Kernel is about to terminate either a process or a thread.

See also Executive messages; STOP message.

STOP message

A character-mode message that occurs when the Kernel detects an inconsistent condition from which it cannot recover. Always displayed on a full character-mode screen, uniquely identified by a hexadecimal number and a symbolic string. The content of the symbolic string can suggest, to a trained technician, the part of the Kernel that detected the condition from which there was no recourse but to stop. However, the cause may actually be in another part of the system. See also Executive messages; STATUS message.

string

A data structure composed of a sequence of characters, usually representing human-readable text.

stripe set

Refers to the saving of data across identical partitions on different drives. A stripe set does not provide fault tolerance; however stripe sets with parity do. See also fault tolerance; partition; stripe sets with parity.

stripe sets with parity

A method of data protection in which data is striped in large blocks across all the disks in an array. Data redundancy is provided by the parity information. This method provides fault tolerance. See also fault tolerance; stripe set.

subdirectory

A directory within a directory. Also called a folder within a folder.

subkey

A key within a key. Subkeys are analogous to subdirectories in the Registry hierarchy. Keys and subkeys are similar to the section heading in .ini files; however subkeys can carry out functions. See also key; Registry.

subnet

A portion of a network, which may be a physically independent network segment, that shares a network address with other portions of the network and is distinguished by a subnet number. A subnet is to a network what a network is to an internet.

subnet mask

A 32-bit value that allows the recipient of IP packets to distinguish the network ID portion of the IP address from the host ID. See also IP address; packet.

substitution macros

Placeholders that are replaced in command strings.

subtree

During directory replication, this refers to the export subdirectory and all of its subdirectories. See also directory replication.

swap file

See paging file.

switched circuit

See dial-up line.

SYN attack

SYN (synchronizing character) messages maliciously generated by an intruder in an attempt to block legitimate access to a server by proliferating half-open TCP port connections. Also called SYN flooding.

synchronize

To replicate the domain database from the primary domain controller (PDC) to one backup domain controller (BDC) of the domain, or to all the BDCs of a domain. This is usually performed automatically by the system, but can also be invoked manually by an administrator. See also backup domain controller (BDC); domain; primary domain controller (PDC).

syntax

The order in which you must type a command and the elements that follow the command. Windows NT commands have up to four elements: command name, parameters, switches, and values.

system access control list (SACL)

The system ACL is controlled by the system administrator, and allows system-level security to be associated with an object. SACL APIs can be used only by a process with System Administrator privileges. See also discretionary access control list (DACL).

system default profile

In Windows NT Server, the user profile that is loaded when Windows NT is running and no user is logged on. When the Begin Logon dialog box is visible, the system default profile is loaded. See also user default profile, user profile.

system disk

A disk that contains the MS-DOS system files necessary to start MS-DOS.

system log

The system log contains events logged by the Windows NT components. For example, the failure of a driver or other system component to load during startup is recorded in the system log. Use Event Viewer to view the system log.

System Network Architecture (SNA)

System Network Architecture is a communications framework developed by IBM. Microsoft System Network Architecture (SNA) is an optional solution that provides a gateway connection between personal computer LANs or WANs and IBM mainframe and AS/400 hosts. See also AS/400; gateway.

system partition

The volume that has the hardware-specific files needed to load Windows NT. See also partition.

system policy

A policy, created by using the System Policy Editor, to control user work environments and actions, and to enforce system configuration for Windows 95. System policy can be implemented for specific users, groups, computers, or for all users. System policy for users overwrites settings in the current user area of the Registry, and system policy for computers overwrites the current local machine area of the Registry. See also Registry.

systemroot

The name of the directory that contains Windows NT files. The name of this directory is specified when Windows NT is installed.

Systems Management Server

Part of the Windows NT BackOffice™ suite. Systems Management Server includes desktop management and software distribution that significantly automates the task of upgrading software on client computers.

T

T1 or T3 connection

Standard measurement of network bandwidth.

tag file

A configuration file that contains information about a corresponding file on a Gopher server or links to other servers. This information is sent to clients in response to a Gopher request.

tape set

A tape set (sometimes referred to as a tape family) in Windows NT Backup is a sequence of tapes in which each tape is a continuation of the backup on the previous tape. See also backup set; backup types.

TAPI

See Telephony API.

Task list

A window that shows all running applications and their status. View the Task list in the Applications tab in Task Manager.

Task Manager

Task Manager enables you to start, end, or run applications, end processes (an application, application component, or system process), and view CPU and memory use data. Task Manager gives you a simple, quick view of how each process (application or service) is using CPU and memory resources. (Note: In previous versions of Windows NT, Task List handled some of these functions).

To run Task Manager, right-click the toolbar and then click Task Manager.

TCP

See Transmission Control Protocol.

TCP/IP

See Transmission Control Protocol/Internet Protocol.

TCP/IP keep-alives

An optimizing feature of the TCP/IP service. TCP/IP periodically broadcasts messages to determine whether an idle connection is still active. See also HTTP keep-alives.

TDI

See transport driver interface.

Telephony API (TAPI)

An API used by programs to make data/fax/voice calls, including HyperTerminal, Dial-up Networking, Phone Dialer, and other Win32 communications applications written for Windows NT.

Telnet (VTP)

A terminal emulation protocol for logging on to remote computers. Once referred to as Virtual Terminal Protocol (VTP). Defined in RFC 854, among others.

template accounts

Accounts that are not actually used by real users but serve as a basis for the real accounts (for administrative purposes).

terminate-and-stay-resident program (TSR)

A program running under MS-DOS that remains loaded in memory even when it is not running so that it can be quickly invoked for a specific task performed while any other application is operating.

text box

In a dialog box, a box in which you type information needed to carry out a command. The text box may be blank or may contain text when the dialog box opens.

text file

A file containing text characters (letters, numbers, and symbols) but no formatting information. A text file can be a "plain" ASCII file that most computers can read. Text file can also refer to a word-processing file. See also ASCII file.

text-file transfer

A method for transferring files from HyperTerminal to a remote computer. With this method, files are transferred as ASCII files with minimal formatting characters, such as linefeeds and carriage returns. All font-formatting information is removed. See also ASCII file.

text-only

An ASCII file that contains no formatting. See also ASCII file.

TFTP

See Trivial File Transfer Protocol.

thread

Threads are objects within processes that run program instructions. They allow concurrent operations within a process and enable one process to run different parts of its program on different processors simultaneously.

throughput

See bandwidth.

time-out

If a device is not performing a task, the amount of time the computer should wait before detecting it as an error.

time slice

The amount of processor time allocated to an application, usually measured in milliseconds.

title bar

The horizontal bar (at the top of a window) that contains the title of the window or dialog box. On many windows, the title bar also contains the program icon and the Maximize, Minimize, and Close buttons.

Token Ring

A type of network media that connects clients in a closed ring and uses token passing to enable clients to use the network. See also Fiber Distributed Data Interface (FDDI); LocalTalk.

toolbar

A series of icons or shortcut buttons providing quick access to commands. Usually located directly below the menu bar. Not all windows have a toolbar.

topic

Information in the Help window. A Help topic usually begins with a title and contains information about a particular task, command, or dialog box.

transforms

Rules the administrator creates to add, remove, and modify domain names appended to inbound and outbound messages.

Transmission Control Protocol (TCP)

A connection-based Internet protocol responsible for breaking data into packets, which the IP protocol sends over the network. This protocol provides a reliable, sequenced communication stream for network communication. See also Internet Protocol (IP); packet.

Transmission Control Protocol/Internet Protocol (TCP/IP)

A set of networking protocols that provide communications across interconnected networks made up of computers with diverse hardware architectures and various operating systems. TCP/IP includes standards for how computers communicate and conventions for connecting networks and routing traffic.

transport driver interface (TDI)

In Windows networking, the common interface for network components that communicate at the Session layer.

trap

In SNMP, a discrete block of data that indicates that the request failed authentication. The SNMP service can send a trap when it receives a request for information that does not contain the correct community name and that does not match an accepted host name for the service. Trap destinations are the names or IP addresses of hosts to which the SNMP service is to send traps with community names. See also IP address; Simple Network Management Protocol (SNMP).

trigger

A set of conditions that, when met, initiate an action. For example, before using Network Monitor to capture data from the network, you can set a trigger to stop the capture or to execute a program or command file.

Trivial File Transfer Protocol (TFTP)

A file transfer protocol that transfers files to and from a remote computer running the TFTP service. TFTP was designed with less functions than FTP. Defined in RFC 1350, among others. See also file transfer protocol (FTP).

Trojan horse

A program that masquerades as another common program in an attempt to receive information. An example of a Trojan horse is a program that masquerades as a system logon to retrieve user names and password information, which the writers of the Trojan horse can use later to break into the system.

TrueType fonts

Fonts that are scalable and sometimes generated as bitmaps or soft fonts, depending on the capabilities of your printer. TrueType fonts can be sized to any height, and they print exactly as they appear on the screen.

trust

See trust relationship.

trust relationship

A link between domains that enables pass-through authentication, in which a trusting domain honors the logon authentications of a trusted domain. With trust relationships, a user who has only one user account in one domain can potentially access the entire network. User accounts and global groups defined in a trusted domain can be given rights and resource permissions in a trusting domain, even though those accounts do not exist in the trusting domain's directory database. See also directory database; global group; pass-through authentication; user account.

trust relationships policy

A security policy that determines which domains are trusted and which domains are trusting domains. See also trust relationship.

TSR

See terminate-and-stay-resident program.

two-way trust relationship

Each domain trusts user accounts in the other domain to use its resources. Users can log on from computers in either domain to the domain that contains their account. See also trust relationship.

type

See file type.

Type 1 fonts

Scalable fonts designed to work with PostScript devices. See also font; font types; PostScript printer.

U

UAM

See user authentication module.

UDP

See User Datagram Protocol.

unavailable

An unavailable button or command is displayed in light gray instead of black, and it cannot be clicked.

UNC name

See universal naming convention name.

unicast datagram

An IP datagram sent to one host. See also broadcast datagram; Internet Protocol (IP); multicast datagram.

Unicode

A fixed-width, 16-bit character-encoding standard capable of representing the letters and characters of virtually all the world's languages. Unicode was developed by a consortium of U.S. computer companies.

Uniform Resource Locator (URL)

A naming convention that uniquely identifies the location of a computer, directory, or file on the Internet. The URL also specifies the appropriate Internet protocol, such as HTTP, FTP, IRC, or Gopher.

uninterruptible power supply (UPS)

A battery-operated power supply connected to a computer to keep the system running during a power failure.

universally unique identifier (UUID)

A unique identification string associated with the remote procedure call interface. Also known as a globally unique identifier (GUID).

universal naming convention (UNC) name

A full Windows NT name of a resource on a network. It conforms to the \\Servername\Sharename syntax, where Servername is the server's name and Sharename is the name of the shared resource. UNC names of directories or files can also include the directory path under the share name, with the following syntax: \\Servername\Sharename\Directory\Filename.

UPS

See uninterruptible power supply.

UPS service

Manages an uninterruptible power supply connected to a computer. See also uninterruptible power supply (UPS).

URL

See Uniform Resource Locator.

user account

Consists of all the information that defines a user to Windows NT. This includes such things as the user name and password required for the user to log on, the groups in which the user account has membership, and the rights and permissions the user has for using the system and accessing its resources. For Windows NT Workstation, user accounts are managed with User Manager. For Windows NT Server, user accounts are managed with User Manager for Domains. See also group.

user account database

See directory database.

user authentication module

Software component that prompts clients for their user names and passwords. See also clear-text passwords.

User Datagram Protocol (UDP)

A TCP complement that offers a connectionless datagram service that guarantees neither delivery nor correct sequencing of delivered packets (much like IP). See also datagram; Internet Protocol (IP); packet.

user default profile

In Windows NT Server, the user profile that is loaded by a server when a user's assigned profile cannot be accessed for any reason; when a user without an assigned profile logs on to the computer for the first time; or when a user logs on to the Guest account. See also system default profile; user profile.

User Manager

A Windows NT Workstation tool used to manage the security for a workstation. User Manager administers user accounts, groups, and security policies.

User Manager for Domains

A Windows NT Server tool used to manage security for a domain or an individual computer. User Manager for Domains administers user accounts, groups, and security policies.

user name

A unique name identifying a user account to Windows NT. An account's user name cannot be identical to any other group name or user name of its own domain or workgroup. See also user account.

user password

The password stored in each user's account. Each user generally has a unique user password and must type that password when logging on or accessing a server. See also password; volume password.

User privilege

One of three privilege levels you can assign to a Windows NT user account. Every user account has one of the three privilege levels (Administrator, Guest, and User). Accounts with User privilege are regular users of the network; most accounts on your network probably have User privilege. See also Administrator privilege; Guest privilege; user account.

user profile

Configuration information that can be retained on a user-by-user basis, and is saved in user profiles. This information includes all the per-user settings of the Windows NT environment, such as the desktop arrangement, personal program groups and the program items in those groups, screen colors, screen savers, network connections, printer connections, mouse settings, window size and position. When a user logs on, the user's profile is loaded and the user's Windows NT environment is configured according to that profile. See also personal group; program item.

user rights

Define a user's access to a computer or domain and the actions that a user can perform on the computer or domain. User rights permit actions such as logging onto a computer or network, adding or deleting users in a workstation or domain, and so forth.

user rights policy

Manages the assignment of rights to groups and user accounts. See also user account; user rights.

users

In the Macintosh environment, a special group that contains all users who have user permissions on the server. When a Macintosh user assigns permissions to everyone, those permissions are given to the groups users and guests. See also guest.

UUENCODE (UNIX-to-UNIX Encode)

A utility that converts a binary file (such as a word-processing file or a program) to text so that it can be transmitted over a network. UUDECODE (UNIX-to-UNIX Decode) is the utility used to convert the file back to its original state.

UUID

See universally unique identifier.

V

value entry

The string of data that appears in the right pane of a Registry editor window and that defines the value of the currently selected key. A value entry has three parts: name, data type, and the value itself. See also key; subkey.

Van Jacobsen header compression

A TCP/IP network layer compression technique, VJ compression reduces the size of IP and TCP headers. See also Internet Protocol (IP); Transmission Control Protocol (TCP); Transmission Control Protocol/ Internet Protocol (TCP/IP).

variables

In programming, a variable is a named storage location capable of containing a certain type of data that can be modified during program execution. System environment variables are defined by Windows NT Server and are the same no matter who is logged on at the computer. (Administrator group members can add new variables or change the values, however.) User environment variables can be different for each user of a particular computer. They include any environment variables you want to define of variables defined by your applications, such as the path where application files are located.

VDD

See virtual device driver.

VDM

See virtual DOS machine.

verify operation

Occurs after all files are backed up or restored, if specified. A verify operation compares files on disk to files that have been written to tape. See also backup types.

virtual device driver (VDD)

A driver that enables MS-DOS –based and 16-bit Windows – based applications to run on Windows NT.

virtual directory

An Internet Information Server directory outside the home directory. A virtual directory appears to browsers as a subdirectory of the home directory.

virtual DOS machine (VDM)

Simulates an MS-DOS environment so that MS-DOS–based and Windows-based applications can run on Windows NT.

virtual memory

The space on your hard disk that Windows NT uses as if it were actually memory. Windows NT does this through the use of paging files. The benefit of using virtual memory is that you can run more applications at one time than your system's physical memory would otherwise allow. The drawbacks are the disk space required for the virtual-memory paging file and the decreased execution speed when paging is required. See also paging file.

virtual printer memory

In a PostScript printer, a part of memory that stores font information. The memory in PostScript printers is divided into two areas: banded memory and virtual memory. The banded memory contains graphics and page-layout information needed to print your documents. The virtual memory contains any font information that is sent to your printer either when you print a document or when you download fonts. See also font types; PostScript printer.

virtual private network (VPN)

A remote LAN that can be accessed through the Internet by using the new PPTP. See also Point-to-Point Tunneling Protocol (PPTP).

virtual server

A computer with several IP addresses assigned to the network adapter card. This configuration makes the computer look like several servers to a browser.

virus

A program that attempts to spread from computer to computer and either cause damage (by erasing or corrupting data) or annoy users (by printing messages or altering what is displayed on the screen).

volume

A partition or collection of partitions that have been formatted for use by a file system. See also Macintosh-accessible volume; partition.

volume password

An optional, case-sensitive password you can assign to a Macintosh-accessible volume when you configure the volume. To access the volume, a user must type the volume password. See also Macintosh-accessible volume; user password.

volume set

A combination of partitions on a physical disk that appear as one logical drive. See also logical drive; partition.

VPN

See virtual private network.

VTP

Acronym for Virtual Terminal Protocol. See Telnet.

W

WAIS

See wide area information server.

wallpaper

A picture or drawing stored as a bitmap file (a file that has a .bmp extension).

WAN

See wide area network.

warning beep

The sound that your computer makes when you encounter an error or try to perform a task that Windows NT does not recognize.

WCAT

Microsoft Web Capacity Analysis Tool. A script-driven utility that tests your client/server configuration by using a variety of predetermined, invariant workloads. WCAT can test how your server responds to different workloads or test the same workload on varying configurations of the server. WCAT is included on the Windows NT Resource Kit Supplement 1 CD.

Web browser

A software program, such as Internet Explorer, that retrieves a document from a Web server, interprets the HTML codes, and displays the document to the user with as much graphical content as the software can supply.

Web server

A computer equipped with the server software to respond to HTTP requests, such as requests from a Web browser. A Web server uses the HTTP protocol to communicate with clients on a TCP/IP network.

Well Known Port Number

The standard port numbers used by the Internet community for well known (commonly used) services. Ports are used in TCP to name the ends of logical connections that carry long-term conversations. Well known services are defined by RFC 1060. The relationship between the well known services and the well known ports is described in RFC 1340.

wide area information server (WAIS)

A network publishing system designed to help users find information over a computer network. WAIS software has four main components: the client, the server, the database, and the protocol. Discussed in RFC 1625.

wide area network (WAN)

A communications network that connects geographically separated areas.

wildcard

A character that represents one or more characters. The question mark (?) wildcard can be used to represent any single character, and the asterisk (*) wildcard can be used to represent any character or group of characters that might match that position in other filenames.

window

A rectangular area on your screen in which you view an application or document. You can open, close, and move windows, and change the size of most windows. You can open several windows at a time, and you can often reduce a window to an icon or enlarge it to fill the entire desktop.

window menu

A menu that contains commands you can use to manipulate a window. You click the program icon or document icon at the left of the title bar to open the window menu.

Windows Internet Name Service (WINS)

A name resolution service that resolves Windows networking computer names to IP addresses in a routed environment. A WINS server handles name registrations, queries, and releases. See also IP address; routing.

Windows NT–based application

Used as a shorthand term to refer to an application that is designed to run with Windows NT and does not run without Windows NT. All Windows NT–based applications follow similar conventions for arrangement of menus, style of dialog boxes, and keyboard and mouse use.

Windows NT browser system

Consists of a master browser, backup browser, and client systems. The master browser maintains the browse list—of all the available domains and servers—and periodically sends copies to the backup browsers. See also browse; master browser.

Windows NT Explorer

A program that enables you to view and manage the files and folders on your computer and make network connections to other shared resources, such as a hard disk on a server. Windows NT Explorer replaces Program Manager and File Manager, which were programs available in earlier versions of Windows NT. Program Manager and File Manager are still available, and can be started in the same way you start other Windows-based programs.

Windows NT file system (NTFS)

An advanced file system designed for use specifically within the Windows NT operating system. It supports file system recovery, extremely large storage media, long filenames, and various features for the POSIX subsystem. It also supports object-oriented applications by treating all files as objects with user-defined and system-defined attributes. See also POSIX.

Windows NT Server

A superset of Windows NT Workstation, Windows NT Server provides centralized management and security, fault tolerance, and additional connectivity. See also fault tolerance; Windows NT Workstation.

Windows NT Server Directory Services

A Windows NT protected subsystem that maintains the directory database and provides an application programming interface (API) for accessing the database. See also application programming interface (API); directory database.

Windows NT Server Services for Macintosh

A software component of Windows NT Server that allows Macintosh users access to the computer running Windows NT Server. The services provided with this component allow PC and Macintosh users to share files and resources, such as printers on the AppleTalk network or those attached to the Windows NT Server. See also File Server for Macintosh service; Print Server for Macintosh.

Windows NT Workstation

The portable, secure, 32-bit, preemptive multitasking member of the Microsoft Windows operating system family.

Windows Open Services Architecture (WOSA)

An open set of APIs for integrating Windows-based computers with back-end services on a broad range of vendor's systems. WOSA consists of an extensible set of APIs that enable Windows-based desktop applications to access available information without having to know anything about the type of network in use, the types of computers in the enterprise, or types of back-end services available. As a result, if the network computers or services change, the desktop applications built by using WOSA will not require rewriting. See also application programming interface (API).

Windows Sockets

See Sockets.

WINS

See Windows Internet Name Service.

workgroup

For Windows NT, a workgroup is a collection of computers that are grouped for viewing purposes. Each workgroup is identified by a unique name. See also domain.

working set

Every program running can use a portion of physical memory, its working set, which is the current number of physical memory bytes used by or allocated by a process.

workstation

Any networked Macintosh or PC using server resources. See also backup domain controller (BDC); member server; primary domain controller (PDC).

Workstation service

Provides network connections and communications.

World Wide Web (WWW)

The software, protocols, conventions, and information that enable hypertext and multimedia publishing of resources on different computers around the world. See also Hypertext Markup Language (HTML); Internet.

WOSA

See Windows Open Services Architecture.

WOW

Acronym for Win16 on Win32. The translation of Windows 3.1-based application calls to standard mode for RISC-based computers and 386 enhanced mode for x86-based computers.

wrap

To continue to the next line rather than stopping when the cursor reaches the end of the current line.

X

X.25

A recommendation published by the Comite Consultatif International de Telegraphique et Telephonique (CCITT) international communications standards organization that defines the connection between a terminal and a packet-switching network. An X.25 network is a type of packet-switching network that routes units of information (packets) as specified by X.25 and is used in public data communications networks. See also packet.

X.25 smart card

A hardware card with a PAD (packet assembler/disassembler) embedded in it. See also packet assembler/disassembler (PAD); X.25.

X.400 system

A messaging system that is compliant with the X.400 standards developed under the CCITT and the International Standards Organization (ISO).

XModem/CRC

Protocol for transmitting binary files that uses a cyclic redundancy check (CRC) to detect any transmission errors. Both computers must be set to transmit and receive eight data bits per character.

XOR

Short for exclusive OR. A Boolean operation in which the Windows NT Server stripe-sets-with-parity form of fault tolerance maintains an XOR of the total data to provide data redundancy. This enables the reconstruction of missing data (on a failed disk or sector) from the remaining disks in the stripe set with parity. See also fault tolerance; stripe sets with parity.

Z

zone

In the Macintosh environment, a zone is a logical grouping that simplifies browsing the network for resources, such as servers and printers. It is similar to a domain in Windows NT Server networking.

In a DNS (Domain Name System) database, a zone is a subtree of the DNS database that is administered as a single separate entity, a DNS name server. This administrative unit can consist of a single domain or a domain with subdomains. A DNS zone administrator sets up one or more name servers for the zone. See also domain; Domain Name System (DNS).

zone data file

A Domain Name System database for a zone in the DNS name space.

zone list

In the Macintosh environment, a zone list includes all the zones associated with a particular network. Not to be confused with Windows NT DNS zones.


PATHMAN.EXE: PathMan

Windows NT® Resource Kits

Copyright © Microsoft Corp. 1995 - 1997

Contents

What is PathMan?

What does PathMan do?

Pathman syntax

Pathman examples

Path abnormalities

Return value

What does PathMan do?

This command-line tool enables you to add or remove components of both the system and user paths. It can modify any number of paths in a single call and includes error checking that can handle path abnormalities such as repeated entries, adjacent semicolons, and missing entries.

Windows NT manages two different types of paths; the current user's path and the system path. Windows NT keeps a separate user path for every user on a system, but there is only one global system path. When a user logs on to a Windows NT machine, these two paths are combined to create the user's full path. For backward compatibility, Windows NT also loads path information from old AUTOEXEC.BAT files left in the root directory.

A non-administrative user can modify his or her own user path. But in order to modify the system path, the user of pathman must have Administrator privileges. Pathman does not manage information contained in old AUTOEXEC.BAT files.

Pathman also broadcasts a message to all top-level windows notifying them that the environment has changed. This causes many applications (like the system shell) to update their environments, thereby obtaining the modified path.

PathMan syntax

Pathman accepts four command line arguments:

/as path[;path[;path ...]]

Adds the semicolon-separated paths to the system path

/au path[;path[;path ...]]

Adds the semicolon-separated paths to the user path

/rs path[;path[;path ...]]

Removes the semicolon-separated paths from the system path

/ru path[;path[;path ...]]

Removes the semicolon-separated paths from the user path

The two add flags, /as and /au, will not add a path that already exists. The two remove flags, /rs and /ru, will do nothing if the path does not currently exist.

Pathman can accept multiple arguments in a single call, each identified by one of the four command line flags (/as, /au, /rs, /ru). Each flag can be added in any order as many times as desired. For each argument, Pathman can accept any number of paths to modify (represented above by path). Each path must be separated by a semicolon.

Once the path modifications have been made, Pathman broadcasts a message to all top-level windows notifying them that the environment has changed. This causes many applications (including the system shell) to update their environments, thereby obtaining the modified path.

Pathman examples

Example 1

pathman /au c:\temp;c:\users\name;d:\utils

In this example, the /au flag tells Pathman that the next set of semicolon separated paths should be added to the current user's path. All three paths (c:\temp, c:\users\name, and d:\utils) will be added to the user's path if they do not already exist.

Example 2

pathman /au c:\temp;c:\users\name;d:\utils /ru d:\data /as d:\data;c:\reskit

Aside from the additions to the current user's path, d:\data is removed form the current user's path and both d:\data and c:\reskit are added to the system path. Pathman can accept any number of path modifications this way.

Example 3

pathman /au c:\temp;c:\app\bin /rs %systemroot% /au c:\app2\bin

This command adds (c:\temp, c:\app\bin, and c:\app2\bin) to the user path and removes (%systemroot%) from the system path.

Path abnormalities

Pathman can handle many path abnormalities. These include:

  • Additional leading semicolons

  • Additional trailing semicolons

  • Multiple consecutive semicolons

  • Double path additions using /au or /as

  • Double path removal using /ru or /rs

  • Addition and removal of the same path (results in removal)

  • Addition of an already existing paths

  • Removal of a non-existing paths

    Pathman does not check the validity of new paths, however.

Return value

Pathman's return value is complicated, because the utility needs to return a lot of information in a single 32-bit value. In order to return status information for each of the four possible flags (/as /au /rs /ru) it accepts as arguments, Pathman treats the return value as four separate 8-bit bytes instead of one 32-bit integer. Each of the four bytes in the return value indicates what action was taken with respect to each of the four flags accepted by Pathman. The return value (wwxxyyzz) is broken down as follows:

byte

4 3 2 1

ww xx yy zz

byte 4 (ww)system path additions

byte 3(xx)user path additions

byte 2 (yy)system path removals

byte 1 (zz)user path removals

Each byte in the return code can have a value of:

0No changes were made.

1At least one change was made.

2An error occurred. No changes were made.

In Example 1:

pathman /au c:\temp;c:\users\name;d:\utils

if we assume that there were no errors and at least one of the paths was added to the user's path, we get a return value of (in hex followed by decimal in parentheses) :

0x00010000(65536)

In Example 2:

pathman /au c:\temp;c:\users\name;d:\utils /ru d:\data /as d:\data;c:\reskit

if we again assume that everything worked, we get a return value of:

0x01010001( 16842753)

If the user did not have Administrator privileges, the return value would have been:

0x02010001( 33619969)

If Pathman is called with invalid parameters, the return value is all errors:

0x02020202(33686018)


POSIX Utilities

POSIX.DOC

Microsoft® Windows NT™ Resource Kit--POSIX Utilities

Windows NT® Resource Kits

Copyright © Microsoft Corp. 1985-1997

This document contains important information about the POSIX utilities that is not included in the Windows NT Resource Kit online Help or printed documents.

Using Write to View This Document

If you enlarge the Write window to its maximum size, this document will be easier to read. To do so, click the Maximize button in the upper-right corner of the window. Or open the Control menu in the upper-left corner of the Write window (press ALT+SPACEBAR), and then choose the Maximize command.

To move through the document, press PAGE UP or PAGE DOWN or click the arrows at the top and bottom of the scroll bar along the right side of the Write window.

To print the document, choose the Print command from the File menu.

For Help on using Write, press F1.

To read other online documents, choose the Open command from the File menu.

Contents

This document contains information on these commands:

ar, page 2

cat, page 5

cc, page 6

chmod, page 21

cp, page 24

find, page 26

ln, page 30

ls, page 31

make, page 34

mkdir, page 42

mv, page 43

rm, page 44

rmdir, page 45

sh, page 46

touch, page 58

wc, page 59

For more details about the ar, cc, devsrv, find, ld, make, sh, and vi commands, see RKTOOLS.HLP in the Resource Kit program group.

NAME

ar -- create and maintain library archives

SYNOPSIS

ar -d[-Tv] archive file ... ar -m[-Tv] archive file ... ar -m[-abiTv] position archive file ... ar -p[-Tv] archive [file ...] ar -q[-cTv] archive file ... ar -r[-cuTv] archive file ... ar -r[-abciuTv] position archive file ... ar -t[-Tv] archive [file ...] ar -x[-ouTv] archive [file ...]

DESCRIPTION

The ar utility creates and maintains groups of files combined into an archive. Once an archive has been created, new files can be added and existing files can be extracted, deleted, or replaced.

Files are named in the archive by a single component; for example, if a file referenced by a path containing a slash ("/") is archived, it will be named by the last component of that path. When matching paths are listed on the command line against file names stored in the archive, only the last component of the path will be compared.

All information and error messages use the path listed on the command line, if any was specified; otherwise the name in the archive is used. If multiple files in the archive have the same name and paths are listed on the command line to "select" archive files for an operation, only the first file with a matching name will be selected.

The normal use of are is for creating and maintaining libraries that are suitable for use with the loader (see ld) although it is not restricted to this purpose. The options follow.

-a

A positioning modifier used with the options -r and -m. The files are entered or moved after the archive member position, which must be specified.

-b

A positioning modifier used with the options -r and -m. The files are entered or moved before the archive member position, which must be specified.

-c

Whenever an archive is created, an information message to that effect is written to standard error. If the -c option is specified, ar creates the archive silently.

-d

Deletes the specified archive files.

-i

A positioning modifier used with the options -r and -m. The files are entered or moved before the archive member position, which must be specified. (Identical to the -b option.)

-m

Moves the specified archive files within the archive. If one of the options -a, -b, or -i is specified, the files are moved before or after the position file in the archive. If none of those options are specified, the files are moved to the end of the archive.

-o

Sets the access and modification times of extracted files to the modification time of the file when it was entered into the archive. This will fail if the user is not the owner of the extracted file or the superuser.

-p

Writes the contents of the specified archive files to the standard output. If no files are specified, the contents of all the files in the archive are written in the order they appear in the archive.

-q

(Quickly) appends the specified files to the archive. If the archive does not exist, a new archive file is created. When creating a large archive piece-by-piece, this is much faster than the -r option, as no checking is done to see if the files already exist in the archive.

-r

Replaces or adds the specified files to the archive. If the archive does not exist, a new archive file is created. Files that replace existing files do not change the order of the files within the archive. New files are appended to the archive unless one of the options -a, -b, or -i is specified.

-T

Selects and/or names archive members using only the first 15 characters of the archive member or command line file name. The historic archive format had 16 bytes for the name, but some historic archiver and loader implementations were unable to handle names that used the entire space. This means that file names that are not unique in their first 15 characters can subsequently be confused. A warning message is printed to the standard error output if any file names are truncated.

-t

Lists the specified files in the order in which they appear in the archive, each on a separate line. If no files are specified, all files in the archive are listed.

-u

Updates files. When used with the -r option, files in the archive will be replaced only if the disk file has a newer modification time than the file in the archive. When used with the -x option, files in the archive will be extracted only if the archive file has a newer modification time than the file on disk.

-v

Provides verbose output. When used with the -d, -m, -q, or -x options, ar gives a file-by-file description of the archive modification. This description consists of three, white-space separated fields: the option letter, a dash ("-"), and the file name. When used with the -r option, ar displays the description as above, but the initial letter is an "a" if the file is added to the archive and an "r" if the file replaces a file already in the archive.

When used with the -p option, the name of each printed file is written to the standard output before the contents of the file (preceded by a single newline character and followed by two newline characters, enclosed in less-than ("<") and greater-than (">") characters).

When used with the -t option, ar displays an "ls -l" style listing of information about the members of the archive. This listing consists of eight, white-space separated fields: the file permissions, the decimal user and group ID's separated by a single slash ("/"), the file size (in bytes), the file modification time (in the date(1) format "%b %e %H:%M %Y"), and the name of the file.

-x

Extracts the specified archive members into the files named by the command line arguments. If no members are specified, all the members of the archive are extracted into the current directory.

If the file does not exist, it is created; if it does exist, the owner and group will be unchanged. The file access and modification times are the time of the extraction (also see the -o option). The file permissions will be set to those of the file when it was entered into the archive; this will fail if the user is not the owner of the extracted file or the superuser.

The ar utility exits 0 on success, and >0 if an error occurs.

ENVIRONMENT

TMPDIR

The pathname of the directory to use when creating temporary files.

FILES

/tmp

default temporary file directory

ar.XXXXXX

temporary file names

COMPATIBILITY

By default, ar writes archives that may be incompatible with historic archives, as the format used for storing archive members with names longer than 15 characters has changed. This implementation of ar is backward-compatible with previous versions of ar in that it can read and write (using the -T option) historic archives. The -T option is provided for compatibility only and will be deleted in a future release.

STANDARDS

The ar utility is expected to offer a superset of the POSIX 1003.2 functionality.

NAME

cat -- concatenate and print files

SYNOPSIS

cat [-b] [-e] [-n] [-s] [-t] [-u] [-v] [file ...]

DESCRIPTION

The cat utility reads files sequentially, writing them to the standard output. The file operands are processed in command line order. A single dash represents standard input. The options follow.

-b

Implies the -n option but does not number blank lines.

-e

Implies the -v option, and displays a dollar sign ("$") at the end of each line as well.

-n

Numbers the output lines, starting at 1.

-s

Squeezes multiple adjacent empty lines, causing the output to be single-spaced.

-t

Implies the -v option and displays tab characters as "^I" as well.

-u

The -u option guarantees that the output is unbuffered.

-v

Displays nonprinting characters so they are visible. Control characters print line "^X" for control-X; the delete character (octal 0177) prints as "^?". Non-ASCII characters (with the high bit set) are printed as "M-" (for meta) followed by the character for the low 7 bits.

The cat utility exits 0 on success and >0 if an error occurs.

BUGS

Because of the shell language mechanism used to perform output redirection, the command

cat file1 file2 > file1

will cause the original data in file1 to be destroyed!

HISTORY

A cat command appeared in Sixth Edition AT&T UNIX.

NAME

cc -- GNU project C Compiler

SYNOPSIS

cc [options] file ...

DESCRIPTION

cc is a version of the GNU C compiler. It accepts a dialect of ANSI C with extensions; this dialect is different from the dialect used in 4.3 BSD and earlier distributions. The -traditional flag causes the compiler to accept a dialect of extended Classic C, much like the C of these earlier distributions. If you are not already familiar with ANSI C and its new features, you will want to build your software with

-traditional.

DIFFERENCES

Most older C compiler flags are supported by cc. Three that are not are -go, to generate symbol tables for the unsupported sdb debugger; -f, for single precision floating point in expressions (which is now the default); and -t, for alternate compiler passes.

The differences between ANSI C and Classic C dialects are too numerous to describe here in detail. The following quick summary is intended to make users aware of potential subtle problems when converting Classic C code to ANSI C.

The most obvious change is the pervasive use of function prototypes. Under the ANSI C dialect, the compiler checks number and type of arguments to C library functions when standard header files are included; calls that fail to match will yield errors. A subtle consequence of adding prototype declarations is that user code which inadvertently redefines a C library function may break; for example it is no longer possible to write an abort function that takes different parameters or returns a different value from the standard abort, when including standard header files.

Another issue with prototypes is that functions which take different parameter types no longer have the same type; function pointers now differ by parameter types as well as return types. Variable argument lists are handled differently; the old varargs(3) package is obsolete; it was replaced by stdarg(3), which unfortunately is not completely compatible. A subtle change in type promotion can be confusing: small unsigned types are now widened into signed types rather than unsigned types. A similar problem can occur with the sizeof operator, which now yields an unsigned type rather than a signed type. One common problem is due to a change in scoping: external declarations are now scoped to the block they occur in, so a declaration for (say) errno inside one block will no longer declare it in all subsequent blocks. The syntax for braces in structure initializations is now a bit stricter, and it is sometimes necessary to add braces to please the compiler.

Two very subtle and sometimes very annoying features apply to constant strings and to the longjmp(3) function. Constant strings in the ANSI dialect are read-only; attempts to alter them cause protection violations. This ANSI feature permits the compiler to coalesce identical strings in the same source file; and, since the read-only part of a binary is sharable, it saves space when multiple copies of a binary are running at the same time. The most common difficulty with read-only strings lies with the use of the mktemp function, which in the past often altered a constant string argument. It is now necessary to copy a constant string before it may be altered. The longjmp function may now destroy any register or stack variable in the function that made the corresponding call to the setjmp function; to protect a local variable, the new ANSI volatile modifier must be used. This often leads to confusing situations upon 'return' from setjmp. The compiler has extended warning flags for dealing with read-only strings and setjmp, but these are not very effective.

If your code has problems with any of these ANSI features, you will probably want to use -traditional. Even with -traditional, there are some differences between this dialect of Classic C and the dialect supported on older distributions.

There are at least two differences that are a consequence of the fact that cc uses an ANSI C style grammar for both traditional and ANSI modes. The old C dialect permitted a typedef to replace a simple type in the idiom "unsigned type"; this cc treats such forms as syntax errors. The old C dialect also permitted formal parameters to have the same names as typedef types; the current dialect does not.

Some questionable or illegal practices that were supported in the old C dialect are not supported by

-traditional: noncomment text at the end of a "#include" preprocessor control line is an error, not ignored; compound assignment operators must not contain white space, e.g. "* =" is not the same as "*="; the last member declaration in a structure or union must be terminated by a semicolon; it is not possible to "switch" on function pointers; more than one occurrence of "#else" at the same level in a preprocessor "#if" clause is an error, not ignored.

Some truly ancient C practices are no longer supported. The idiom of declaring an anonymous structure and using its members to extract fields from other structures or even nonstructures is illegal. Integers are not automatically converted to pointers when they are dereferenced. The -traditional dialect does not retain the so-called "old-fashioned" assignment operators (with the "=" preceding rather than following the operator) or initializations (with no "=" between initializer and initializee).

WARNING

The rest of this topic is an extract of the documentation of the GNU C compiler and is limited to the meaning of the options. It is not kept up to date. If you want to be certain of the information below, check it in the manual "Using and Porting GCC". Refer to the Info file gcc.info or the DVI file gcc.dvi, which are made from the Texinfo source file gcc.texinfo.

The GNU C compiler uses a command syntax much like the UNIX C compiler. The cc program accepts options and file names as operands. Multiple single-letter options may not be grouped: -dr is very different from -d -r.

When you invoke GNU CC, it normally does preprocessing, compiling, assembly, and linking. File names which end in .c are taken as C source to be preprocessed and compiled; file names ending in .i are taken as preprocessor output to be compiled; compiler output files plus any input files with names ending in .s are assembled; then the resulting object files, plus any other input files, are linked to produce an executable.

Command options allow you to stop this process at an intermediate stage. For example, the -c option says not to run the linker. Then the output consists of object files output by the assembler.

Other command options are passed on to one stage of processing. Some options control the preprocessor and others the compiler itself. Yet other options control the assembler and linker; these are not documented here, but you rarely need to use any of them.

OPTIONS

Here are the options to control the overall compilation process, including those that say whether to link, whether to assemble, and so on.

-o file

Places output in file file. This applies regardless of whatever sort of output is being produced -- whether it is an executable file, an object file, an assembler file, or preprocessed C code.

If -o is not specified, the default is to put an executable file in a.out, the object file source.c in source.o, an assembler file in source.s, and preprocessed C on standard output.

-c

Compiles or assembles the source files, but does not link. Produces object files with names made by replacing .c or .s with .o at the end of the input file names. Does nothing at all for object files specified as input.

-S

Compiles into assembler code but does not assemble. The assembler output file name is made by replacing .c with .s at the end of the input file name. Does nothing at all for assembler source files or object files specified as input.

-E

Runs only the C preprocessor. Preprocess all the C source files specified and outputs the results to standard output.

-v

Compiler driver program prints the commands it executes as it runs the preprocessor, compiler proper, assembler, and linker. Some of these are directed to print their own version numbers.

-pipe

Uses pipes rather than temporary files to communicate between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the GNU assembler has no trouble.

-B prefix

Compiler driver program tries prefix as a prefix for each program it tries to run. These programs are cpp, cc1, as, and ld.

For each subprogram to be run, the compiler driver first tries the -B prefix, if any. If that name is not found, or if -B was not specified, the driver tries a standard prefix (which currently is /usr/libexec/). If this does not result in a file name that is found, the unmodified program name is searched for using the directories specified in your PATH environment variable.

You can get a similar result from the environment variable GCC_EXEC_PREFIX; if it is defined, its value is used as a prefix in the same way. If both the -B option and the GCC_EXEC_PREFIX variable are present, the -B option is used first and the environment variable value is used second.

-b prefix

The argument prefix is used as a second prefix for the compiler executables and libraries. This prefix is optional: the compiler tries each file first with it, then without it. This prefix follows the prefix specified with -B or the default prefixes.

Thus, -bvax- -Bcc/ in the presence of environment variable GCC_EXEC_PREFIX with definition /u/foo/ causes GNU CC to try the following file names for the preprocessor executable.

cc/vax-cpp cc/cpp /u/foo/vax-cpp /u/foo/cpp /usr/libexec/vax-cpp /usr/libexec/cpp

The following options control the details of C compilation itself.

-ansi

Supports all ANSI standard C programs.

This turns off certain features of GNU C that are incompatible with ANSI C, such as the asm, inline, and typeof keywords and predefined macros such as unix and vax that identify the type of system you are using. It also enables the undesirable and rarely used ANSI trigraph feature.

The alternate keywords __asm__, __inline__, and __typeof__ continue to work despite -ansi. You would not want to use them in an ANSI C program, of course; but it useful to put them in header files that might be included in compilations done with -ansi. Alternate predefined macros such as __unix__ and __vax__ are also available, with or without -ansi.

The -ansi option does not cause non-ANSI programs to be rejected gratuitously. For that,

-pedantic is required in addition to -ansi.

The macro __STRICT_ANSI__ is predefined when the -ansi option is used. Some header files may notice this macro and refrain from declaring certain functions or defining certain macros that the ANSI standard does not call for; this is to avoid interfering with any programs that might use these names for other things.

-traditional

Attempts to support some aspects of traditional C compilers. Specifically:

* All extern declarations take effect globally even if they are written inside of a function definition. This includes implicit declarations of functions.

* The keywords typeof, inline, signed, const, and volatile are not recognized.

* Comparisons between pointers and integers are always allowed.

* Integer types unsigned short and unsigned char promote to unsigned int.

* Out-of-range floating point literals are not an error.

* All automatic variables not declared register are preserved by longjmp(3C). Ordinarily, GNU C follows ANSI C: automatic variables not declared volatile may be clobbered.

* In the preprocessor, comments convert to nothing at all, rather than to a space. This allows traditional token concatenation.

* In the preprocessor, macro arguments are recognized within string constants in a macro definition (and their values are stringified, though without additional quote marks, when they appear in such a context). The preprocessor always considers a string constant to end at a newline.

* The predefined macro __STDC__ is not defined when you use -traditional, but __GNUC__ is (since the GNU extensions which __GNUC__ indicates are not affected by -traditional). If you need to write header files that work differently (depending upon whether -traditional is in use) you can distinguish four situations by testing both of these predefined macros: GNU C, traditional GNU C, other ANSI C compilers, and other old C compilers.

-O

Optimizes. Optimizing compilation takes somewhat more time and a lot more memory for a large function.

Without -O, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent--if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.

Without -O, only variables declared register are allocated in registers. The resulting compiled code is a little worse than produced by PCC without -O.

With -O, the compiler tries to reduce code size and execution time.

Some of the -f options described below turn specific kinds of optimization on or off.

-g

Produces debugging information in the operating system's native format (for dbx or sdb). gdb also can work with this debugging information.

Unlike most other C compilers, GNU CC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results--some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops. Nevertheless, it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

-w

Inhibits all warning messages.

-W

Prints extra warning messages for the following events.

* An automatic variable is used without first being initialized.

These warnings are possible only in optimizing compilation, because they require data flow information that is computed only when optimizing. If you do not specify -O, you simply will not get these warnings.

These warnings occur only for variables that are candidates for register allocation. Therefore, they do not occur for a variable that is declared volatile; or whose address is taken; or whose size is other than 1, 2, 4 or 8 bytes. Also, they do not occur for structures, unions, or arrays, even when they are in registers.

Note that there may be no warning about a variable that is used only to compute a value that itself is never used, because such computations may be deleted by data flow analysis before the warnings are printed.

These warnings are made optional because GNU CC is not smart enough to see all the reasons why the code might be correct despite appearing to have an error. Here is one example of how this can happen:

{ \ \ int x; \ \ switch (y) \ \ \ \ { \ \ \ \ case 1: x = 1; \ \ \ \ \ \ break; \ \ \ \ case 2: x = 4; \ \ \ \ \ \ break; \ \ \ \ case 3: x = 5; \ \ \ \ } \ \ foo (x); }

If the value of y is always 1, 2, or 3, then x is always initialized; however, GNU CC does not know this. The following example demonstrates another common case.

{ \ \ int save_y; \ \ if (change_y) save_y = y, y = new_y; \ \ ... \ \ if (change_y) y = save_y; }

This has no bug because save_y is used only if it is set.

Some spurious warnings can be avoided if you declare as volatile all the functions you use that never return.

* A nonvolatile automatic variable might be changed by a call to longjmp(3C). These warnings are possible only in optimizing compilation.

The compiler sees only the calls to setjmp(3C). It cannot know where longjmp(3C) will be called; in fact, a signal handler could call it at any point in the code. As a result, you may get a warning even when there is, in fact, no problem because longjmp(3C) cannot, in fact, be called at the place that would cause a problem.

* A function can return either with or without a value. (Falling off the end of the function body is considered returning without a value.) For example, the following function would evoke such a warning.

foo (a) { \ \ if (a > 0) \ \ \ \ return a; }

Spurious warnings can occur because GNU CC does not realize that certain functions (including abort(3C) and longjmp(3C)) will never return.

* An expression statement contains no side effects.

In the future, other useful warnings also may be enabled by this option.

-Wimplicit

Warns whenever a function is implicitly declared.

-Wreturn-type

Warns whenever a function is defined with a return-type that defaults to int. Also warns about any return statement with no return-value in a function whose return-type is not void.

-Wunused

Warns whenever a local variable is unused aside from its declaration and whenever a function is declared static but never defined.

-Wswitch

Warns whenever a switch statement has an index of enumeral type and lacks a case for one or more of the named codes of that enumeration. (The presence of a default label prevents this warning.) case labels outside the enumeration range also provoke warnings when this option is used.

-Wcomment

Warns whenever a comment-start sequence /* appears in a comment.

-Wtrigraphs

Warns if any trigraphs are encountered (assuming they are enabled).

-Wall

All of the above -W options combined. These are all the options that pertain to usage which we do not recommend and that we believe is always easy to avoid, even in conjunction with macros.

The other -W... options below are not implied by -Wall because certain kinds of useful macros are almost impossible to write without causing those warnings.

-Wshadow

Warns whenever a local variable shadows another local variable.

-Wid-clash-len

Warns whenever two distinct identifiers match in the first len characters. This may help you prepare a program that will compile with certain obsolete, brain-damaged compilers.

-Wpointer-arith

Warns about anything that depends upon the size of a function type or of void. GNU C assigns these types a size of 1 for convenience in making calculations with void * pointers and pointers to functions.

-Wcast-qual

Warns whenever a pointer is cast so as to remove a type qualifier from the target type. For example, warns if a const char * is cast to an ordinary char *.

-Wwrite-strings

Gives string constants the type const char[length] so that copying the address of one into a non-const char * pointer will get a warning. At compile time, these warnings will help you find code that can try to write into a string constant, but only if you have been very careful about using const in declarations and prototypes. Otherwise, it will just be a nuisance; this is why we did not make

-Wall request these warnings.

-p

Generates extra code to write profile information suitable for the analysis program prof(1).

-pg

Generates extra code to write profile information suitable for the analysis program gprof(1).

-a

Generates extra code to write profile information for basic blocks, suitable for the analysis program tcov(1). Eventually, GNU gprof(1) should be extended to process this data.

-l library

Searchs a standard list of directories for a library named library, which is actually a file named lib library.a. The linker uses this file as if it had been specified precisely by name.

The directories searched include several standard system directories plus any that you specify

with -L.

Normally, the files found this way are library files--archive files whose members are object files. The linker handles an archive file by scanning through it for members that define symbols which have, so far, been referenced but not defined. But, if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l searches several directories.

-L dir

Adds directory dir to the list of directories to be searched for -l.

-nostdlib

Does not use the standard system libraries and startup files when linking. Only the files you specify (plus gnulib) will be passed to the linker.

-m machinespec

This is a machine-dependent option that specifies something about the type of target machine. These options are defined by the macro TARGET_SWITCHES in the machine description. The default for the options is also defined by that macro, which enables you to change the defaults.

The following -m options are defined in the 68000 machine description:

-m68020

-mc68020

Generates output for a 68020 (rather than a 68000). This is the default if you use the unmodified sources.

-m68000

-mc68000

Generates output for a 68000 (rather than a 68020).

-m68881

Generates output containing 68881 instructions for floating point. This is the default if you use the unmodified sources.

-mfpa

Generates output containing Sun FPA instructions for floating point.

-msoft-float

Generates output containing library calls for floating point.

-mshort

Considers type int to be 16 bits wide, like short int.

-mnobitfield

Does not use the bit-field instructions. -m68000 implies -mnobitfield.

-mbitfield

Does use the bit-field instructions. -m68020 implies -mbitfield. This is the default if you use the unmodified sources.

-mrtd

Uses a different function-calling convention, in which functions that take a fixed number of arguments return with the rtd instruction, which pops their arguments while returning. This saves one instruction in the caller since there is no need to pop the arguments there.

This calling convention is incompatible with the one normally used on UNIX, so you cannot use it if you need to call libraries compiled with the UNIX compiler.

Also, you must provide function prototypes for all functions that take variable numbers of arguments (including printf(3S)); otherwise incorrect code will be generated for calls to those functions.

In addition, seriously incorrect code will result if you call a function with too many arguments. (Normally, extra arguments are harmlessly ignored.)

The rtd instruction is supported by the 68010 and 68020 processors but not by the 68000.

The following -m options are defined in the Vax machine description.

-munix

Does not output certain jump instructions (aobleq and so on) that the UNIX assembler for the Vax cannot handle across long ranges.

-mgnu

Does output those jump instructions, on the assumption that you will assemble with the GNU assembler.

-mg

Outputs code for g-format floating point numbers instead of d-format.

The following -m switches are supported on the Sparc.

-mfpu

Generates output containing floating point instructions. This is the default if you use the unmodified sources.

-msoft-float

Generates output containing library calls for floating point.

-mno-epilogue

Generates separate return instructions for return statements. This has both advantages and disadvantages.

The following -m options are defined in the Convex machine description.

-mc1

Generates output for a C1. This is the default when the compiler is configured for a C1.

-mc2

Generates output for a C2. This is the default when the compiler is configured for a C2.

-margcount

Generates code that puts an argument count in the word preceding each argument list. Some nonportable Convex and Vax programs need this word. (Debuggers do not; this information is in the symbol table.)

-mnoargcount

Omits the argument count word. This is the default if you use the unmodified sources.

-f flag

Specifies machine-independent flags. Most flags have both positive and negative forms; for example, the negative form of -ffoo would be -fno-foo. In the table below, only one of the forms is listed--the one that is not the default. You can figure out the other form by either removing no- or adding it.

-fpcc-struct-return

Uses the same convention for returning struct and union values that is used by the usual C compiler on your system. This convention is less efficient for small structures; and, on many machines, it fails to be reentrant. However, it has the advantage of allowing intercallability between GCC-compiled code and PCC-compiled code.

-ffloat-store

Does not store floating-point variables in registers. This prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a double is supposed to have.

For most programs, the excess precision does only good; however, a few programs rely upon the precise definition of IEEE floating point. Use -ffloat-store for such programs.

-fno-asm

Does not recognize asm, inline, or typeof as a keyword. These words may then be used as identifiers. You can use __asm__, __inline__, and __typeof__ instead.

-fno-defer-pop

Always pops the arguments to each function call as soon as that function returns. Normally, the compiler (when optimizing) lets arguments accumulate on the stack for several function calls and pops them all at once.

-fstrength-reduce

Optimizes loop strength reduction and eliminates iteration variables.

-fcombine-regs

Allows the combine pass to combine an instruction that copies one register into another. This might or might not produce better code when used in addition to -O.

-fforce-mem

Forces memory operands to be copied into registers before doing arithmetic on them. This may produce better code by making all memory references potential common subexpressions. When they are not common subexpressions, instruction combination should eliminate the separate register-load.

-fforce-addr

Forces memory address constants to be copied into registers before doing arithmetic on them. This may produce better code just as -fforce-mem may.

-fomit-frame-pointer

Does not keep the frame pointer in a register for functions that do not need one. This avoids the instructions to save, set up, and restore frame pointers. It also makes an extra register available in many functions. It also makes debugging impossible.

On some machines, such as the Vax, this flag has no effect because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it does not exist. The machine-description macro FRAME_POINTER_REQUIRED controls whether a target machine supports this flag.

-finline-functions

Integrates all simple functions into their callers. The compiler heuristically decides which functions are simple enough to be worth integrating in this way.

If all calls to a given function are integrated and the function is declared static, then the function is normally not output as assembler code in its own right.

-fcaller-saves

Enables values to be allocated in registers that will be clobbered by function calls, by emitting extra instructions to save and restore the registers around such calls. Such allocation is done only when it seems to result in better code than would otherwise be produced.

This option is enabled by default on certain machines, usually those that have no call-preserved registers to use instead.

-fkeep-inline-functions

Outputs a separate run-time callable version of the function, even if all calls to a given function are integrated and the function is declared static.

-fwritable-strings

Stores string constants in the writable data segment and does not uniquize them. This is for compatibility with old programs that assume they can write into string constants. Writing into string constants is a very bad idea; constants should be constant.

-fcond-mismatch

Allows conditional expressions with mismatched types in the second and third arguments. The value of such an expression is void.

-fno-function-cse

Does not put function addresses in registers; instead, it makes each instruction that calls a constant function contain the function's address explicitly.

This option results in less efficient code, but some strange hacks that alter the assembler output may be confused by the optimizations performed when this option is not used.

-fvolatile

Considers all memory references through pointers to be volatile.

-fshared-data

Requests that the data and non-const variables of this compilation be shared data rather than private data. The distinction makes sense only on certain operating systems, where shared data is shared between processes running the same program, while private data exists in one copy per process.

-funsigned-char

Lets the type char be the unsigned, like unsigned char.

Each kind of machine has a default for what char should be. It is either like unsigned char by default or like signed char by default. (Actually, at present, the default is always signed.)

The type char is always a distinct type from either signed char or unsigned char, even though its behavior is always just like one of those two.

Note that this is equivalent to -fno-signed-char, which is the negative form of -fsigned-char.

-fsigned-char

Lets the type char be signed, like signed char.

Note that this is equivalent to -fno-unsigned-char, which is the negative form of -funsigned-char.

-fdelayed-branch

If supported for the target machine, attempts to reorder instructions to exploit instruction slots available after delayed branch instructions.

-ffixed-reg

Treats the register named reg as a fixed register; generated code should never refer to it (except perhaps as a stack pointer, frame pointer, or in some other fixed role).

reg must be the name of a register. The register names accepted are machine-specific and are defined in the REGISTER_NAMES macro in the machine description macro file.

This flag does not have a negative form, because it specifies a three-way choice.

-fcall-used-reg

Treats the register named reg as an allocatable register that is clobbered by function calls. It may be allocated for temporaries or variables that do not live across a call. Functions compiled this way will not save and restore the register reg.

Use of this flag for a register that has a fixed pervasive role in the machine's execution model, such as the stack pointer or frame pointer, will produce disastrous results.

This flag does not have a negative form, because it specifies a three-way choice.

-fcall-saved-reg

Treats the register named reg as an allocatable register saved by functions. It may be allocated even for temporaries or variables that live across a call. Functions compiled this way will save and restore the register reg if they use it.

Use of this flag for a register that has a fixed pervasive role in the machine's execution model, such as the stack pointer or frame pointer, will produce disastrous results.

A different sort of disaster will result from the use of this flag for a register in which function values may be returned.

This flag does not have a negative form, because it specifies a three-way choice.

-d letters

Says to make debugging dumps at times specified by letters. The following list defines the possible letters.

rDump after RTL generation.

j Dump after first jump optimization.

J Dump after last jump optimization.

s Dump after CSE (including the jump optimization that sometimes follows CSE).

L Dump after loop optimization.

f Dump after flow analysis.

c Dump after instruction combination.

l Dump after local register allocation.

g Dump after global register allocation.

d Dump after delayed branch scheduling.

m Print statistics on memory usage, at the end of the run.

-pedantic

Issues all the warnings demanded by strict ANSI standard C; rejects all programs that use forbidden extensions.

Valid ANSI standard C programs should compile properly with or without this option (though a rare few will require -ansi). However, without this option, certain GNU extensions and traditional C features are supported as well. With this option, they are rejected. There is no reason to use this option; it exists only to satisfy pedants.

-pedantic does not cause warning messages for use of the alternate keywords whose names begin and end with __.

-static

On Suns running version 4, this prevents linking with the shared libraries. (-g has the same effect.)

These options control the C preprocessor, which is run on each C source file before actual compilation. If you use the '-E' option, nothing is done except C preprocessing. Some of these options make sense only together with '-E' because they request preprocessor output that is not suitable for actual compilation.

-C

Tells the preprocessor not to discard comments. Used with the -E option.

-I dir

Searchs directory dir for include files.

-I-

Searches any directories specified with -I options before the -I- option only for the case of #include "file"; they are not searched for #include <file>.

If additional directories are specified with -I options after the -I-, searches these directories for all #include directives. (Ordinarily all -I directories are used this way.)

In addition, the -I- option inhibits the use of the current directory as the first search directory for #include "file". Therefore, the current directory is searched only if it is requested explicitly with

-I.. Specifying both -I- and -I. allows you to control precisely which directories are searched before the current one and which are searched after.

-nostdinc

Does not search the standard system directories for header files. Only the directories you have specified with -I options (and the current directory, if appropriate) are searched.

Between -nostdinc and -I-, you can eliminate all directories from the search path except those you specify.

-M

Tells the preprocessor to output a rule suitable for make(1) describing the dependencies of each source file. For each source file, the preprocessor outputs one make-rule whose target is the object file name for that source file and whose dependencies are all the files #included in it. This rule may be a single line or, if it is long, may be continued with \\-newline.

-M implies -E.

-MM

Like -M but the output mentions only the user-header files included with #include "file". System header files included with #include <file> are omitted.

-MM implies -E.

-D macro

Defines macro macro with the empty string as its definition.

-D macro=defn

Defines macro macro as defn.

-U macro

Undefines macro macro.

-trigraphs

Supports ANSI C trigraphs. You do not want to know about this brain damage. The -ansi option also has this effect.

FILES

file.cC source file

file.sassembly language file

file.oobject file

a.outlink edited output

/tmp/cc*temporary files

/usr/libexec/cpppreprocessor

/usr/libexec/cclcompiler

/usr/lib/libgnulib.alibrary needed by GCC on some machines

/usr/lib/crt0.ostart-up routine

/usr/lib/libc.astandard C library, see intro(3)

/usr/includestandard directory for #include files

BUGS

Bugs should be reported to bug-gcc@prep.ai.mit.edu. Bugs actually tend to get fixed if they can be isolated, so it is in your interest to report them in such a way that they can be easily reproduced.

COPYING

Copyright © 1988 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English.

AUTHORS

See the GNU CC Manual for the contributors to GNU CC.

NAME

chmod -- change file modes

SYNOPSIS

chmod [-R] mode file ...

DESCRIPTION

The chmod utility modifies the file mode bits of the listed files as specified by the mode operand.

The options follow.

-R

Traverses a file hierarchy. For each file that is of type directory, chmod changes the mode of all files in the file hierarchy below it followed by the mode of the directory itself.

Symbolic links are not indirected through nor are their modes altered.

Only the owner of a file or the superuser is permitted to change the mode of a file.

The chmod utility exits 0 on success and >0 if an error occurs.

MODES

Modes may be absolute or symbolic. An absolute mode is an octal number constructed by oring the following values.

4000

set-user-ID-on-execution

2000

set-group-ID-on-execution

1000

sticky bit, see chmod(2)

0400

read by owner

0200

write by owner

0100

execute (or search for directories) by owner

0070

read, write, execute/search by group

0007

read, write, execute/search by others

The read, write, and execute/search values for group and others are encoded as described for owner.

The symbolic mode is described by the following grammar.

mode::= clause [, clause ...]

clause::= [who ...] [action ...] last_action

action::= op [perm ...]

last_action::= op [perm ...]

who ::= a | u | g | o

op::= + | - | =

perm::= r | s | t | w | X | x | u | g | o

The who symbols "u", "g", and "o" specify the user, group, and other parts of the mode bits, respectively. The who symbol "a" is equivalent to "ugo".

The perm symbols represent the portions of the mode bits, as follows.

r

The read bits.

s

The set-user-ID-on-execution and set-group-ID-on-execution bits.

t

The sticky bit.

w

The write bits.

x

The execute/search bits.

X

The execute/search bits if the file is a directory or if any of the execute/search bits are set in the original (unmodified) mode. Operations with the perm symbol "X" are only meaningful in conjunction with the op symbol "+"; it is ignored in all other cases.

The op symbols represent the operation performed, as follows.

+

If no value is supplied for perm, the "+" operation has no effect. If no value is supplied for who, each permission bit specified in perm (for which the corresponding bit in the file mode creation mask is clear) is set. Otherwise, the mode bits represented by the specified who and perm values are set.

-

If no value is supplied for perm, the "-" operation has no effect. If no value is supplied for who, the mode bits represented by perm are cleared for the owner, group, and other permissions. Otherwise, the mode bits represented by the specified who and perm values are cleared.

=

The mode bits specified by the who value are cleared; or, if no who value is specified, the owner, group, and other mode bits are cleared. Then, if no value is supplied for who, each permission bit specified in perm (for which the corresponding bit in the file mode creation mask is clear) is set. Otherwise, the mode bits represented by the specified who and perm values are set.

Each clause specifies one or more operations to be performed on the mode bits, and each operation is applied to the mode bits in the order specified.

Operations upon the other permissions only (specified by the symbol "o" by itself), in combination with the perm symbols "s" or "t", are ignored.

EXAMPLES

644

Makes a file readable by anyone and writable by the owner only.

go-w

Denies write permission to group and others.

=rw,+X

Sets the read and write permissions to the usual defaults but retain any execute permissions that are currently set.

+X

Makes a directory or file searchable/executable by everyone if it is already searchable/executable by anyone.

755

u=rwx,go=rx

u=rwx,go=u-w

Makes a file readable/executable by everyone and writeable by the owner only.

go=

Clears all mode bits for group and others.

g=u-w

Sets the group bits equal to the user bits but clears the group write bit.

BUGS

There is no perm option for the naughty bits.

STANDARDS

The chmod utility is expected to be POSIX 1003.2-compatible with the exception of the perm symbols t and X, which are not included in that standard.

NAME

cp -- copy files

SYNOPSIS

cp [-R] [-f] [-h] [-i] [-p] source_file target_file cp [-R] [-f] [-h] [-i] [-p] source_file ... target_directory

DESCRIPTION

In the first synopsis form, the cp utility copies the contents of the source_file to the target_file. In the second synopsis form, the contents of each named source_file is copied to thedestination target_directory. The names of the files themselves are not changed. If cp detects an attempt to copy a file to itself, the copy will fail.

The following options are available.

-R

If source_file designates a directory, cp copies the directory and the entire subtree connected at that point. This option also causes symbolic links to be copied, rather than indirected through, and for cp to create special files rather than copying them as normal files. Created directories have the same mode as the corresponding source directory, unmodified by the process' umask.

-f

For each existing destination pathname, removes it and creates a new file, without prompting for confirmation regardless of its permissions. (The -i option is ignored if the -f option is specified.)

-h

Forces cp to follow symbolic links. Provided for the -R option, which does not follow symbolic links by default.

-i

Causes cp to write a prompt to standard error before copying a file that would overwrite an existing file. If the response from the standard input begins with the character "y'', the file is copied if permissions allow the copy.

-p

Causes cp to preserve in the copy as many of the modification times, access times, file modes, user IDs, and group IDs as allowed by permissions.

If the user ID and group ID cannot be preserved, no error message is displayed and the exit value is not altered.

If the source file has its set user ID bit on and the user ID cannot be preserved, the set user ID bit is not preserved in the copy's permissions. If the source file has its set group ID bit on and the group ID cannot be preserved, the set group ID bit is not preserved in the copy's permissions. If the source file has both the set user ID and set group ID bits on and either the user ID or group ID cannot be preserved, neither the set user ID nor the set group ID bits are preserved in the copy's permissions.

For each destination file that already exists, its contents are overwritten if permissions allow; but its mode, user ID, and group ID are unchanged.

If the destination file does not exist, the mode of the source file is used as modified by the file mode creation mask (see sh). If the source file has its set user ID bit on, that bit is removed unless both the source file and the destination file are owned by the same user.

If the source file has its set group ID bit on, that bit is removed unless both the source file and the destination file are in the same group and the user is a member of that group. If both the set user ID and set group ID bits are set, all of the above conditions must be fulfilled or both bits are removed.

Appropriate permissions are required for file creation or overwriting.

Symbolic links are followed unless the -R option is specified, in which case the link itself is copied.

cp exits 0 on success; >0 if an error occurred.

HISTORY

The cp command is expected to be POSIX 1003.2 compatible.

NAME

find -- walk a file hierarchy

SYNOPSIS

find [-d] [-s] [-X] [-x] [-f file] file ... expression

DESCRIPTION

find recursively descends the directory tree for each file listed, evaluating an expression (composed of the "primaries" and "operands" listed below) in terms of each file in the tree.

If file is a symbolic link referencing an existing file, the directory tree referenced by the link is descended instead of the link itself.

The options follow.

-d

The -d option causes find to perform a depth-first traversal; i.e., directories are visited in post-order and all entries in a directory will be acted upon before the directory itself. By default, find visits directories in preorder; i.e., before their contents. Note that the default is not a breadth-first traversal.

-f

The -f option specifies a file hierarchy for find to traverse. File hierarchies also may be specified as the operands immediately following the options.

-s

The -s option causes the file information and file type, returned for each symbolic link, to be those of the file referenced by the link, not the link itself. If the referenced file does not exist, the file information and type will be for the link itself.

-X

The -X option is a modification to permit find to be safely used in conjunction with xargs(1). If a file name contains any of the delimiting characters used by xargs, a diagnostic message is displayed on standard error and the file is skipped. The delimiting characters include single (" ' ") and double (" " ") quotes, backslash ("\"), space, tab, and newline characters.

-x

The -x option prevents find from descending into directories that have a device number different than that of the file from which the descent began.

PRIMARIES

-atime n

True, if the difference between the file last access time and the time find was started ( rounded up to the next full 24-hour period) is n 24-hour periods.

-ctime n

True, if the difference between the time of last change of file status information and the time find was started (rounded up to the next full 24-hour period) is n 24-hour periods.

-exec utility [argument ...] ;

True, if the program named utility returns a zero value as its exit status. Optional arguments may be passed to the utility. The expression must be terminated by a semicolon (";"). If the string "{}" appears anywhere in the utility name or the arguments, it is replaced by the pathname of the current file. utility will be executed from the directory from which IfIiInId was executed.

-fstype type

True, if the file is contained in a file system of type type. Currently supported types are "local", "mfs", "nfs", "pc", "rdonly", and "ufs". The types "local" and "rdonly" are not specific file system types. The former matches any file system physically mounted on the system where the find is being executed, and the latter matches any file system which is mounted read-only.

-group gname

True, if the file belongs to the group gname. If gname is numeric and there is no such group name, then gname is treated as a group id.

-inum n

True, if the file has inode number n.

-links n

True, if the file has n links.

-ls

This primary always evaluates to true. The following information for the current file is written to standard output: its inode number, size in 512-byte blocks, file permissions, number of hard links, owner, group, size in bytes, last modification time, and pathname. If the file is a block or character-special file, the major and minor numbers will be displayed instead of the size in bytes. If the file is a symbolic link, the pathname of the linked-to file will be displayed preceded by "->". The format is identical to that produced by "ls -dgils".

-mtime n

True, if the difference between the file last modification time and the time find was started (rounded up to the next full 24-hour period) is n 24-hour periods.

-ok utility [argument ...] ;

The -ok primary is identical to the -exec primary with the exception that find requests user affirmation for executing the utility by printing a message to the terminal and reading a response. If the response is other than "y", the command is not executed and the value of the -ok expression is false.

-name pattern

True, if the last component of the pathname being examined matches pattern. Special shell pattern matching characters ("[", "]", "*", and "?") may be used as part of pattern. These characters may be matched explicitly by escaping them with a backslash ("\").

-newer file

True, if the current file has a more recent last modification time than file.

-nouser

True, if the file belongs to an unknown user.

-nogroup

True, if the file belongs to an unknown group.

-path pattern

True, if the pathname being examined matches pattern. Special shell pattern matching characters ("[", "]", "*", and "?") may be used as part of pattern. These characters may be matched explicitly by escaping them with a backslash ("\"). Slashes ("/") are treated as normal characters and do not need to be matched explicitly.

-perm mode

The mode may be either symbolic (see chmod) or an octal number. If the mode is symbolic, a starting value of zero is assumed and the mode sets or clears permissions without regard to the process' file mode creation mask. If the mode is octal, only bits 07777 (S_ISUID|S_ISGID|S_ISTXT|S_IRWXU|S_IRWXG|S_IRWXO) of the file's mode bits participate in the comparison. If the mode is preceded by a dash ("-"), this primary evaluates to true if at least all of the bits in the mode are set in the file's mode bits. If the mode is not preceded by a dash, this primary evaluates to true if the bits in the mode exactly match the file's mode bits. Note that the first character of a symbolic mode may not be a dash ("-").

-print

This primary always evaluates to true. It prints the pathname of the current file to standard output. The expression is appended to the user specified expression if neither -exec, -ls, nor -ok is specified.

-prune

This primary always evaluates to true. It causes find to not descend into the current file. Note that the -prune primary has no effect if the -d option was specified.

-size n[c]

True, if the file's size (rounded up in 512-byte blocks) is n. If n is followed by a "c", then the primary is true if the file's size is n bytes.

-type t

True, if the file is of the specified type. Possible file types follow.

bblock special

ccharacter special

ddirectory

fregular file

lsymbolic link

pFIFO

ssocket

-user uname

True, if the file belongs to the user uname. If uname is numeric and there is no such user name, then uname is treated as a user id.

All primaries which take a numeric argument allow the number to be preceded by a plus sign ("+") or a minus sign ("-"). A preceding plus sign means "more than n"; a preceding minus sign means "less than n"; and neither sign means "exactly n".

OPERATORS

The primaries may be combined using the following operators. The operators are listed in order of decreasing precedence.

(expression)

This evaluates to true if the parenthesized expression evaluates to true.

!expression

This is the unary NOT operator. It evaluates to true if the expression is false.

expression -and expression

expression expression

The -and operator is the logical AND operator. As it is implied by the juxtaposition of two expressions, it does not need to be specified. The expression evaluates to true if both expressions are true. The second expression is not evaluated if the first expression is false.

expression -or expression

The -or operator is the logical OR operator. The expression evaluates to true if either the first or the second expression is true. The second expression is not evaluated if the first expression is true.

All operands and primaries must be separate arguments to find. Primaries which themselves take arguments expect each argument to be a separate argument to find.

EXAMPLES

The following examples are shown as given to the shell.

find / \! -name "*.c" -print

Prints out a list of all the files whose names do not end in ".c".

find / -newer ttt -user wnj -print

Prints out a list of all the files owned by user "wnj" that are newer than the file "ttt".

find / \! \( -newer ttt -user wnj \)

Prints out a list of all the files that are not both newer than "ttt" and owned by "wnj".

find / \( -newer ttt -or -user wnj \)

Prints out a list of all the files that are either owned by "wnj" or that are newer than "ttt".

STANDARDS

The find utility syntax is a superset of the syntax specified by the POSIX 1003.2 standard.

The -s and -X options and the -inum and -ls primaries are extensions to POSIX 1003.2.

Historically, the -d, -s, and -x options were implemented using the primaries "-depth", "-follow", and "-xdev". These primaries always evaluated to true. As they were really global variables that took effect before the traversal began, some legal expressions could have unexpected results. An example is the expression "-print -o -depth". As -print always evaluates to true, the standard order of evaluation implies that -depth would never be evaluated. This is not the case.

The operator "-or" was implemented as "-o", and the operator "-and" was implemented as "-a".

Historic implementations of the -exec and -ok primaries did not replace the string "{}" in the utility name or the utility arguments if it had preceding or following nonwhitespace characters. This version replaces it no matter where in the utility name or arguments it appears.

BUGS

The special characters used by find also are special characters to many shell programs. In particular, the characters "*", "[", "]", "?", "(", ")", "!", "\", and ";" may have to be escaped from the shell.

As there is no delimiter separating options and file names or file names and the expression, it is difficult to specify files named "-xdev" or "!". These problems are handled by the -f option and the getopt(3) "--" construct.

NAME

ln -- make links

SYNOPSIS

ln [-s] source_file target_file ln [-s] source_file ... target_directory

DESCRIPTION

The ln utility creates a new directory entry (linked file), which inherits the same modes as the orginal file. It is useful for maintaining multiple copies of a file in many places at once--without the "copies"; instead, a link 'points' to the original copy. There are two types of links: hard links and symbolic links. How a link 'points' to a file is one of the differences between a hard or symbolic link.

Option available:

-s

Create a symbolic link.

By default ln makes hard links. A hard link to a file is indistinguishable from the original directory entry; any changes to a file are effective independent of the name used to reference the file. Hard links may not refer to directories (unless the proper incantations are supplied) and may not span file systems.

A symbolic link contains the name of the file to which it is linked. The referenced file is used when an open(2) operation is performed on the link. A stat(2) on a symbolic link will return the linked-to file; an lstat(2) must be done to obtain information about the link. The readlink(2) call may be used to read the contents of a symbolic link. Symbolic links may span file systems and may refer to directories.

Given one or two arguments, ln creates a link to an existing file source_file. If target_file is given, the link has that name; target_file may also be a directory in which to place the link; otherwise it is placed in the current directory. If only the directory is specified, the link will be made to the last component of source_file.

Given more than two arguments, ln makes links in target_directory to all the named source files. The links made will have the same name as the files being linked to.

HISTORY

An ln command appeared in Sixth Edition AT&T UNIX.

NAME

ls -- list directory contents.

SYNOPSIS

ls [-ACFLRTacdfgiklqrstu1] file ...

DESCRIPTION

For each operand that names a file of a type other than directory, ls displays its name as well as any requested, associated information. For each operand that names a file of type directory, ls displays the names of files contained within that directory, as well as any requested, associated information.

If no operands are given, the contents of the current directory are displayed. If more than one operand is given, nondirectory operands are displayed first; directory and nondirectory operands are sorted separately and in lexicographical order.

The following options are available.

-A

Lists all entries except for "." and "..". Always set for the superuser.

-C

Forces multicolumn output; this is the default when output is to a terminal.

-F

Displays a slash (/) immediately after each pathname that is a directory, an asterisk (*) after each that is executable, and an at sign (@) after each symbolic link.

-L

If argument is a symbolic link, lists the file or directory the link references rather than the link itself.

-R

Recursively lists subdirectories encountered.

-T

Displays complete time information for the file, including month, day, hour, minute, second, and year.

-a

Includes directory entries whose names begin with a dot (.).

-c

Uses time when file status was last changed for sorting or printing.

-d

Lists directories as plain files (not searched recursively).

-f

Does not sort output.

-g

Includes the group ownership of the file in a long "l" output "lg". If the group is not a known group name, the numeric ID is printed.

-i

For each file, prints the file's file serial number (inode number).

-k

Modifies the -s option, causing the sizes to be reported in kilobytes.

-l

(The lowercase letter "ell.") Lists in long format. (See below.) If the output is to a terminal, a total sum for all the file sizes is output on a line before the long listing.

-q

Forces printing of nongraphic characters in file names as the character '?'; this is the default when output is to a terminal.

-r

Reverses the order of the sort to get reverse lexicographical order or the oldest entries first.

-s

Displays the number of file system bytes actually used by each file, in units of 512, where partial units are rounded up to the next integer value. If the output is to a terminal, a total sum for all the file sizes is output on a line before the listing.

-t

Sort by time modified (most recently modified first) before sorting the operands by lexicographical order.

-u

Uses time of last access, instead of last modification of the file for sorting "t" or printing "l".

-1

(The numeric digit "one.") Forces output to be one entry per line. This is the default when output is not to a terminal.

The -1, -C, and -l options all override each other; the last one specified determines the format used.

The -c and -u options override each other; the last one specified determines the file time used.

By default, ls lists one entry per line to standard output; the exceptions are to terminals or when the

-C option is specified.

File information is displayed with one or more blanks separating the information associated with

the -i, -s, and -l options.

THE LONG FORMAT

If the -l option is given, the following information will be displayed: file mode, number of links, owner name, number of bytes in the file, abbreviated month, day-of-month file was last modified, hour file last modified, minute file last modified, and the pathname.

If the owner name is not a known user name, the numeric ID is displayed.

If the file is a character-special or block-special file, the major and minor device numbers for the file are displayed in the size field. If the file is a symbolic link, the pathname of the linked-to file is preceded

by "->".

The file mode printed under the -l option consists of the the entry type, owner permissions, and group permissions. The entry type character describes the type of file, as follows.

bBlock special file.

cCharacter special file.

dDirectory.

lSymbolic link.

sSocket link.

-Regular file.

The next three fields are three characters each: owner permissions, group permissions, and other permissions. Each field has three character positions.

If r, the file is readable; if -, it is not readable.

If w, the file is writable; if -, it is not writable.

The first of the following applies.

S If in the owner permissions, the file is not executable and set-user-ID mode is set. If in the group permissions, the file is not executable and set-group-ID mode is set.

s If in the owner permissions, the file is executable and set-user-ID mode is set. If in the group permissions, the file is executable and set-group-ID mode is set.

x The file is executable or the directory is searchable.

- The file is neither readable, writeable, exectutable, nor set-user-ID nor set-group-ID mode nor sticky. (See below.)

These next two apply only to the third character in the last group (other permissions).

T The sticky bit is set (mode 1000) but is not executable nor contains search permission. (See chmod(1) or sticky(8).)

t The sticky bit is set (mode 1000) and is searchable or executable. (See chmod(1) or sticky(8).)

The ls utility exits 0 on success, and >0 if an error occurs.

ENVIRONMENT

The following environment variables affect the execution of ls:

COLUMNS

If this variable contains a string representing a decimal integer, it is used as the column position width for displaying multiple- text-column output. The ls utility calculates how many pathname text columns to display based on the width provided. (See -C.)

HISTORY

An ls command appeared in Sixth Edition AT&T UNIX.

NAME

make -- maintain program dependencies

SYNOPSIS

make [-eiknqrstv] [-D variable] [-d flags] [-f makefile] [-I directory] [-j max_jobs] [variable=value ...] target ...

DESCRIPTION

make is a program designed to simplify the maintenance of other programs. Its input is a list of specifications as to the files upon which programs and other files depend. If the file "makefile" exists, it is read for this list of specifications. If it does not exist, the file "Makefile" is read. If the file ".depend" exists, it is read. This manual page is intended as a reference document only.

The options follow.

-D variable

Defines variable to be 1, in the global context.

-d flags

Turns on debugging and specifies which portions of make are to print debugging information. flags is one or more of the following:

A Prints all possible debugging information; equivalent to specifying all of the debugging flags.

a Prints debugging information about archive searching and caching.

c Prints debugging information about conditional evaluation.

d Prints debugging information about directory searching and caching.

g1 Prints the input graph before making anything.

g2 Prints the input graph after making everything or before exiting on error.

j Prints debugging information about running multiple shells.

m Prints debugging information about making targets, including modification dates.

s Prints debugging information about suffix-transformation rules.

t Prints debugging information about target list maintenance.

v Prints debugging information about variable assignment.

-e Specifies that environmental variables override macro assignments within makefiles.

-f makefile Specifies a makefile to read instead of the default "makefile" and "Makefile". If makefile is -, standard input is read. Multiple makefiles may be specified and are read in the order specified.

-I directory Specifies a directory in which to search for makefiles and included makefiles. The system makefile directory is automatically included as part of this list.

-i Ignores nonzero exit of shell commands in the makefile. Equivalent to specifying - before each command line in the makefile.

-j max_jobs Specifies the maximum number of jobs that make may have running at any one time.

-k Continues processing after errors are encountered but only on those targets that do not depend upon the target whose creation caused the error.

-n Displays the commands that would have been executed, but do not actually execute them.

-q Does not execute any commands but does exit 0 if the specified targets are up to date; otherwise, it specifies 1.

-r Does not use the built-in rules specified in the system makefile.

-s Does not echo any commands as they are executed. Equivalent to specifying _B@ before each command line in the makefile.

-t Rather than rebuilding a target as specified in the makefile, creates it or updates its modification time to make it appear up to date.

variable=value

Set the value of the variable variable to value.

There are six different types of lines in a makefile: file dependency specifications, shell commands, variable assignments, include statements, conditional directives, and comments.

In general, lines may be continued from one line to the next by ending them with a backslash ("\"). The trailing newline character and initial whitespace on the following line are compressed into a single space.

FILE DEPENDENCY SPECIFICATIONS

Dependency lines consist of one or more targets, an operator, and zero or more sources. This creates a relationship where the targets "depend" upon the sources and are usually created from them. The exact relationship between the target and the source is determined by the operator that separates them. The three operators are as follows:

:

A target is considered out of date if its modification time is less than those of any of its sources. Sources for a target accumulate over dependency lines when this operator is used. The target is removed if make is interrupted.

!

Targets are always re-created but not until all sources have been examined and re-created as necessary. Sources for a target accumulate over dependency lines when this operator is used. The target is removed if make is interrupted.

::

If no sources are specified, the target is always re-created. Otherwise, a target is considered out of date if any of its sources has been modified more recently than the target. Sources for a target do not accumulate over dependency lines when this operator is used. The target will not be removed if make is interrupted.

Targets and sources may contain the shell wildcard values "?", "*", "[]", and "{}". The values "?", "*", and "[]" may only be used as part of the final component of the target or source and must be used to describe existing files. The value "{}" need not necessarily be used to describe existing files. Expansion is in directory order not alphabetically as done in the shell.

SHELL COMMANDS

Each target may have associated with it a series of shell commands, normally used to create the target. Each of the commands in this script must be preceded by a tab. While any target may appear on a dependency line, only one of these dependencies may be followed by a creation script, unless the "::" operator is used.

If the first or first two characters of the command line are "@" and/or "-", the command is treated specially. A "@" causes the command not to be echoed before it is executed. A "-" causes any nonzero exit status of the command line to be ignored.

VARIABLE ASSIGNMENTS

Variables in make are much like variables in the shell; and, by tradition, consist of all uppercase letters. The five operators that can be used to assign values to variables are as follows:

=

Assigns the value to the variable. Any previous value is overridden.

+=

Appends the value to the current value of the variable.

?=

Assigns the value to the variable if it is not already defined.

:=

Assigns with expansion, i.e., expands the value before assigning it to the variable. Normally, expansion is not done until the variable is referenced.

!=

Expands the value and passes it to the shell for execution and assigns the result to the variable. Any newlines in the result are replaced with spaces.

Any white-space before the assigned value is removed; if the value is being appended, a single space is inserted between the previous contents of the variable and the appended value.

Variables are expanded by surrounding the variable name with either curly braces ("{}") or parentheses ("()") and preceding it with a dollar sign ("$"). If the variable name contains only a single letter, the surrounding braces or parentheses are not required. This shorter form is not recommended.

Variable substitution occurs at two distinct times, depending upon where the variable is being used. Variables in dependency lines are expanded as the line is read. Variables in shell commands are expanded when the shell command is executed.

The four different classes of variables (in order of increasing precedence) are:

Environment variables

Variables defined as part of make's environment.

Global variables

Variables defined in the makefile or in included makefiles.

Command line variables

Variables defined as part of the command line.

Local variables

Variables that are defined specific to a certain target. The seven local variables are as follows:

.ALLSRC The list of all sources for this target; also known as ">".

.ARCHIVE The name of the archive file.

.IMPSRC The name/path of the source from which the target is to be transformed (the "implied" source); also known as "<".

.MEMBER The name of the archive member.

.OODATE The list of sources for this target that were deemed out of date; also known as "?".

.PREFIX The file prefix of the file, containing only the file portion, no suffix or preceding directory components; also known as "*".

.TARGET The name of the target; also known as "@". The shorter forms "@", "?", ">", and "*" are permitted for backward compatibility with historical makefiles and are not recommended. The six variables "@F", "@D", "<F", "<D", "*F", and "*D" are permitted for compatibility with AT&T System V makefiles and are not recommended.

Four of the local variables may be used in sources on dependency lines because they expand to the proper value for each target on the line. These variables are ".TARGET", ".PREFIX", ".ARCHIVE", and ".MEMBER".

In addition, make sets or knows about the following variables:

$

A single dollar sign "$", i.e. "$$" expands to a single dollar sign.

.MAKE

The name that make was executed with (argv[0]).

.CURDIR

A path to the directory where make was executed.

MAKEFLAGS

The environment variable "MAKEFLAGS" may contain anything that may be specified on make's command line. Anything specified on make's command line is appended to the "MAKEFLAGS" variable which is then entered into the environment for all programs which make executes.

Variable expansion may be modified to select or modify each word of the variable (where a "word" is white-space delimited sequence of characters). The general format of a variable expansion is:

{variable[:modifier[:...]]}

Each modifier begins with a colon and one of the following special characters. The colon may be escaped with a backslash ("\").

E

Replaces each word in the variable with its suffix.

H

Replaces each word in the variable with everything but the last component.

M pattern

Selects only those words that match the rest of the modifier. The standard shell wildcard characters ("*" and "?") may be used. The wildcard characters may be escaped with a backslash ("\").

N pattern

This is identical to M, but selects all words that do not match the rest of the modifier.

R

Replaces each word in the variable with everything but its suffix.

S /old_pattern/new_pattern/[g]

Modifies the first occurrence of old_pattern in each word to be replaced with new_pattern. If a g is appended to the last slash of the pattern, all occurrences in each word are replaced. If old_pattern begins with a caret ("^"), old_pattern is anchored at the beginning of each word. If old_pattern ends with a dollar sign ("$"), it is anchored at the end of each word. Inside new_string, an ampersand ("&") is replaced by old_pattern. Any character may be used as a delimiter for the parts of the modifier string. The anchoring, ampersand, and delimiter characters may be escaped with a backslash ("\").

Variable expansion occurs in the normal fashion inside both old_string and new_string with the single exception that a backslash is used to prevent the expansion of a dollar sign ("$"), not a preceding dollar sign as is usual.

T

Replaces each word in the variable with its last component.

old_string=new_string

This is the AT&T System V style variable substitution. It must be the last modifier specified. old_string is anchored at the end of each word, so only suffixes or entire words may be replaced.

INCLUDE STATEMENTS AND CONDITIONALS

Makefile inclusion and conditional structures reminiscent of the C programming language are provided in make. All such structures are identified by a line beginning with a single dot (".") character. Files are included by either ".include <file>" or ".include "file"". Variables between the angle brackets or double quotes are expanded to form the file name. If angle brackets are used, the included makefile is expected to be in the system makefile directory. If double quotes are used, the including makefile's directory and any directories specified using the -I option are searched before the system makefile directory.

Conditional expressions also are preceded by a single dot as the first chraracter of a line. The possible conditionals are listed below.

.undef variable

Undefines the specified global variable. Only global variables may be undefined.

.if [ ! ] expression [ operator expression ... ]

Tests the value of an expression.

.ifdef [ ! ] variable [ operator variable ... ]

Tests the value of a variable.

.ifndef [ ! ] variable [ operator variable ... ]

Tests the value of a variable.

.ifmake [ ! ] target [ operator target ... ]

Tests the target being built.

.ifnmake [ ! ] target [ operator target ... ]

Tests the target being built.

.else

Reverses the sense of the last conditional.

.elif [ ! ] expression [ operator expression ... ]

A combination of .else followed by .if.

.elifdef [ ! ] variable [ operator variable ... ]

A combination of .else followed by .ifdef.

.elifndef [ ! ] variable [ operator variable ... ]

A combination of .else followed by .ifndef.

.elifmake [ ! ] target [ operator target ... ]

A combination of .else followed by .ifmake.

.elifnmake [ ! ] target [ operator target ... ]

A combination of .else followed by .ifnmake.

.endif

Ends the body of the conditional.

The operator may be any one of the following:

|| logical OR && Logical AND; of higher precedence than ||.

As in C, make will only evaluate a conditional as far as is necessary to determine its value. Parentheses may be used to change the order of evaluation. The boolean operator "!" may be used to logically negate an entire conditional. It is of higher precendence than "&&".

The value of expression may be any of the following.

defined

Takes a variable name as an argument and evaluates to true if the variable has been defined.

make

Takes a target name as an argument and evaluates to true if the target was specified as part of make's command line or was declared the default target (either implicitly or explicitly, see .MAIN) before the line containing the conditional.

empty

Takes a variable, with possible modifiers, and evaluates to true if the expansion of the variable would result in an empty string.

exists

Takes a file name as an argument and evaluates to true if the file exists. The file is searched for on the system search path (see .PATH).

target

Takes a target name as an argument and evaluates to true if the target has been defined.

expression also may be an arithmetic or string comparison, with the left-hand side being a variable expansion. The standard C relational operators are all supported, and the usual number/base conversion is performed. Note, octal numbers are not supported. If the righthand value of a "==" or "!=" operator begins with a quotation mark ("") a string comparison is done between the expanded variable and the text between the quotation marks. If no relational operator is given, it is assumed that the expanded variable is being compared against 0.

When make is evaluating one of these conditional expressions and it encounters a word it does not recognize, either the "make" or "defined" expression is applied to it, depending upon the form of the conditional. If the form is .ifdef or .ifndef, the "defined" expression is applied. Similarly, if the form is .ifmake or .ifnmake, the "make" expression is applied.

If the conditional evaluates to true, the parsing of the makefile continues as before. If it evaluates to false, the following lines are skipped. In both cases this continues until a .else or .endif is found.

COMMENTS

Comments begin with a number sign ("#") character, anywhere but in a shell command line, and continue to the end of the line.

SPECIAL SOURCES

.IGNORE

Ignores any errors from the commands associated with this target, exactly as if they all were preceded by a dash ("-").

.MAKE

Executes the commands associated with this target, even if the -n or -t options were specified. Normally used to mark recursive make's.

.NOTMAIN

Normally, make selects the first target it encounters as the default target to be built if no target was specified. This source prevents this target from being selected.

.OPTIONAL

If a target is marked with this attribute and make cannot determine how to create it, it will ignore this fact and assume that the file is not needed or already exists.

.PRECIOUS

When make is interrupted, it removes any partially made targets. This source prevents the target from being removed.

.SILENT

Does not echo any of the commands associated with this target, exactly as if they all were preceded by an at sign ("@").

.USE

Turns the target into make's version of a macro. When the target is used as a source for another target, the other target acquires the commands, sources, and attributes (except for .USE) of the source. If the target already has commands, the .USE target's commands are appended to them.

SPECIAL TARGETS

Special targets may not be included with other targets; i.e., they must be the only target specified.

.BEGIN

Any command lines attached to this target are executed before anything else is done.

.DEFAULT

This is sort of a .USE rule for any target (that was used only as a source) that make cannot figure out any other way to create. Only the shell script is used. The .IMPSRC variable of a target that inherits .DEFAULT's commands is set to the target's own name.

.END

Any command lines attached to this target are executed after everything else is done.

.IGNORE

Marks each of the sources with the .IGNORE attribute. If no sources are specified, this is the equivalent of specifying the -i option.

.INTERRUPT

If make is interrupted, the commands for this target will be executed.

.MAIN

If no target is specified when make is invoked, this target will be built.

.MAKEFLAGS

This target provides a way to specify flags for make when the makefile is used. The flags are as if typed to the shell, though the -f option will have no effect.

.PATH

The sources are directories that are to be searched for files not found in the current directory. If no sources are specified, any previously specified directories are deleted.

.PRECIOUS

Applies the .PRECIOUS attribute to any specified sources. If no sources are specified, the .PRECIOUS attribute is applied to every target in the file.

.SILENT

Applies the .SILENT attribute to any specified sources. If no sources are specified, the .SILENT attribute is applied to every command in the file.

.SUFFIXES

Each source specifies a suffix to make. If no sources are specified, any previously specified suffixes are deleted.

ENVIRONMENT

make utilizes the following environment variables, if they exist: MAKE, MAKEFLAGS,and MAKEOBJDIR.

FILES

.depend list of dependencies

Makefile list of dependencies

makefile list of dependencies

sys.mk system makefile

/usr/share/mk system makefile directory

HISTORY

A make command appeared in Seventh Edition AT&T UNIX.

NAME

mkdir -- make directories

SYNOPSIS

mkdir [-p] directory_name ...

DESCRIPTION

mkdir creates the directories named as operands, in the order specified, using mode 0777 modified by the current umask.

The options follow.

-p

Creates intermediate directories as required. If this option is not specified, the full path prefix of each operand must already exist.

The user must have write permission in the parent directory.

mkdir exits 0 if successful and >0 if an error occurred.

STANDARDS

mkdir is POSIX 1003.2-compliant. This manual page is derived from the POSIX 1003.2 manual page.

NAME

mv -- move files

SYNOPSIS

mv [-f | -i] source target mv [-f | -i] source ... directory

DESCRIPTION

In its first form, the mv utility renames the file named by the source operand to the destination path named by the target operand. This form is assumed when the last operand does not name an already existing directory.

In its second form, mv moves each file named by a source operand to a destination file in the existing directory named by the directory operand. The destination path for each operand is the pathname produced by the concatenation of the last operand, a slash, and the final pathname component of the named file.

The following options are available.

-f

Does not prompt for confirmation before overwriting the destination path. (The -i option is ignored if the -f option is specified.)

-i

Causes mv to write a prompt to standard error before moving a file that would overwrite an existing file. If the response from the standard input begins with the character "y'", the move is attempted.

It is an error for either the source operand or the destination path to specify a directory unless both do.

If the destination path does not have a mode that permits writing, mv prompts the user for confirmation as specified for the -i option.

As the rename(2) call does not work across file systems, mv uses cp(1) and rm(1) to accomplish the move. The effect is equivalent to:

rm -f destination_path && \ cp -pr source destination_path && \ rm -rf source

The mv utility exits 0 on success and >0 if an error occurs.

STANDARDS

The mv utility is expected to be POSIX 1003.2-compatible.

NAME

rm -- remove directory entries

SYNOPSIS

rm [-f | -i] [-d] [-R] [-r] file ...

DESCRIPTION

The rm utility attempts to remove the nondirectory type files specified on the command line. If the permissions of the file do not permit writing and the standard input device is a terminal, the user is prompted (on the standard error output) for confirmation.

The options are listed below.

-d

Attempts to remove directories as well as other types of files.

-f

Attempts to remove the files without prompting for confirmation, regardless of the file's permissions. If the file does not exist, does not display a diagnostic message nor modify the exit status to reflect an error. The -f option overrides any previous -i options.

-i

Requests confirmation before attempting to remove each file, regardless of the file's permissions or whether or not the standard input device is a terminal. The -i option overrides any previous

-f options.

-R

Attempts to remove the file hierarchy rooted in each file argument. The -R option implies the

-d option. If the -i option is specified, the user is prompted for confirmation before each directory's contents are processed (as well as before the attempt is made to remove the directory). If the user does not respond affirmatively, the file hierarchy rooted in that directory is skipped.

-r

Equivalent to -R.

The rm utility removes symbolic links, not the files referenced by the links.

It is an error to attempt to remove the files "." and "..".

The rm utility exits 0 if all of the named files or file hierarchies were removed or if the -f option was specified and all of the existing files or file hierarchies were removed. If an error occurs, rm exits with a value >0.

COMPATIBILITY

The rm utility differs from historical implementations in that the -f option only masks attempts to remove nonexistent files instead of masking a large variety of errors.

Also, historical rm implementations prompted on the standard output not the standard error output.

STANDARDS

The rm command is expected to be POSIX 1003.2-compatible.

NAME

rmdir -- remove directories

SYNOPSIS

rmdir directory ...

DESCRIPTION

The rmdir utility removes the directory entry specified by each directory argument, provided it is empty.

Arguments are processed in the order given. To remove both a parent directory and a subdirectory of that parent, the subdirectory must be specified first so that the parent directory is empty when rmdir tries to remove it.

The rmdir utility exits with one of the following values:

0 Each directory entry specified by a directory operand referred to an empty directory and was removed successfully.

>0 An error occurred.

STANDARDS

The rmdir function is expected to be POSIX 1003.2-compatible.

NAME

ash -- a shell

SYNOPSIS

ash [-efIijnsxz] [+efIijnsxz] [-c command] [arg] ...

COPYRIGHT

Copyright © 1989 by Kenneth Almquist.

DESCRIPTION

ash is a version of sh(1) with features similar to those of the System V shell. This manual page lists all the features of ash but concentrates upon the ones not in other shells.

Invocation

If the -c option is given, then the shell executes the specified shell command. The -s flag causes the shell to read commands from the standard input (after executing any command specified with the -c option). If neither the -s nor -c options are set, then the first arg is taken as the name of a file to read commands from. If this is impossible because there are no arguments following the options, then ash will set the -s flag and will read commands from the standard input.

The shell sets the initial value of the positional parameters from the args remaining after any arg used as the name of a file of commands is deleted.

The flags (other than -c) are set by preceding them with "-" and cleared by preceding them with "+"; see the set built-in command for a list of flags. If no value is specified for the -i flag, the -s flag is set and the standard input and output of the shell are connected to terminals; then, the -i flag will be set. If no value is specified for the -j flag, then the -j flag will be set if the -i flag is set.

When the shell is invoked with the -c option, it is good practice to include the -i flag if the command was entered interactively by a user. For compatibility with the System V shell, the -i option should come after the -c option.

If the first character of argument zero to the shell is "-", the shell is assumed to be a login shell; and the files /etc/profile and .profile are read if they exist. If the environment variable SHINIT is set upon entry to the shell, the commands in SHINIT are normally parsed and executed. SHINIT is not examined if the shell is a login shell or if it the shell is running a shell procedure. (A shell is considered to be running a shell procedure if neither the -s nor the -c options are set.)

Control Structures

A list is a sequence of zero or more commands separated by newlines, semicolons, or ampersands, and optionally terminated by one of these three characters. (This differs from the System V shell, which, in most cases, requires a list to contain at least one command.) The commands in a list are executed in the order in which they are written. If a command is followed by an ampersand, the shell starts the command and immediately proceeds on to the next command; otherwise it waits for the command to terminate before proceeding to the next one.

"&&" and "||" are binary operators. "&&" executes the first command and then executes the second command if the exit status of the first command is zero. "||" is similar but executes the second command if the exit status of the first command is nonzero. "&&" and "||" both have the same priority.

The "|" operator is a binary operator that feeds the standard output of the first command into the standard input of the second command. The exit status of the "|" operator is the exit status of the second command. "|" has a higher priority than "||" or "&&".

An if command looks like the following example.

if list then list [ elif list then list ] ... [ else list ] fi

A while command looks like the following example.

while list do list done

The two lists are executed repeatedly while the exit status of the first list is zero. The until command is similar; however, it has the word until in place of while and repeats until the exit status of the first list is zero.

The for command looks like the following example.

for variable in word... do list done

The words are expanded; and, then, the list is executed repeatedly with the variable set to each word in turn. do and done may be replaced with "{" and "}".

The break and continue commands look like the following example.

break [ num ] continue [ num ]

break terminates the num'ths innermost for or while loops. continue continues with the next iteration of the num'ths innermost loop. These are implemented as built-in commands.

The case command looks like the following example.

case word in pattern) list ;; ... esac

The pattern can actually be one or more patterns (see Patterns below) separated by "|" characters.

Commands may be grouped by writing either one of the following.

(list)

or

{ list; }

The first of these executes the commands in a subshell.

A function definition looks like the following example.

name ( ) command

A function definition is an executable statement; when executed it installs a function named name and returns an exit status of zero. The command is normally a list enclosed between "{" and "}".

Variables may be declared to be local to a function by using a local command. This should appear as the first statement of a function; it should looks like the following example.

local [ variable | - ] ...

local is implemented as a built-in command.

When a variable is made local, it inherits the initial value and exported and read-only flags from the variable with the same name in the surrounding scope, if there is one. Otherwise, the variable is initially unset. ash uses dynamic scoping so that, if you make the variable x local to function f, which then calls function g, references to the variable x made inside g will refer to the variable x declared inside f, not to the global variable named x.

The only special parameter that can be made local is "-". Making "-" local sets any shell options that are changed via the set command inside the function to be restored to their original values when the function returns.

The return command looks like the following example.

return [ exitstatus ]

It terminates the currently executing function. return is implemented as a built-in command.

Simple Commands

A simple command is a sequence of words. The execution of a simple command proceeds as follows. First, the leading words of the form "name=value" are stripped off and assigned to the environment of the command. Second, the words are expanded. Third, the first remaining word is taken as the command name of the command that is located. Fourth, any redirections are performed. Fifth, the command is executed. We look at these operations in reverse order.

The execution of the command varies with the type of command. There are three types of commands: shell functions, built-in commands, and normal programs.

When a shell function is executed, all of the shell positional parameters (except $0, which remains unchanged) are set to the parameters to the shell function. The variables that are explicitly placed in the environment of the command (by placing assignments to them before the function name) are made local to the function and are set to values given. Then, the command given in the function definition is executed. The positional parameters are restored to their original values when the command completes.

Shell built-ins are executed internally to the shell, without spawning a new process.

When a normal program is executed, the shell runs the program, passing the parameters and the environment to the program. If the program is a shell procedure, the shell will interpret the program in a subshell. The shell will reinitialize itself in this case, so that the effect will be as if a new shell had been invoked to handle the shell procedure, except that the location of commands located in the parent shell will be remembered by the child. If the program is a file beginning with "#!", the remainder of the first line specifies an interpreter for the program. In this case, the shell (or the operating system, under Berkeley UNIX) will run the interpreter. The arguments to the interpreter will consist of any arguments given on the first line of the program, followed by the name of the program, followed by the arguments passed to the program.

Redirection

Input/output redirections can be intermixed with the words in a simple command and can be placed following any of the other commands. When redirection occurs, the shell saves the old values of the file descriptors and restores them when the command completes. The "<", ">", and ">>" redirections open a file for input, output, and appending, respectively. The "<&digit" and ">&digit" makes the input or output a duplicate of the file descriptor numbered by the digit. If a minus sign is used in place of a digit, the standard input or the standard output is closed.

The "<< word" redirection takes input from a here document. As the shell encounters "<<" redirections, it collects them. The next time it encounters an unescaped newline, it reads the documents in turn. The word following the "<<" specifies the contents of the line that terminates the document. If none of the quoting methods ('', "", or \) are used to enter the word, then the document is treated like a word inside double quotes: "$" and backquote are expanded and backslash can be used to escape these and to continue long lines. The word cannot contain any variable or command substitutions, and its length (after quoting) must be in the range of 1 to 79 characters. If "<<-" is used in place of "<<", then leading tabs are deleted from the lines of the document. (This is to allow you to do indent shell procedures containing here documents in a natural fashion.)

Any of the preceding redirection operators may be preceded by a single digit specifying the file descriptor to be redirected. There cannot be any white space between the digit and the redirection operator.

Path Search

When locating a command, the shell first looks to see if it has a shell function by that name. Then, if PATH does not contain an entry for "%builtin", it looks for a built-in command by that name. Finally, it searches each entry in PATH in turn for the command.

The value of the PATH variable should be a series of entries separated by colons. Each entry consists of a directory name, or a directory name followed by a flag beginning with a percent sign. The current directory should be indicated by an empty directory name.

If no percent sign is present, then the entry causes the shell to search for the command in the specified directory. If the flag is "%builtin", then the list of shell built-in commands is searched. If the flag is "%func", then the directory is searched for a file that is read as input to the shell. This file should define a function whose name is the name of the command being searched for.

Command names containing a slash are simply executed without performing any of the above searches.

The Environment

The environment of a command is a set of name/value pairs. When the shell is invoked, it reads these names and values, sets the shell variables with these names to the corresponding values, and marks the variables as exported. The export command can be used to mark additional variables as exported.

The environment of a command is constructed by constructing name/value pairs from all the exported shell variables, and then by modifying this set by the assignments that precede the command, if any.

Expansion

The process of evaluating words when a shell procedure is executed is called expansion. Expansion consists of four steps: variable substitution, command substitution, word splitting, and file name generation. If a word is the expression following the word case in a case statement, the file name that follows a redirection symbol, or an assignment to the environment of a command, then the word cannot be split into multiple words. In these cases, the last two steps of the expansion process are omitted.

Command Substitution

ash accepts two syntaxes for command substitution, as listed below.

'list'

and

$(list)

Either of these may be included in a word. During the command substitution process, the command (syntactically a list) will be executed, and anything that the command writes to the standard output will be captured by the shell. The final newline (if any) of the output will be deleted; the rest of the output will be substituted for the command in the word.

Word Splitting

When the value of a variable or the output of a command is substituted, the resulting text is subject to word splitting, unless the dollar sign introducing the variable or backquotes containing the text were enclosed in double quotes. In addition, "$@" is subject to a special type of splitting, even in the presence of double quotes.

ash uses two different splitting algorithms. The normal approach, which is intended for splitting text separated by white space, is used if the first character of the shell variable IFS is a space. Otherwise, an alternative experimental algorithm, which is useful for splitting (possibly empty) fields separated by a separator character, is used.

When performing splitting, the shell scans the replacement text looking for a character (when IFS does not begin with a space) or a sequence of characters (when IFS does begin with a space), deletes the character or sequence of characters, and spits the word into two strings at that point. When IFS begins with a space, the shell deletes either of the strings if they are null. As a special case, if the word containing the replacement text is the null string, the word is deleted.

The variable "$@" is special in two ways. First, splitting takes place between the positional parameters, even if the text is enclosed in double quotes. Second, if the word containing the replacement text is the null string and there are no positional parameters, then the word is deleted. The result of these rules is that "$@" is equivalent to "$1" "$2" ... "$n", where n is the number of positional parameters. (Note that this differs from the System V shell. The System V documentation claims that "$@" behaves this way; in fact on the System V shell "$@" is equivalent to "" when there are no positional paramteters.)

File Name Generation

Unless the -f flag is set, file name generation is performed after word splitting is complete. Each word is viewed as a series of patterns, separated by slashes. The process of expansion replaces the word with the names of all existing files whose names can be formed by replacing each pattern with a string that matches the specified pattern. There are two restrictions on this: first, a pattern cannot match a string containing a slash; and, second, a pattern cannot match a string starting with a period unless the first character of the pattern is a period.

If a word fails to match any files and the -z flag is not set, then the word will be left unchanged (except that the meta characters will be converted to normal characters). If the -z flag is set, then the word is only left unchanged if none of the patterns contain a character that can match anything other than itself. Otherwise, the -z flag forces the word to be replaced with the names of the files that it matches, even if there are zero names.

Patterns

A pattern consists of normal characters, which match themselves, and meta characters. The meta characters are "!", "*", "?", and "[". These characters lose there special meanings if they are quoted. When command or variable substitution is performed and the dollar sign or back quotes are not double quoted, the value of the variable or the output of the command is scanned for these characters and they are turned into meta characters.

Two exclamation points at the beginning of a pattern function as a "not" operator, causing the pattern to match any string that the remainder of the pattern does not match. Other occurrences of exclamation points in a pattern match exclamation points. Two exclamation points are required, rather than one, to decrease the incompatibility with the System V shell (which does not treat exclamation points specially).

An asterisk ("*") matches any string of characters. A question mark matches any single character. A left bracket ("[") introduces a character class. The end of the character class is indicated by a "]"; if the "]" is missing, then the "[" matches a "[" rather than introducing a character class. A character class matches any of the characters between the square brackets. A range of characters may be specified using a minus sign. The character class may be complemented by making an exclamation point of the first character of the character class.

To include a "]" in a character class, make it the first character listed (after the "!", if any). To include a minus sign, make it the first or last character listed.

The /u Directory

By convention, the name "/u/user" refers to the home directory of the specified user. There are good reasons why this feature should be supported by the file system (using a feature such as symbolic links) rather than by the shell, but ash is capable of performing this mapping if the file system does not. If the mapping is done by ash, setting the -f flag will turn it off.

Character Set

ash silently discards NUL characters. Any other character will be handled correctly by ash, including characters with the high-order bit set.

Job Names and Job Control

The term job refers to a process created by a shell command or, in the case of a pipeline, to the set of processes in the pipeline. The ways to refer to a job follow.

%number %string %% process_id

The first form identifies a job by its job number. When a command is run, ash assigns it a job number (the lowest unused number is assigned). The second form identifies a job by giving a prefix of the command used to create the job. The prefix must be unique. If there is only one job, then the null prefix will identify the job, so you can refer to the job by writing "%". The third form refers to the current job. The current job is the last job to be stopped while it was in the foreground. (See the next paragraph.) The last form identifies a job by giving the process id of the last process in the job.

If the operating system that ash is running on supports job control, ash will allow you to use it. In this case, typing the suspend character (typically ^Z) while running a command will return you to ash and will make the suspended command the current job. You can then continue the job in the background by typing bg, or you can continue it in the foreground by typing fg.

ATTY

If the shell variable ATTY is set and the shell variable TERM is not set to "emacs", then ash generates appropriate escape sequences to talk to atty(1).

Exit Statuses

By tradition, an exit status of zero means that a command has succeeded, and a nonzero exit status indicates that the command failed. This is better than no convention at all; but, in practice, it is extremely useful to allow commands that succeed to use the exit status to return information to the caller. A variety of better conventions have been proposed, but none of them has met with universal approval. The convention used by ash and all the programs included in the ash distribution follows.

0Success

1Alternate success

2Failure

129-...Command terminated by a signal

The alternate success return is used by commands to indicate various conditions that are not errors but which can, with a little imagination, be conceived of as less successful than plain success. For example, test returns 1 when the tested condition is false and getopts returns 1 when there are no more options. Because this convention is not used universally, the -e option of ash causes the shell to exit when a command returns 1, even though that contradicts the convention described here.

When a command is terminated by a signal, it uses 128 plus the signal number as the exit code for the command.

Built-in Commands

This concluding section lists the built-in commands that are built in because they need to perform some operation that cannot be performed by a separate process. In addition to these, there are several other commands (catf, echo, expr, line, nlecho, test, ":", and true) that can optionally be compiled into the shell. The built-in commands described below that accept options use the System V Release 2 getopt(3) syntax.

bg [ job ] ...

Continues the specified jobs (or the current job if no jobs are given) in the background. This command is only available on systems with Berkeley job control.

bltin command arg ...

Executes the specified built-in command. (This is useful when you have a shell function with the same name as a built-in command.)

cd [ directory ]

Switchs to the specified directory (default $HOME). If an entry for CDPATH appears in the environment of the cd command or the shell variable CDPATH is set and the directory name does not begin with a slash, then the directories listed in CDPATH will be searched for the specified directory. The format of CDPATH is the same as that of PATH. In an interactive shell, the cd command will print out the name of the directory that it actually switched to if this is different from the name that the user gave. These may be different either because the CDPATH mechanism was used or because a symbolic link was crossed.

. file

The commands in the specified file are read and executed by the shell. A path search is not done to find the file because the directories in PATH generally contain files that are intended to be executed, not read.

eval string ...

The strings are parsed as shell commands and executed. (This differs from the System V shell, which concatenates the arguments (separated by spaces) and parses the result as a single command.)

exec [ command arg ... ]

Unless command is omitted, the shell process is replaced with the specified program (which must be a real program, not a shell built-in or function). Any redirections on the exec command are marked as permanent so that they are not undone when the exec command finishes. If the command is not found, the exec command causes the shell to exit.

exit [ exitstatus ]

Terminates the shell process. If exitstatus is given, it is used as the exit status of the shell; otherwise, the exit status of the preceding command is used.

export name ...

The specified names are exported so that they will appear in the environment of subsequent commands. The only way to unexport a variable is to unset it. ash allows the value of a variable to be set at the same time it is exported by writing the following.

export name=value

With no arguments, the export command lists the names of all exported variables.

fg [ job ]

Moves the specified job or the current job to the foreground. This command is only available on systems with Berkeley job control.

getopts optstring var

The System V getopts(1) command.

hash [ -rv ] command ...

The shell maintains a hash table that remembers the locations of commands. With no arguments whatsoever, the hash command prints out the contents of this table. Entries that have not been looked at since the last cd command are marked with an asterisk; it is possible for these entries to be invalid.

With arguments, the hash command removes the specified commands from the hash table (unless they are functions) and then locates them. With the -v option, hash prints the locations of the commands as it finds them. The -r option causes the hash command to delete all the entries in the hash table except for functions.

jobid [ job ]

Prints the process id's of the processes in the job. If the job argument is omitted, uses the current job.

jobs

This command lists out all the background processes that are children of the current shell process.

lc [ function-name ]

The function name is defined to execute the last command entered. If the function name is omitted, the last command executed is executed again. This command only works if the -i flag is set.

pwd

Prints the current directory. The built-in command may differ from the program of the same name because the built-in command remembers what the current directory is rather than recomputing it each time. This makes it faster. However, if the current directory is renamed, the built-in version of pwd will continue to print the old name for the directory.

read [ -p prompt ] [ -e ] variable ...

The prompt is printed if the -p option is specified and the standard input is a terminal. Then, a line is read from the standard input. The trailing newline is deleted from the line, and the line is split (as described in the section on word splitting above) and the pieces are assigned to the variables in order. If there are more pieces than variables, the remaining pieces (along with the characters in IFS that separated them) are assigned to the last variable. If there are more variables than pieces, the remaining variables are assigned the null string.

The -e option causes any backslashes in the input to be treated specially. If a backslash is followed by a newline, the backslash and the newline will be deleted. If a backslash is followed by any other character, the backslash will be deleted and the following character will be treated as though it were not in IFS, even if it is.

readonly name ...

The specified names are marked as read only, so that they cannot be subsequently modified nor unset. ash allows the value of a variable to be set at the same time it is marked read-only by writing the following.

readonly name=value

With no arguments, the read-only command lists the names of all read-only variables.

set [ { -options | +options | -- } ] [ arg ... ]

The set command performs three different functions.

With no arguments, it lists the values of all shell variables.

If options are given, it sets the specified option flags, or clears them if the option flags are introduced with a + rather than a -. Only the first argument to set can contain options. The possible options are listed below.

-e Causes the shell to exit when a command terminates with a nonzero exit status, except when the exit status of the command is explicitly tested. The exit status of a command is considered to be explicitly tested if the command is used to control an if, elif, while, or until or if the command is the left-hand operand of an "&&" or "||" operator.

-f Turns off file name generation.

-I Causes the shell to ignore end-of file-conditions. (This does not apply when the shell is a script source using the "." command.) The shell will, in fact, exit if it gets 50 EOF's in a row.

-i Makes the shell interactive. This causes the shell to prompt for input, to trap interrupts, to ignore quit and terminate signals, and to return to the main command loop rather than exiting upon error.

-j Turns on Berkeley job control on systems that support it. When the shell starts up, the

-j is set by default if the -i flag is set.

-n Causes the shell to read commands but not to execute them. (This is marginally useful for checking the syntax of scripts.)

-s If this flag is set when the shell starts up, the shell reads commands from its standard input. The shell does not examine the value of this flag at any other time.

-x If this flag is set, the shell will print out each command before executing it.

-z If this flag is set, the file name generation process may generate zero files. If it is not set, then a pattern that does not match any files will be replaced by a quoted version of the pattern.

The third use of the set command is to set the values of the shell's positional parameters to the specified args. To change the positional parameters without changing any options, use "--" as the first argument to set. If no args are present, the set command will leave the value of the positional parameters unchanged. Therefore, to set the positional parameters to a set of values that may be empty, execute the command

shift $#

first to clear out the old values of the positional parameters.

setvar variable value

Assigns value to variable. (In general, it is better to write variable=value rather than using setvar. setvar is intended to be used in functions that assign values to variables whose names are passed as parameters.)

shift [ n ]

Shift the positional parameters n times. A shift sets the value of $1 to the value of $2, the value of $2 to the value of $3, and so on, decreasing the value of $# by one. If there are zero positional parameters, shifting does not do anything.

trap [ action ] signal ...

Causes the shell to parse and execute action when any of the specified signals are received. The signals are specified by signal number. action may be null or omitted; the former causes the specified signal to be ignored and the latter causes the default action to be taken. When the shell forks off a subshell, it resets trapped (but not ignored) signals to the default action. The trap command has no effect upon signals that were ignored upon entry to the shell.

umask [ mask ]

Sets the value of umask to the specified octal value. If the argument is omitted, the umask value is printed.

unset name ...

The specified variables and functions are unset and unexported. If a given name corresponds to both a variable and a function, both the variable and the function are unset.

wait [ job ]

Waits for the specified job to complete and returns the exit status of the last process in the job. If the argument is omitted, waits for all jobs to complete and then returns an exit status of zero.

EXAMPLES

The following function redefines the cd command:

cd() { if bltin cd "$@" then if test -f .enter then . .enter else return 0 fi fi }

This function causes the file ".enter" to be read when you enter a directory, if it exists. The bltin command is used to access the real cd command. The "return 0" ensures that the function will return an exit status of zero if it successfully changes to a directory that does not contain a ".enter" file. Redefining existing commands is not always a good idea, but this example shows that you can do it if you want to.

The suspend function distributed with ash looks like the following example.

# Copyright (C) 1989 by Kenneth Almquist. All rights reserved. # This file is part of ash, which is distributed under the terms # specified by the Ash General Public License. suspend() { local - set +j kill -TSTP 0 }

This turns off job control and then sends a stop signal to the current process group, which suspends the shell. (When job control is turned on, the shell ignores the TSTP signal.) Job control will be turned back on when the function returns because "-" is local to the function. As an example of what not to do, consider an earlier version of suspend, as illustrated below.

suspend() { suspend_flag=$- set +j kill -TSTP 0 set -$suspend_flag }

There are two problems with this. First, suspend_flag is a global variable rather than a local one, which will cause problems in the (unlikely) circumstance that the user is using that variable for some other purpose. Second, consider what happens if shell received an interrupt signal after it executes the first set command but before it executes the second one. The interrupt signal will abort the shell function, so that the second set command will never be executed and job control will be left off. The first version of suspend avoids this problem by turning job control off only in a local copy of the shell options. The local copy of the shell options is discarded when the function is terminated, no matter how it is terminated.

HINTS

Shell variables can be used to provide abbreviations for things that you type frequently. For example, if you set export h=$HOME in your.profile so that you can type the name of your home directory simply by typing "$h".

When writing shell procedures, try not to make assumptions about what is imported from the environment. Explicitly unset or initialize all variables, rather than assuming they will be unset. If you use cd, it is a good idea to unset CDPATH.

People sometimes use "<&-" or ">&-" to provide no input to a command or to discard the output of a command. A better way to do this is to redirect the input or output of the command to /dev/null.

Word splitting and file name generation are performed by default, and you must explicitly use double quotes to suppress it. This is backwards, but you can learn to live with it. Just get in the habit of writing double quotes around variable and command substitutions, and omit them only when you really want word splitting and file-name generation. If you want word splitting but not file-name generation, use the

-f option.

AUTHORS

Kenneth Almquist

BUGS

When command substitution occurs inside a here document, the commands inside the here document are run with their standard input closed. For example, the following will not work because the standard input of the line command will be closed when the command is run.

cat <<-! Line 1: $(line) Line 2: $(line) !

Unsetting a function that is currently being executed may cause strange behavior.

The shell syntax allows a here document to be terminated by an end-of-file as well as by a line containing the terminator word that follows the "<<". What this means is that, if you mistype the terminator line, the shell will silently swallow up the rest of your shell script and stick it in the here document.

NAME

touch -- update last modification date of a file

SYNOPSIS

touch [-c] [-f] file ...

DESCRIPTION

The touch utility changes the modification and or access times of the given file operands.

Available options:

-c

Does not create a specified file if it does not exist. Does not write any diagnostic messages concerning this condition.

-f

Attempts to force the touch in spite of read and write permissions on a file.

HISTORY

A touch command appeared in Seventh Edition AT&T UNIX.

NAME

wc -- word, line, and byte count

SYNOPSIS

wc [-c] [-l] [-w] [file ...]

DESCRIPTION

The wc utility reads one or more input text files, and, by default, writes the number of lines, words, and bytes contained in each input file to the standard output. If more than one input file is specified, a line of cumulative counts for all named files is output on a separate line following the last file count. wc considers a word to be a maximal string of characters, delimited by white space.

The following options are available.

-c

The number of bytes in each input file is written to the standard output.

-l

The number of lines in each input file is written to the standard output.

-w

The number of words in each input file is written to the standard output.

When an option is specified, wc only reports the information requested by that option. The default action is equivalent to all the flags (-lwc) having been specified.

The following operands are available.

file A pathname of an input file.

If no file names are specified, the standard input is used and a file name is not output. The resulting output is one line of the requested count(s), with the cumulative sum of all data read in via standard input.

By default, the standard output contains a line for each input file of the form:

lines words bytes file_name

The counts for lines, words, and bytes are integers separated by spaces. The ordering of the display of the number of lines, words, and/or bytes is the order in which the options were specified.

The wc utility exits 0 on success and >0 if an error occurs.

STANDARDS

The wc function conforms to POSIX 1003.2.


RAS and X.25 - Evaluation, Implementation, and Troubleshooting for All RAS Versions

MS RAS and X.25 - Evaluation, Implementation, and Troubleshooting for All RAS Versions

Last updated: March 1997

Contributed by Gert C. Gustedt, Technical Content Developer and former Support Engineer specializing in RAS
Microsoft® Enterprise Systems Support

AT A GLANCE

Key Point: Providing detailed X.25 information on all RAS versions for planners, implementers, and troubleshooters
Detail: High | Task: Evaluation, planning, troubleshooting
Article Section | What's There
Introduction | This paper consolidates information from many sources including information based on the author's own troubleshooting experience. The goal is to help the planner and support engineer with RAS and X.25. It mentions that Pad.inf and Switch.inf script languages are nearly the same and that the new script language in Windows NT® 4.0 and Windows® 95 is not supported with X.25.
List of MS RAS Versions | Lists all RAS versions to date (March 1997)
General X.25 Information | Gives an overview of X.25 and RAS, reasons to use X.25 versus ISDN, including how many X.25 connections a RAS server can support simultaneously.
Planning an X.25 RAS Client To Server Dial-Up or Direct Connection | Discusses X.25-related features and limitations of the different RAS versions, including which versions can become RAS servers, what dial-up scripts exist and which third-party X.25 products are supported.
Implementing an X.25 RAS Client-To-Server Dial-Up or Direct Connection | Discusses the RAS after-dialing Terminal screen and how to configure RAS for existing dial-up scripts and how to write new dial-up scripts, if necessary. Explains how to configure direct-connection clients and how to configure RAS servers. Further RAS X.3 specifications and X.28 PAD commands are discussed.
Troubleshooting an X.25 RAS Client-To-Server Dial-Up or Direct-Connection | Gives and understanding of what connections the RAS client makes on the way to connecting to the RAS server. Discusses frequent problem areas, including debugging dial-up scripts, how to enable logging of communication between RAS and the PAD and gives some tips on how to troubleshoot the server. It then gives a few problem scenarios and solutions of transmission reliability problems.
Appendix A: Windows NT 4.0 Networking Supplement Manual RAS X.25 Chapter | Contains Chapter 9 of the Windows NT 4.0 Supplement Manual covering RAS X.25.
Appendix B: General X.3 Parameter Description | Gives a more detailed description (than in the RAS X.3 specifications) of the function of each X.3 parameter.
Appendix C: Using Pad.inf with Non-X.25 RAS Connections | Discusses the advantages of Pad.inf versus Switch.inf.
Appendix D: List of Electronic and Hardcopy RAS Documentation in the Different RAS Versions | Gives a list of documentation available to help you identify if you have all documentation available for a certain RAS version and where to look for it.
Appendix E: Other RAS Sources | Gives pointers to the Microsoft Knowledge Base and TechNet and the Microsoft web site.
Appendix F: The New Script Language for Windows 95 and Windows NT 4.0 | Contains a copy of the Script.doc file included in the Windows NT 4.0 %SystemRoot%\System32\RAS directory and available with Windows 95 Service Pack 1.
Appendix G: Troubleshooting RAS 1.0 and 1.1 on a MS OS/2 1.3 Server Running MS LAN Manager | Has a copy of two Microsoft Knowledge Base articles that focus on troubleshooting a computer running MS OS/2 1.3 with LAN Manager 2.1 or later and RAS 1.0 or 1.1 installed.
Legal Disclaimers | Contains all the legal disclaimers pertaining to this document.

Introduction

In many organizations, computers run different versions of Remote Access Service (RAS). This makes the job harder for the planner and support engineer because it requires knowing all about all the versions, and this material is scattered through the manuals, the help and Readme files, the Microsoft (MS) Knowledge Base, the Pad.inf and Switch.inf files, and the Script.doc file (Windows 95 and Windows NT 4.0). This article is designed to be a Remote Access Service X.25 reference that addresses common network questions related to all versions of RAS current at the time of writing (March 1997). To help its target audience (CIO, MIS, or help desk employees) it incorporates the most useful information and provides other helpful material that cannot be found even in the usual sources. Even though this paper focuses on X.25 issues, many sections relating to writing and troubleshooting Pad.inf scripts also apply to Switch.inf scripts in RAS 1.x, Windows for Workgroups 3.11 and Windows NT 3.x because the script language is the same. (For more information on writing Switch.inf scripts see the MS Knowledge Base or the RAS online help.)

For convenience and to assist with planning, a copy of the Windows NT 4.0, Networking Supplement, Chapter 9, titled X.25 PAD Support is included.

Appendix E lists manuals (including on-line sources, when possible) for the different RAS versions. Microsoft recommends that you refer to the manuals that pertain to your RAS versions in addition to this article.

Not covered in-depth is the new script language for Windows 95 and Windows NT 4.0. Windows 95 has not been tested with X.25 dial-up, though it may work, and Windows NT 3.x and 4.0 do not support the use of the new script language inside the Pad.inf file. (However, Windows NT 4.0 supports the new script language in regular RAS script files for PPP and Slip dial-up which is not the topic of this article.) The new script language is more intuitive, very similar to BASIC and C, and is well described in Script.doc, which you can find in Appendix F. Three example script files are included with Windows NT 4.0: Pppmenu.scp, Slip.scp, Slipmenu.scp. These three files and Script.doc are in the Windows NT 4.0 %SystemRoot%\System32\RAS directory.

Troubleshooting RAS 1.0 and 1.1 for Microsoft OS/2 version 1.3 is mainly covered in Appendix G because most OS/2 implementations have been upgraded to Windows NT. For more information on RAS for Microsoft OS/2 (v. 1.3) versions 1.0 and 1.1 see the Microsoft Knowledge Base.

List of Microsoft Remote Access Versions

Microsoft Remote Access for MS-DOS, versions 1.0, 1.1, and 1.1a

Microsoft Remote Access for OS/2 (v. 1.3), versions 1.0 and 1.1

Microsoft Windows for Workgroups version 3.11 (RAS is built-in)

Microsoft Windows 95 (RAS is built-in under the name “Dial-Up Networking”)

Microsoft Windows NT operating system version 3.1 (RAS is built-in)

Microsoft Windows NT Advanced Server version 3.1 (RAS is built-in)

Microsoft Windows NT Workstation versions 3.5, 3.51, and 4.0 (RAS is built-in; Windows NT 4.0: “Dial-Up Networking”)

Microsoft Windows NT Server versions 3.5, 3.51, and 4.0 (RAS is built-in; Windows NT 4.0: “Dial-Up Networking”)

General X.25 Information

The following section contains general information about X.25 networks.

Overview of X.25 Networks

An X.25 network transmits data between two computers with a packet-switching protocol. This protocol relies on an elaborate worldwide network of packet-forwarding nodes (DCEs) that can deliver an X.25 packet to its designated address.

X.25 also requires additional hardware such as an X.25 Smart Card or a PAD. For additional information on hardware requirements, see “What Third-Party Products Are Required to Set Up a RAS Connection over X.25” below and the Windows NT Server 3.5 and 3.51 Remote Access Service manual, Chapter 6, or the Windows NT Server 4.0 Networking Supplement manual, Chapter 9.

How RAS Supports X.25 Networks

Connecting to a server through an X.25 network is similar to connecting through a phone line. The only difference is that the phone book entry must specify an X.25 PAD type and an X.121 address for the RAS server.

RAS does not know what medium it is running over. It does not know about the X.25 protocol, just as it does not know about how phone lines and modem

equipment work on the lower levels. The RAS server uses the Eicon Technology WAN Services Eicon drivers and an internal Eicon X.25 adapter to convert the X.25 protocol to the serial (RS232) protocol signals (and vice versa), or it can send and receive serial signals to and from an external X.25 PAD (packet assembler/disassembler), in which case, no Eicon software and hardware is necessary because the X.25 PAD does the protocol conversion.

Some RAS client versions can also be configured with the Eicon driver and adapter or the external PAD, but usually the clients use a modem to call the X.25 network provider dial-up PAD, which is also a modem. After the RAS client modem and the X.25 provider dial-up PAD connect, the X.25 provider usually requires callers to identify themselves for billing purposes. To support caller identification, most RAS clients can run a customized command script, and some can also go into an interactive post-connect Terminal mode, to allow the client to send the user name and password.

Note

The external PAD configuration mentioned above is not supported in Windows for Workgroups 3.11, Windows 95, and Windows NT Workstation and Server versions 3.5, 3.51, and 4.0, because they have not been tested. However, there are no known reasons why this external configuration should not work.

Note

You need to purchase an Eicon X.25 adapter card and the specific Eicon WAN Services for your operating system. Since Windows NT version 4.0 the “Eicon WAN Adapters” card driver ships with Windows NT.

Reasons to Use RAS with an X.25 Network

In addition to transmitting data more reliably than regular phone lines, X.25 connections supply bandwidths of up to 56 kilobytes (K) (64K in Europe).

How Many X.25 Connections Are Supported by RAS Servers

A Windows NT 3.1, 3.5, 3.51, or 4.0 RAS server with Eicon Technologies software and Smart Card installed can host up to 256 RAS client connections over one X.25 line simultaneously. This compares favorably to the expense and space needs of having to purchase and maintain 256 modems and phone lines for the RAS server for regular telephone line connections not using X.25.

RAS 1.1 for OS/2 (OS/2 version 1.3), version 2.1 or later only supports 13 simultaneous RAS client connections over one X.25 line.

X.25 Versus ISDN

Note

In areas where ISDN is available, Microsoft recommends considering the use of ISDN rather than X.25. ISDN is much faster (128kb or more depending on the type of adapter and provider network) without compromising reliability, however, it is likely to be more expensive.

For additional information on ISDN and RAS, see the Windows NT 3.5 Server “Remote Access Service” manual, page 8, or the Windows NT 3.5 RAS online Help.

Planning an X.25 RAS Client to Server Dial-Up or Direct Connection

X.25 Related Limitations of Certain RAS Versions

RAS 1.0

Microsoft RAS version 1.0 does not have the capability to invoke RAS

Terminal or use scripts in .INF files. It does not support X.25. Upgrades to RAS 1.1 and RAS 1.1a are free.

RAS 1.1 and 1.1a

RAS 1.1 is the first RAS version to support X.25 with a Pad.inf file, however, the syntax in Pad.inf scripts is different from the syntax used in later RAS versions. For more information, see your RAS version 1.1x Pad.inf file, RAS manual, and release notes.

RAS 1.1x also does not support a RAS Terminal screen (nor the capability to run scripts from a Switch.inf file for use with intermediary security devices). The latter two features were introduced with RAS for Windows For Workgroups 3.11.

Windows 95

Windows 95 was not tested with X.25 RAS Dial-Up Networking and therefore is not supported as a RAS X.25 client, however, it may work. If you want to try RAS X.25 on Windows 95 keep in mind that it does not support the script language used in the Pad.inf and Switch.inf files and that the Pad.inf and Switch.inf files do not exist and cannot be invoked in Windows 95.

To get support for scripting in non-X.25 environments (for example for Slip or PPP Internet access) in Windows 95, obtain Windows 95 Service Pack 1 (SP1). In the Admin directory of SP1 you can find the scripting tool Script.exe. The Admin directory also contains the Script.doc file that describes the commands and syntax of that new and improved script language which is, however, incompatible with the Pad.inf and Switch.inf script language.

Windows 95 supports an after-dialing Terminal window for connections to non-X.25 providers. We have received unconfirmed reports from customers attempting to use Windows 95 with X.25 dial-up that there are problems of receiving incomplete text from the provider PAD in the Terminal window.

Note

Windows NT 4.0 supports the script language used in Pad.inf and Switch.inf as well as the new Windows 95 script language. RAS for Windows for Workgroups 3.11 and Windows NT 3.1, 3.5, 3.51, and 4.0 support RAS Terminal screens for X.25 dial-up. Eicon Technologies supports Windows 95 as a non-RAS X.25 client with the OSI PCGATEWAY software which does not allow connections to a Windows NT RAS server.

Which RAS Clients Support X.25 Dial-Up

RAS 1.1x for LAN Manager 2.1 or later (MS-DOS-based or Windows-based)

RAS 1.1 for LAN Manager for OS/2 (v. 1.3), version 2.1 and later

RAS for Windows for Workgroups 3.11

RAS for Windows NT Workstation and Server 3.1, 3.5, 3.51, and 4.0

Note

The Dial-up Networking client (DUN) for Windows 95 has not been tested as an X.25 dial-up client and is therefore not supported in that function, but may work.

Which RAS Clients Support X.25 Smart Cards (Client and Server function)

The following RAS versions can assume the RAS client or RAS server roll:

RAS 1.1 for LAN Manager for OS/2 (OS/2 v. 1.3), version 2.1 and later

RAS for Windows NT Workstation and Server 3.1, 3.5, 3.51, and 4.0

To make Windows NT work with an X.25 SmartCard, install the driver and the X.25 SmartCard from Eicon Technologies in your computer. Windows NT 4.0 ships with the Eicon X.25 driver. The driver is called “Eicon WAN Adapters.” You do not need to purchase additional software if you have purchased an adapter that is supported by this driver. See “What Third-Party Products Are Required to Set Up a RAS Connection over X.25” below.

Which RAS Versions Can Become RAS Servers Using an X.25 Smart Card

The RAS versions that can become RAS servers are identical to the ones listed above under “ RAS Clients Accessing X.25 Through an X.25 Smart Card.”

RAS and External X.25 PADs - Supported Only in Windows NT 3.1

RAS for Windows NT 3.1 was the only RAS version tested with an external X.25 PAD (see RAS manual page 34, 37 Figure 6.3). Other versions of RAS may work with an external X.25 PAD, but are not supported in that configuration.

For Which X.25 Providers Exist RAS Dial-Up Scripts in the Pad.inf File

These scripts allow an automatic connection of your RAS client with the RAS server over X.25 dial-up:

RAS 1.1, Windows for Workgroups 3.11, and Windows NT 3.1 include the following scripts:

Sprintnet (9600 bps and 2400 bps)

InfoNet (9600 bps and 2400 bps)

The following scripts are included with Windows NT 3.5, 3.51, and 4.0, but should work with Windows NT 3.1, too.

Sprintnet (9600 bps and 2400 bps)

InfoNet (9600 bps and 2400 bps)

Compuserve

SITA Group Network

Alascom/Tymnet/MCI

Telematics

Note

These scripts are not required to connect. You can also connect manually by using a RAS Terminal window and typing the required parameters, user name and password. For X.25 providers that are not listed here, you can write your own script or connect manually. To write your own script, see the section titled “Writing a Pad.inf script to automate Remote RAS Logons.”

In case there were updates to Pad.inf after this document is published, check the Pad.inf file that is installed with RAS automatically to find out for which X.25 carriers your current RAS version includes scripts. The section title (enclosed in square brackets [ ]) for each script usually indicates the name of the X.25 carrier for which the script was designed, except the section titled Eicon X.PAD which is the X.25 Eicon card script for Windows NT servers and clients that have an Eicon card installed.

For Which X.25 Cards Exist RAS Scripts in the Pad.inf File

Only X.25 cards by Eicon Technologies are supported for RAS over X.25. See the following paragraph for more information on Eicon products. There maybe X.25 cards and drivers available by other companies, however, they have not been tested by Microsoft. Please contact that vendor for support.

What Third-Party Products Are Required to Set Up a RAS Connection over X.25

Microsoft only supports Eicon Technologies hardware and software with RAS over X.25. You only need Eicon products for your RAS X.25 server and RAS X.25 direct-connection clients. RAS Dial-Up clients do not need any additional software or adapters.

Software

To get X.25 support on your Windows NT 3.1, 3.5, or 3.51 server you need to purchase the corresponding version WAN Services for Windows NT from Eicon Technologies. However, in Windows NT 4.0 you do not need to purchase Wan Services For Windows NT (it does not exist). Windows NT 4.0 already ships with the Eicon driver for Eicon X.25 adapters. You can install the adapter driver by running Control Panel and choosing Network. The adapter driver name is Eicon WAN Adapter.

Driver Versions and Adapter Support

For Windows NT 3.51 obtain Eicon Wan Services version 3, release 4a (V3R4A). This version works only on Windows NT 3.51, not on Windows NT 4.0. It supports the following Eicon X.25 adapters:

PC, HSI, DPNA, MPNA, C21, and S51

There is a newer version of Wan Services for Windows NT 3.51 known as version 3, release 4c (V3R4C). This version works only on Windows NT 3.51 but has additional adapter support as follows:

S52, S50, C20

The Windows NT 4.0 Eicon Wan Adapter driver supports the following adapters:

C21, S51, PC, HSI, DPNA, and MPNA.

For a complete up-to-date list contact Eicon Technologies.

Note

At the time of this writing (December 1996) Eicon Technologies stated it was close to releasing a new X.25 Windows NT Server product called Connection For Windows NT 4.0. This software has support for new and faster X.25 adapters and is said to support software compression and other new features. To find out more about this new product contact Eicon Technologies. Contact information is provided below.

Per Eicon Technologies, Connection For Windows NT 4.0 supports the following adapters:

All cards the Eicon Wan Adapter in Windows NT 4.0 supports.

New: C20, S50, S52, and S94.

Note

The S-series of adapters, that is the adapters with an “S” in the model name, are generally faster (S stands for Server) than those with a “C” in the model name (“C” stands for Client) which are designed to be for X.25 clients which do not require as much speed.

You can contact Eicon Technologies at:

USA: (214) 239-3270

Canada: (514) 745-5500

Internet: http://www.eicon.com

E-mail: sales@eicon.com

On CompuServe, type: go eicon

Implementing an X.25 RAS Client-to-Server Dial-Up or Direct Connection

Creating Reliable Links When Connecting Through Dial-up PADs

The following is recommended on all workstations that are going to access a dial-up PAD to connect through X.25 to a RAS server using an Eicon card.

Establish all modem connections using a reliable link (either V.42, LAPM, or MNP4) and enable hardware handshaking between your local modem and the workstation. Enable these settings by editing the Remote Access entry's modem settings. Select the check box for modem error correction and the check box for hardware flow control.

Using this feature ensures that there is end-to-end flow control and no data will be lost between the dial-up PAD and the client workstation. You may encounter problems unless these modem settings are made.

Configuring RAS Clients to Use RAS Terminal After Dialing

If RAS does not have an X.25 logon script for your particular X.25 provider (see above “For Which X.25 Providers Exist RAS Dial-Up Scripts in the Pad.inf File”), you need to write a script or configure RAS to pop up the interactive RAS Terminal screen after dialing to display logon prompts from X.25 providers and allow you to type your logon credentials and other parameters. For more information on writing your own X.25 script see “Creating Scripts for the RAS Pad.inf File” below.

RAS 1.x Clients do not have support for a RAS Terminal screen.

To configure a Windows NT RAS 3.1, 3.5, or 3.51 entry to use RAS Terminal after dialing:

1.In Remote Access, select an entry.

2.Click Edit.

3.If the Security button is not available, click the Advanced button.

4.Click Security. (In Windows NT 3.1 and Windows for Workgroups 3.11 this button is labeled Switch).

5.In the After Dialing field, select Terminal. (In Windows NT 3.1 and Windows for Workgroups 3.11 this is labeled Post-Connect).

6.Click the OK button until you return to the main Remote Access screen.

To configure a Windows NT RAS 4.0 entry to use Terminal after dialing:

1.On the Windows NT 4.0 desktop, double-click My Computer and then Dial-Up Networking.

2.In Dial-Up Networking, select a Phonebook entry and then click More and click Edit entry and modem properties.

3.In the Script tab under After Dialing (Login), click on Pop Up A Terminal Window.

To configure a Windows 95 Dial-Up entry to use Terminal after dialing:

1.On your Desktop double-click My Computer.

2.Double-click Dial-Up Networking

3.Double-click Make New Connection and click Configure.

4.Click the Options tab and click the Bring Up Terminal Window After Dialing check box.

Configuring a Windows NT 3.x or Windows for Workgroups 3.11 RAS Dial-Up Client to Run a Pad.inf X.25 Script

You can configure a RAS entry to run a Pad.inf script after dialing. For example, to automate the task of logging onto a remote host, create the script in the Pad.inf file and then configure the RAS entry to use the created script after dialing. The following steps allow you to connect to an X.25 provider through Windows for Workgroups RAS dial-up. These instructions assume that a dial-up script exists for your X.25 provider:

1.In Remote Access, do one of the following:

If you need to add a new RAS Phonebook entry, click Add from the toolbar.

– Or –

If you want to edit an existing RAS Phonebook entry, click Edit from the toolbar.

2.In the Phone Book Entry dialog box, if the Advanced button is displayed, select Advanced, otherwise go to step 3.

  1. In the Port field, select the COM port your modem is connected to.

Note

Do not select the “Any X.25 port” option in the Port drop down list unless you are connecting through an Eicon X.25 card instead of a modem.

4.At the bottom of the Advanced Phone Book Entry dialog box, select X.25.

5.Fill in the fields in the X.25 dialog box:

PAD Type: Enter the name of the X.25 provider (for example, SprintNet, InfoNet, or another provider that you added to Pad.inf file manually with a text editor).

X.121 Address: Provide the RAS server X.121 address

User Data: Enter any additional connection information required by the X.25 host computer. In Windows for Workgroups RAS Setup or X.25, the User Data field is usually left blank unless additional connection information is required such as a user name to identify the caller to the X.25 provider for billing purposes.

Facilities: Facility parameters for the X.25 provider. For example, some X.25 providers support the /R parameter to specify reverse charging. Consult the X.25 documentation or provider for more information. Some providers require the user to provide a password which you can enter here if the script you are using specifies the reserved word “<facilities>“ to send the password to the remote X.25 device.

Note

When using a Pad.inf script the “PAD Type” and “X.121 Address” are mandatory settings. The “User Data” and “Facilities” fields are only used with certain scripts where additional information is required by the X.25 provider.

For more information, see the RAS Online Help under “Setting X.25 Parameters.”

Activating an X.25 Script in Switch.inf instead of Pad.inf in Windows for Workgroups 3.11 RAS

In Windows for Workgroups 3.11 RAS, if you have a problem of Pad.inf script files not executing completely, you can try running your X.25 script from Switch.inf after replacing all references to the special Pad.inf macros X25address, Userdata, and Facilities (if applicable) with the actual values because Switch.inf does not support these macros.

You can configure a RAS entry to run a Switch.inf script before dialing, after dialing, or both. For example, to automate the task of logging onto a dial-up PAD, create the script in the Switch.inf file and then configure the RAS entry to use the created script after dialing.

To activate a Switch.inf script in Windows for Workgroups version 3.11

1.Run Remote Access and select an entry.

2.Click the Edit button.

3.If the Security button is not available, click the Advanced button.

4.Click the Security button. (In Windows NT 3.1 and Windows for Workgroups 3.11 the button is labeled Switch).

5.In the After Dialing box, select the name of the script. The section header in the Switch.inf file is what appears as the name of the script. (In Windows NT 3.1 and Windows for Workgroups 3.11 this box is labeled Post-Connect).

6.Click the OK button until you return to the main Remote Access Screen. When you dial this entry, the selected script runs after RAS dials and connects to the remote host.

Configuring a Windows NT 3.x RAS X.25 Direct-Connection Client to Run a Pad.inf Script

On a direct connect (via an Eicon card) X.25 RAS client you can configure a RAS entry to run a Pad.inf script to call the X.25 RAS server. In most cases you should select the script titled Eicon X.PAD which is for Eicon cards on SprintNet network. If you have an Eicon card, but a different X.25 provider select the Eicon X.PAD script to try it out. If it does not work, see the section titled “Writing a script for Direct X.25 Connections” below.

The following steps allow you to connect to an X.25 provider through a Windows NT direct X.25 connection. These instructions assume that a script exists for your X.25 provider:

1.In Remote Access, do one of the following:

If you need to add a new RAS Phonebook entry, click Add from the toolbar.

– Or –

If you want to edit an existing RAS Phonebook entry, click Edit on the toolbar.

2.In the Phone Book Entry dialog box, if the Advanced button is displayed, select Advanced, otherwise go to step 3.

3.In the Port field, select an X.25 port which usually appears as a COM port with a high number such as COM3 or COM10 or select “Any X.25 port.”

4.At the bottom of the Advanced Phone Book Entry dialog box, select X.25.

5.Fill in the fields in the X.25 dialog box:

PAD Type: Enter the name of the X.25 provider (for example, SprintNet, InfoNet, or another provider that you added to Pad.inf file manually with a text editor).

X.121 Address: Provide the RAS server X.121 address

User Data: Enter any additional connection information required by the X.25 host computer. In Windows for Workgroups RAS Setup for X.25, the User Data field is usually left blank unless additional connection information is required such as a username to identify the caller to the X.25 provider for billing purposes.

Facilities: Facility parameters for the X.25 provider. For example, some X.25 providers support the /R parameter to specify reverse charging. Consult the X.25 documentation or provider for more information. Some providers require the user to provide a password which you can enter here if the script you are using specifies the reserved word “<facilities>“ to send the password to the remote X.25 device.

Note

When using a Pad.inf script the “PAD Type” and “X.121 Address” are mandatory settings. The “User Data” and “Facilities” fields are only used with certain scripts where additional information is required by the X.25 provider.

For more information, see the RAS Online Help under “Setting X.25 Parameters.”

Configuring a Windows NT 4.0 X.25 Client to Run a Pad.inf X.25 Script

These instructions apply to RAS Direct-Connection or Dial-Up X.25 clients:

1.In Dial-Up Networking, select a phonebook entry and then click More and click Edit entry and modem properties.

2.On the Basic tab under Dial Using, select the X.25 card if you have a direct X.25 connection, or, select the COM port your modem is on, if you are using a dial-up X.25 connection. If you need to configure the entry, click on Configure.

3.The X.25 tab, select your X.25 provider dial-up provider (or Eicon X.PAD for direct connections) and type the X.25 address of the remote server.

In most cases of direct-connect RAS X.25 client configurations you should select the script titled Eicon X.PAD which is for Eicon cards on SprintNet network. If you have an Eicon card, but a different X.25 provider select the Eicon X.PAD script to try it out. If it does not work, see the section titled “Writing a script for Direct X.25 Connections” below.

4.Type additional information in the User Data and Facilities boxes if the Userdata and Facilities variables are used in the script you selected.

Configuring a RAS Server for an X.25 Network

To install RAS, run Control Panel and click Network. In Windows NT 3.x click Add Software. In Windows NT 4.0 click the Services tab and click Add. Then add the Remote Access service.

To configure your RAS server for an X.25 RAS network, follow the installation instruction for the X.25 adapter and software. As a rule of thumb use the defaults, for example, leave the X.25 COM port (e.g.: COM10) at the default unless you are absolutely sure another COM port number has to be used.

Also for X.25 Buffering: On each communication port in the Eicon PAD configuration, it is recommended that the packet length supported be left at the default of 128. This will give optimum performance on the server.

Otherwise, connection problems may occur.

Windows NT 4.0 RAS Server

To configure RAS on Windows NT 4.0 for the X.25 adapter:

1.Install the Eicon adapter in your computer according to your computer manufacturer and Eicon adapter installation instructions.

Install the Eicon driver by running Control Panel, clicking Network, then Adapters, and then Add and adding the Eicon Wan Adaters driver.

Configure the driver according to your Eicon WAN Services for Windows NT System Guide or in online Help “Help For WAN Services Configuration” on how to configure the total number of virtual circuits.

The sum of the two-way virtual circuits (TVC) and incoming virtual circuits (IVC) in the X.25 configuration screen must equal the number of incoming X.25 clients the server will support at one time. You may have to find out how many TVCs and IVCs your X.25 line has by contacting your X.25 vendor.

2.Define the number of communication ports to be available for RAS in the XPAD configuration program.

Click the Network option in Control Panel.

Click the Services tab.

If didn't chose to install the Eicon X.PAD services during the Eicon card installation in step1, click the Add button and install the “Eicon X.PAD Driver” and follow the instructions for rebooting.

Restart Windows NT and Control Panel Network and click the Services tab.

Click the Eicon X.PAD Driver in the Network Services list box and click Properties.

Configure the total number of COM ports by selecting the COM ports from the Available Ports list and then clicking Add.

It is recommended that the number of communication ports should be equal to the number of virtual circuits (TVC+IVC) configured.

Click Configure Ports and make sure that the Local Profile and Remote Profile name is RAS. Make changes to the fields in this screen only if you know they are necessary. The default values work with most X.25 networks and RAS.

3.Configure the number of communication ports (Eicon XPAD's) in RAS using the Network option in Control Panel.

Run Control Panel and click Network again.

Click the Services tab, then click Remote Access Service.

Click Properties, click Add, and then click Install X.25 Pad.

Add an X.25 port to RAS by specifying a port name. Take the default or first available port first to avoid connection problems due to unexpected configurations.

Specify an X.25 PAD and click OK.

If you do not see the PAD name you want in the Click X.25 PAD Name box, you can edit the PAD names in Pad.inf. For more information, see the section on X.25 PAD Support in the Windows NT Server Networking Supplement, below in appendix A.

Make sure the selected ports are configured for dial-in.

Windows NT 3.x RAS Server

When configuring a RAS Server to use X.25 over an EiconCard, several steps must be followed to define the number of clients that can connect to the server.

1.Define the total number of virtual circuits that the EiconCard will be configured for.

Click the Network option in Control Panel.

In the Network Settings dialog box, select the EiconCard driver in the Installed Adapter Cards box.

Click the Configure button.

Follow the instructions in your Eicon WAN Services for Windows NT System Guide on how to configure the total number of virtual circuits.

The sum of the two-way virtual circuits (TVC) and incoming virtual circuits (IVC) in the X.25 configuration screen must equal the number of incoming X.25 clients the server will support at one time. You may have to find out how many TVCs and IVCs your X.25 line has by contacting your X.25 vendor.

2.Define the number of communication ports to be available for RAS in the XPAD configuration program.

Click the Network option in Control Panel.

In the Network Settings dialog box, select the Eicon X.PAD Driver in the Installed Network Software box.

Click the Configure button.

Configure the total number of COM ports by selecting the COM ports from the Available Ports list and then choosing the Add button.

It is recommended that the number of communication ports should be equal to the number of virtual circuits (TVC+IVC) configured.

3.Configure the number of communication ports (Eicon XPAD's) in RAS using the Network option in Control Panel. Make sure the selected ports are configured for dial-in.

Configuring the X.25 RAS Server Eicon card to Configure the Client Dial-Up PAD

The client dial-up PAD, through which a remote computer connects to the X.25 network, might have previously been set to X.3-parameter values that are incompatible with the Remote Access Service. Therefore, it is important to configure the X.25 smart card on the Remote Access server so that it changes the client PAD’s X.3 settings to the values described in “X.3 RAS Specifications and Potential Problems” Table 9.3 as soon as a connection is established through X.29 commands. To configure an X.25 smart card to make these changes, see the configuration manual for your specific card.

Note

If the X.25 smart card on the server end does not support commands for the X.29 language, the client PAD script must set the X.3 parameters locally. If you have problems, contact the support site for your X.25 smart card vendor.

Server Bandwidth and the Total Number of Clients

To obtain maximum performance in the RAS clients and to ensure reliable connections, ensure that the aggregate throughput of all clients does not exceed the bandwidth of the RAS server.

For example, four clients running at 2400 bits per second (bps) can be connected to a server with a 9600 bps X.25 line. However, attaching a fifth client at 2400 bps will exceed the server's bandwidth. This will cause all clients to operate at speeds below 2400 bps. If a virtual circuit, communication port, and RAS port are defined for five ports, then five clients can connect using X.25. However, connecting five clients at one time is not recommended since the throughput of each client will be very low and will cause time-outs in the network protocols running over RAS.

Configuring Null Modem Connections on X.25 Networks

When using a null-modem connection on X.25 networks, the server X.25 port must be set to DCE and the client should be set to DTE. If the port on both computers is set to DTE, you cannot connect.

The X.25 null modem should be configured for DCE and internal clocking before an X.25 null-modem client can connect. To configure the X.25 null modem, in Control Panel click Network. In the Network Settings dialog box, click the X.25 card driver in the list of adapters, then click Configure. Select the null modem port, click X.25 and change the node type to DCE. Select X.25 and set the clocking to Internal. Save the configuration and restart the system.

The X.28 Packet Assembler/Disassembler (PAD) and X.3 and X.29 Standards

On an X.25 network, a X.28 Packet Assembler/Disassembler (PAD) converts serial signals from the RAS client modem to and from X.25 packet-switched signals for communication with the X.25 host, for example, a RAS server with Eicon WAN services installed. A PAD is similar to a modem in that it has a command mode and a data transfer mode. In command mode the user can issue X.3 commands to the PAD. In data transfer mode the PAD forwards data between the client and the server which can be any equipment that complies with the X.25 standards like Unix TTY hardware and a Unix host or a RAS client and a RAS server with Eicon WAN Services installed. The host must comply with the X.29 standard , which allows the host to configure the dial-up PAD's X.3 parameters remotely. Therefore, the PAD X.3 parameters can be set by the client or by the server. The client or the server can invoke predefined purpose-specific Profiles that configure all X.3 parameters at once. When writing a new RAS Pad.inf script, it can sometimes save code to invoke a Profile first and then set only a couple parameters with the Set command rather than having to use the Set command to set all X.3 parameters individually.

These X.3 parameters configure the dial-up PAD so that it produces a data stream of required characteristics similar to serial communication where Parity, Data Bits, and Stop Bits are configured. For RAS to work over X.25 the X.3 parameters must be set according to the RAS specifications mentioned below under “X.3 RAS Specifications and Potential Problems.” The X.3 parameters can be set by the RAS client or the WAN services on the X.25 RAS server (the host) depending on the X.25 provider network functionality. The X.29 standard allows the host to modify the dial-up PAD X.3 parameters over the X.25 network, however, in most RAS Pad.inf scripts, the RAS client sets the X.3 parameters. The RAS client can set the X.3 parameters either in a Terminal window or usually inside a script (see Pad.inf).

Some X.25 network providers use additional proprietary parameters that are extensions to the standard X.3 set of 22 parameters. For more information on X.3 extionsions, see “X.3 RAS Specifications and Potential Problems” below.

Therefore, for RAS X.25 set up and troubleshooting it is important to verify that all X.3 parameters are set correctly. If problems occur they can be caused by setting the X.3 parameters correctly, but failing to configure the X.29 parameters which can override the X.3 parameters or vice versa.

Important X.28 Commands

The RAS client can issue the following commands to the PAD when the PAD is in command mode:

Set <X.3 parameter A>:<value> [,<X.3 parameter B>:<value>,<X.3 parameter C>:<value>,…]

Sets the PAD X.3 configuration to define the form of the data stream. Multiple parameter/value pairs can be listed on the same line if each pair is separated by a comma.

Par?

Displays the current settings of all X.3 parameters. This is an important command for verifying X.3 parameter settings during RAS X.25 setup and troubleshooting.

PROF (identifier)

Invokes a predefined set of values for all or a number of X.3 parameters to prepare the data stream for different types of connections eliminating the need to set X.3 parameters individually.

PRF?

Displays the current profile settings. This is an important command for verifying X.3 parameters during setup troubleshooting. This command may not work on all X.25 networks.

RESET

Resets all X.3 parameters back to their default settings. Default settings vary according to vendor equipment used on the particular X.25 network.

Contact your X.25 network provider for other commands, that the RAS client needs to issue before calling the RAS server. For example, on SprintNet the @ sign configures the PAD to use 8 data bits, the letter D requests 9600 bits per second (bps) communication.

Important X.28 Service Signals

The following are X.28 service signals that a RAS client or Windows Terminal client receives when making a call to the X.121 address of the RAS server X.25 host. One of these signals should appear in the Terminal window or the Device.log file if logging is turned on:

PAD Service Signal | Explanation
CLR | Indication that the call has been cleared (not accepted)
ERR | A PAD command signal is in error
COM | The call is connected

Note

Some vendors have non-standard service signals like “connected” or similar.

X.3 RAS Specifications and Potential Problems

The following table shows the RAS X.3 specifications. This table was taken from the Windows NT 4.0 Networking Supplement Chapter 9, titled “X.25 PAD Support.” For a detailed description of the standard 22 X.3 parameters, see “Appendix B: General X.3 Parameter Description.” Give these specifications to your X.25 provider and the information in the following two paragraphs as well.

The values set for the X.3 parameters in the following table apply to the X.25 network equipment of most providers, however, there are exceptions. The values in the table are derived from a SprintNet X.25 network. If your X.25 provider has different X.25 equipment the X.3 values may actually specify different unit sizes or may mean “off” when the same value on SprintNet means “on”. Therefore, to achieve the same effect as on a SprintNet network you may have to specify values that differ from the values in the table below.

For example, if you set parameter 4: to 4:1 to set the Idle Timer to an interval of 50 miliseconds on a Sprintnet x.25 network, the same setting of 4:1 may mean an interval of only 20 miliseconds on your x.25 carrier network (e.g. on a SITA Group Network 4:1 means 40 miliseconds as of July 1994). Therefore, parameter 4: should be set to 4:2 in this example (or should be tried at 4:1 or 4:2 for the SITA Group Network).

As the example demonstrates, it is essential to know how the values for the X.3 parameters on your x.25 carrier network map to those of a SprintNet X.25 network or you may experience connection problems. See your X.25 providers documentation for more specific information on your X.25 network if you have problems.

A note on syntax. The parameter number is always separated from the parameter value by a colon. for example, to set parameter 1 to a value of 126 you type:

1:126

To set parameters 1 and 2 to the value 0 (zero) from within the RAS Terminal Window separate the two parameter/value pairs with a space. For example

set 1:0 2:0

and press the enter key.

X.25 Configuration Values

Parameter number | X.3 parameter | Value
1 | PAD Recall | 0
2 | Echo | 0
3 | Data Fwd. Char | 0
4 | Idle Timer | 1
5 | Device Ctrl | 0
6 | PAD Service Signals | 1
7 | Break Signal | 0
8 | Discard Output | 0
9 | Padding after CR | 0
10 | Line Folding | 0
11 | Not Set |
12 | Flow Control | 0
13 | Linefeed Insertion | 0
14 | Padding after LF | 0
15 | Editing | 0
16 | Character Delete | 0
17 | Line Delete | 0
18 | Line Display | 0
19 | Editing PAD Srv Signals | 0
20 | Echo Mask | 0
21 | Parity Treatment | 0
22 | Page Wait | 0

Caution:

Failure to set these values as shown prevents the Remote Access Service from functioning properly. For information on setting these values, see the instructions with your X.25 smart card.

Some X.25 network providers use additional proprietary parameters that are extensions to the standard X.3 set of 22 parameters. Northern Telecom Equipment may support the following X.3 parameter extensions. Not all extended X.3 parameter information was available or confirmed at the time of publishing this paper, therefore, please do not rely on the information in the following table. Instead, please consult your X.25 provider whether extended X.3 parameters are used on the X.25 network. The information in this table is provided as an example only and will be updated as information becomes available.

Example Extended Parameter Table

Extended Parameter Number | Extended Parameter
113 | ?
114 | Abort Output
118 | Character Delete
119 | Line Delete
120 | Line Display
121 | Additional data forwarding?
122 | Additional data forwarding?
123 | Parity on Input data stream; 0 means OFF
124 | ?
125 | Output Pending Timer
126 | Linefeed insertion

The SITA Group Network is an X.25 provider that supports these additional parameters and maybe more. Therefore, if your provider equipment uses extended X.3 parameters, it is important for RAS X.25 setup and troubleshooting to verify that all X.3 parameters are set correctly including these extended parameters. If problems occur they can be caused by setting the standard X.3 parameters correctly, but failing to configure the extended X.3 parameters which can override the X.3 parameters or vice versa. For example, the following parameters can cancel each other based on the example table of extended parameters above:

X.3 Parameter Number | Corresponding Example Extended Parameter Number
13 | 126
16 | 118
17 | 119
18 | 120

Consult your X.25 provider for a complete list of parameters that can cancel each other's effect, if applicable.

Writing a Script for Direct X.25 RAS Client Connections with Non-Eicon X.25 Cards

If you plan on using a non-Eicon X.25 card, verify first that the drivers are available to work with the version of your RAS server.

If you have a non-Eicon X.25 card in a RAS client, but the Eicon X.PAD script does not work, modify the script according to your X.25 card vendor and your X.25 providers requirements to initialize the PAD and make the X.121 address call to the RAS server. To do that, first make a copy of the Eicon X.PAD script and copy it to the end of Pad.inf. Rename the script title so that it is unique in Pad.inf and then start modifying the copied script.

For more information on modifying Pad.inf scripts, read the section below titled “Writing a Pad.inf Script to Automate Remote RAS Logons.”

Automating Remote RAS Logons Using Pad.inf Scripts

Use an Existing Script or Write a New Script

Instead of using the interactive RAS Terminal screen, you can automate the logon process to X.25 providers by using an existing script in the Pad.inf file if you are using an X.25 provider for which a script is provided. See the section above “For Which X.25 Providers Exist RAS Dial-Up Scripts in the Pad.inf File”. Keep in mind that these scripts are provided only for your convenience and are not guaranteed by Microsoft to work because X.25 providers may change or upgrade their equipment at any time which may cause the requirements for scripts to change, in effect making the scripts obsolete. If this is the case in your situation or if your X.25 provider is not listed at all you can create a modified or new script in the Pad.inf file yourself.

Pad.inf was specifically designed for X.25 scripts, but most of the information pertaining to Pad.inf scripting also applies to Switch.inf scripting. However, Pad.inf supports a few more features and has a few more requirements. If you have problems using Pad.inf under Windows for Workgroups please see “Potential Pad.inf Problem in Windows for Workgroups” below in the Troubleshooting section.

Creating Scripts for the Ras Pad.inf File

Note

In Windows NT version 4.0, you must use the script language described in this section if you are planning to use Pad.inf for X.25 dial-up. The new and improved script language described in Script.doc in Appendix F (also in the Windows NT 4.0 %SystemRoot%\System32\RAS directory) does not work in Pad.inf. RAS X.25 dial-up has not been tested with the new script language using a regular *.scp file. If you are planning to run your script on a previous version of RAS as well, you must use the Pad.inf script language described in the following paragraphs:

The Pad.inf file is like a set of small batch files or scripts, all contained in one file separated by script titles called section headers. A Pad.inf script can contain six elements: a section header, comments, commands, responses, response keywords, and reserved macro keywords.

In addition to dividing the Pad.inf file into individual scripts, section headers start the scripts. Comment lines are used to document the script. Any other line in a script is either a command or a response. A command is issued from the local RAS client. A response is received from the remote device or computer.

To write an automatic script for your RAS client you must know the required commands and corresponding responses for the intermediary device. The commands and responses must be in the exact order that the device expects to encounter them. Branching statements, such as GOTO or IF command, are not supported by the Pad.inf and Switch.inf script language. The required sequence of commands and responses from the PAD device should be in the device documentation. If you are connecting to a commercial service, the required sequence of commands and responses should also be available from the service support staff.

The Pad.inf file contains scripts for different X.25 providers or different PADs that the RAS user calls. The scripts are activated by configuring Remote Access Phonebook entries as described under “Configuring a Windows NT 3.x or WFWG 3.11 RAS Client for a Pad.inf X.25 Script” and “Configuring a Windows NT 4.0 RAS Client for a Pad.inf X.25 Script.”

For additional information on writing a Pad.inf script, see the instructions in the Windows NT 3.5 RAS manual, pages 65-67

SECTION HEADERS

A section header marks the beginning of a script, is enclosed in square brackets, and cannot exceed 31 characters. For example:

[Route 66 Login]

Each script requires one section header. The section header appears in the RAS Phonebook field allowing you to select RAS Terminal or any other Pad.inf script. For more information, see the “Activating Pad.inf Scripts” section below.

COMMENTS

Comment lines are preceded by semicolons (;) in the left most margin (column one), are optional, and can be placed anywhere in the file. For example:

;This script was created by Patrick on September 29, 1995

COMMANDS

A command comes from the local computer. A response comes from the remote device or computer. The COMMAND= statement, which can be used in three different ways, is used to send commands to the intermediary device.

Note

Use upper case for all Pad.inf commands.

DEVICETYPE=pad

DEVICETYPE=pad tells RAS that it is not communicating with a modem which is the default if DEVICETYPE= is completely omitted. Use the string as the first line of your script only if your are writing a new script for communication with an X.25 adapter.

DEFAULTOFF=

DEFAULTOFF= by itself specifies that no default off commands are going to be send to the PAD. This command allows you to specify a custom macro, but is usually only used in the Modem.inf file. See the Modem.inf file for examples.

MAXCARRIERBPS=<bits per second>
MAXCONNECTBPS=<bits per second>

The MAXCARRIERBPS=<bits per second> and MAXCONNECTBPS=<bits per second> should be specified for every X.25 script. These parameters specify a bits-per-second (bps) rate, however, these rates are not dictating the actual maximum carrier or connect rate. Instead, they indicate to the RAS server to wait for a response from the client as long as it would wait for a response over a connection of that bps rate. For example, the client-server carrier speed may occur at 9600 bps, but both parameters may be set as follows to allow the server to wait longer before timing out:

MAXCARRIERBPS=1200
MAXCONNECTBPS=1200

The following setting allows the server to time out faster:

MAXCARRIERBPS=9600
MAXCONNECTBPS=9600

COMMAND=

COMMAND= by itself causes an approximate two second delay, depending on CPU speed and the presence of caching software (for example, SMARTDRV.EXE). If the intermediary device cannot process all of the characters on a COMMAND=<CustomString><cr> line (because they are sent at once), use multiple COMMAND= statements.

COMMAND=<CUSTOM STRING>

COMMAND=<custom string> sends the custom string and causes a slight delay of several hundred milliseconds (depending on CPU speed and installed caching software). The delay gives the intermediary device time to process the custom string and prepare for the next command.

COMMAND=<CUSTOM STRING> <cr>

COMMAND=<custom string><cr> sends the custom string immediately.

Consult the remote device documentation to determine which strings are required.

RESPONSES

Each command line is followed by one or more response lines. Consult the remote device documentation to determine which response strings and dialogs are expected by the remote device. RAS compares responses received with what you put on the response lines. If it matches, RAS uses the response related keyword and macro.

RESPONSE KEYWORDS

The keyword in a response line specifies what your RAS client does with the responses it receives from the remote computer.

The response strings your RAS client receives from the remote device or online service can be used with one of the following keywords in response lines:

OK= remote_device_response <macro>

The OK keyword indicates that RAS can execute the next script line if the condition on the right side of the equal sign is met.

LOOP= remote_device_response <macro>

The LOOP keyword indicates to RAS to wait for a response that matches the condition to the right of the equal sign and if that condition is met to wait for the same response again. If a response does not meet the condition on the right side of the equal sign RAS executes the next line.

CONNECT= remote_device_response <macro>

This keyword is used near the end of the script to indicate the end of the script.

ERROR_NO_CARRIER= remote_device_response <macro>

This keyword is used to test for the presence of a carrier. Intermediary devices report their presence in different ways.

ERROR_DIAGNOSTICS= remote_device_response <macro>

This keyword can be used in conjunction with the <Diagnostics> macro to allow RAS to display a message box containing a problem cause and diagnostic information.

These response related keywords are usually clustered, but do not have to be. CONNECT= is usually the last line, unless it is followed by an ERROR_line. For example:

CONNECT=<match>“ CONNECT”
ERROR_NO_CARRIER=<match>“NO CARRIER”
ERROR_DIAGNOSTICS=<cr><lf><Diagnostics>
ERROR_DIAGNOSTICS=<lf><cr><lf><Diagnostics>

NoResponse

The RAS client always expects a response from the remote device. The client waits until a response is received unless a NoResponse statement follows the COMMAND= line. If there is no statement for a response following a COMMAND= line, the COMMAND= line still executes, but the script does not execute any further.

RESERVED MACRO KEYWORDS

The macros in the following list are reserved words, which you cannot define in Pad.inf to create a new entry. Reserved words are case insensitive.

Macro | Function
<x25address> | Inserts the value you type in the “X.121 Address” field (Windows NT 3.x, WFWG 3.11) or “Address” field (Windows NT 4.0) of the RAS application (Dial-Up client).
<userdata> | Inserts the value you type in the User Data field in the RAS application (Dial-Up client).
<facilities> | Inserts the value you type in the Facilities field in the RAS application (Dial-Up client).
<cr> | Inserts a carriage return.
<lf> | Inserts a line feed.
<match> | Reports a match if the string enclosed in quotation marks is found in the device response. For example, <match>“Smith” matches Jane Smith and John Smith III.
<?> | Inserts a wildcard character. For example, CO<?><?>2 matches COOL2 or COAT2, but not COOL3.
<hXX> | Allows any hexadecimal character to appear in a string including the zero byte, <h00>. (XX represents hexadecimal digits)
<ignore> | Ignores the rest of a response from the macro. For example, <cr><lf>CONNECTV-<ignore> reads the following responses as the same: “crlfCONNECTV-1.1” and “crlfCONNECTV-2.3.” If a lot of information is ignored, like a large welcome banner, RAS might time out and move on to the next script line. This usually causes problems. To avoid this problem, use multiple pairs of COMMAND= followed by OK=<ignore> to force RAS to wait longer and ignore additional response stings. For example: COMMAND=OK=<ignore> COMMAND= OK=<ignore>
<diagnostics> | This macro function can be used in conjunction with the ERROR_DIAGNOSITICS= keyword macro to allow RAS to display a message box containing a problem cause and diagnostic information.

Stepping Through an Example Script

This topic describes each part of a relatively long X.25 script for a fictitious X.25 provider. Not every script has to contain as many commands as this one, but for training purposes this type of script is most helpful. Please see the Pad.inf file for the following examples of short scripts: Compuserve or Alascom/Tymnet/MCI.

Every script must start with a script header followed by DEFAULTOFF=, MAXCARRIERBPS=<baudrate>, and MAXCONNECTBPS=<baudrate> to properly inform the RAS client software of transmission speeds and corresponding expected delays, for example:

[Fictitious X.25 Provider]

DEFAULTOFF= MAXCARRIERBPS=9600 MAXCONNECTBPS=9600

Next issue a command to the remote computer, followed by one or more response lines. This initial command might be simply to wait for the remote computer to initialize and send its logon banner. The initial command depends on your X.25 carrier equipment. In some cases it is necessary to wait two seconds after making the telephone connection to the X.25 PAD modem so the PAD can initialize and get ready to receive commands from your RAS client. So a COMMAND= to cause a two second delay should be used first in such a case, otherwise not. Note, the COMMAND= is preceded by a line with a semicolon indicating to RAS it is a comment line. Use comments to allow easy debugging in the future. Near the end of this walk-through the comment lines are used instead of regular text:

; Give the PAD 2 seconds time to initialize after the modem connection. COMMAND=

If there is no response expected, RAS needs to be informed about that or it waits forever for a response. So the next line should be:

NoResponse

On a computer with a Pentium processor you may need to add another COMMAND= followed by NoResponse to achieve an approximate two second delay since the COMMAND= delay is controlled by CPU speed or slowness not actual time.

Next the X.25 provider requires you to select 8 data-bit communication and send an “@” sign to the PAD upon which the PAD is not expected to respond. To delay RAS from moving on to the next command too fast the carriage return (<cr>) is left out:

; set 8 databit mode COMMAND=@ NoResponse

Next a “D” should be sent to configure the PAD for 9600 baud. However, through testing it was found that the @ command needs about 3 seconds to be processed by the PAD before it is ready to receive the next command; so to give the PAD some more time (about 2 more seconds) in addition to leaving out the <cr> in the previous command, use the following two lines:

; Delay RAS 2 more seconds to give the PAD time to process previous command

COMMAND= NoResponse

Next send the D without a carriage return to cause RAS to delay moving on to the next command; the response can be ignored:

; D sets 9600 baud on X.25 network COMMAND = D OK=<ignore>

Next the caller's user id and password need to be entered.

; Enter your user id in the Remote Access program's X.25 Settings “User ; Data:” field. COMMAND=<UserData><cr> The response from the PAD after the user ID is not important: OK=<ignore>

Next the caller's password needs to be provided to the X.25 provider. For that the Facilities variable is used which allows the user to enter the password in the RAS user interface:

; Enter your x.25 password in the Remote Access program's X.25 Settings ; “Facilities:” field. COMMAND=<Facilities><cr>

The response should contain the word “active” if the user ID and password were recognized:

OK=<match>“active”

If the user ID and password are not recognized, the error information provided in the response from the PAD should be displayed by RAS with the help of the <Diagnostics> macro. Since the X.25 equipment error response has two versions (preceded by a different number of carriage returns and line feeds), two error lines are added to make sure both error response versions are received by the RAS client and displayed on the screen:

ERROR_DIAGNOSTICS=<ca><lf><cr><lf><lf><Diagnostics> ERROR_DIAGNOSTICS=<lf><cr><lf><Diagnostics>

Next profile 6 is invoked to set all 22 (or more) X.3 parameters to values that are close to the X.3 RAS specifications. The few parameters that are known to differ from the X.3 RAS specifications will be set later:

COMMAND=PROF 6<cr> NoResponse

The profile set the X.3 Echo facility to Off (2:0) which prevents responses from the PAD being send to the RAS client. It is important to see the responses from the PAD so problems can be identified, therefore parameter 2 is set to On again:

; turn echo back On to allow PAD responses to be sent to RAS client COMMAND=SET 2:1<cr> OK=<ignore> COMMAND= NoResponse ; set the standard parameters that the profile didn't set to X.3 RAS specifications yet. COMMAND=SET 4:1,6:1,16:0,17:0,18:0,19:0,21:0<cr> OK=<ignore> COMMAND= NoResponse ; set certain extended X.3 parameters so they don't undo what the standard ; parameters were configured for COMMAND=SET 118:0,119:0,120:0<cr> OK=<ignore> COMMAND= NoResponse

If you are in the process of debugging X.3 parameter settings use the following two lines to request the PAD to send all X.3 parameter settings information to the RAS client so you can capture it in the Device.log or Modemlog.txt files.

COMMAND=PAR? OK=<ignore> ; Call the RAS X25 server COMMAND=<x25address><cr><lf> ; CONNECT response means that the connection completed fine. CONNECT=<match>“COM” ; ERROR_DIAGNOISTICS response means connection attempt failed - the X25 ; DIAGNOSTIC information will be extracted from the response and sent ; to the user. ; ERROR_NO_CARRIER means that the remote modem hung up. ; ERROR responses are for generic failures. ERROR_NO_CARRIER=<match>“NO CARRIER” ERROR_DIAGNOSTICS=<cr><lf><Diagnostics>

; Finally turn echo Off again to comply with X.3 RAS specifications

COMMAND=SET 2:0<cr> NoResponse ; End of Pad.inf script

Creating One Script for Multiple Situations

RAS for Windows NT 4.0 supports a new script language that supports subroutines, IF, WHILE, and GOTO command, etc. which allows for complex scripts, however, this script language does not work in the Pad.inf file. It is designed to work with PPP and SLIP dial-up connections in *.scp files invoked in RAS under the Script tab (not the X.25 tab) and has not been tested with X.25 dial-up. Windows 95 supports the same script language, but has not yet been tested with X.25 and therefore is not supported in that environment; however, it may work.

A company with employees working at different locations may need to provide employees with the ability to log on to an X.25 service from various locations requiring different scripts. Not all employees may have the same RAS versions and the RAS script language on pre-Windows NT 4.0 RAS does not provide any IF, or GOTO statements or support for subroutines. Therefore, you cannot test for logical responses or errors received from a PAD and then branch off to a different execution path. However, the script language does allow you to catch errors and display them on the screen using:

ERROR_DIAGNOSTICS=<cr><lf><Diagnostics>

To provide a variety of RAS clients with a Pad.inf or Switch.inf script you need to write several scripts in the Pad.inf file to manage all local logon dialog variations. For example:

If you have a Windows for Workgroups 3.11 RAS client or Microsoft RAS 1.1a client, set an environment variable to a value representing the local X.25 carrier. Then run a batch file that copies the correct script to the file name Pad.inf or switch.inf (depending on the value of the environment variable) and then start Windows.

If you have a Windows NT RAS client, create an icon that runs a similar batch file that tests the environment variable and then runs RAS. All scripts can be provided on one disk and all the user has to do is copy the files to a directory on their hard drive and set the environment variable. This can be automated as well to minimize user interaction.

Troubleshooting a X.25 RAS Client-to-Server Dial-Up or Direct-Connection

The following sections contain formation about X.25 RAS connections.

Frequent Problem Areas

The following are often especially difficult problem areas when implementing a RAS X.25 network:

On the Client side:

Writing a new logon script for communication with the dial-up PAD.

Setting the x.3 paramenters on the x.25 providers network.

On the Server side:

The server side usually does not experience difficult problems unless the Eicon software is erroneously changed from the default settings.

Troubleshooting Connection Problems During Implementation

To ensure proper operation of the dial-up X.25 RAS client and server, do the following:

1.Verify your RAS client can establish a simple RAS link with the RAS server over a regular public switched telephone network (PSTN) using a supported modem.

This verifies the RAS software on client and server is properly working and the serial port, cable, and modem on the client side are properly configured.

Note

If problems persist over PSTN and you have an internal modem in the client or the serer, test with an external modem. This configuration is usually easier to troubleshoot because the modem can be easily reset by switching it on and off while an internal modem can only be reset completely if the computer is turned off and on again. External modem configurations are also less prone to interrupt and i/o address conflicts.

To isolate the problem to the client or the server it is often useful to have two RAS clients with different versions of RAS to test with. If the problem occurs with one client and not the other, you know that the server is configured correctly and the client that failed has the problem.

If problems persist PSTN connections, use the MS RAS troubleshooters and the MS Knowledge Base available on the MS support web site http://www.microsoft.com or query your TechNet CD.

If simple PSTN connections work and the problems over a X.25 connection persist, the problem lies with the X.25 network or the RAS server X.25 configuration. Read item number 2.

2.Make sure the Eicon software and hardware is installed on the RAS server without changing any default settings, for example, do not change the COM port numbers Eicon software is configured to use. For example, Eicon WAN Services version 3, release 1 on Windows NT Server 3.51 uses COM10 as the default COM port. If problems persist, read item 3.

3.Verify that you can type messages back and forth over x.25 using the Windows Terminal (not the RAS after-dialing Terminal window!) application on the client and server side.

4.If this works but RAS connections do not, the server Eicon software is probably configured correctly and the problem lies with the X.3 parameter settings not matching the RAS specifications. Read item 4.

5.Verify that your X.25 provider has configured the X.25 network according to the RAS X.3 specifications above or if it is your responsibility to set the X.3 parameters for each call, verify that you are setting them correctly. To resolve this problem,

If you are using a script:

Turn on logging on your RAS client (See “Enabling Logging and Creating a Device.log file” below).

Insert the command COMMAND=PAR? into your X.25 dial-up script after your X.25 vendor user account name and password and after your attempt to set the X.3 parameters so you can later verify the result of your attempt.

Call the RAS server to run the script with the PAR? command.

Verify that the Device.log or Modemlog.txt file captured the X.3 parameter settings.

Compare the X.3 parameters in the Device.log file to the Microsoft X.3 RAS Specifications above and note any mismatches. Be sure to read “X.3 RAS Specifications and Potential Problems” above.

If any parameter values are set incorrectly, correct your script in Pad.inf to set them to the correct value. If you are already setting them to the correct value in your script, the problem may be a timing issue where the RAS client is sending the script command too fast for the PAD to process. Adjust your script by inserting more COMMAND= statements to delay RAS and give the PAD more time to process the previous command (See “Stepping Through an Example Script” above).

There is also a possibility of you trying to set a parameter that is not changable by users. For example, many X.25 providers have a fixed terminal speed (X.3 parameter 11) and any attempt to change that setting causes an error. Check with your X.25 provider if there are any other X.3 parameters that are “frozen.”

If you are using RAS Terminal:

After you type your X.25 vendor user account name and password and after typing the X.3 parameter settings, type the PAR? command. Write down the resulting PAD response with all the X.3 parameter settings and compare it to the RAS X.3 specifications.

If any parameter values are set incorrectly, you may not have specified them when you gave the Set command. Be sure to set them to the correct value the next time.

There is also a possibility of you trying to set a parameter that is not changable by users. For example, many X.25 providers have a fixed terminal speed (X.3 parameter 11) and any attempt to change that setting causes an error. Check with your X.25 provider if there are any other X.3 parameters that are “frozen.”

Understanding RAS X.25 Configurations

In all troubleshooting, the cause needs to be identified through tests that isolate the problem to the component that is not working properly. To be able to isolate a problem quickly an understanding of the following is helpful and sometimes necessary:

Hardware and software components and their functionality.

Required sequence of events and expected feedback from the software.

Troubleshooting tools available.

A. Hardware and Software Components of X.25 Configurations

Verify that all the following hardware and software components are installed and configured correctly:

RAS Client

Software

RAS software

X.25 Logon Script (unless RAS Terminal is used)

Latest X.25 card driver (if X.25 SmartCard is used and supported in this client)

Hardware

Modem

X.25 SmartCard (if used)

Phone line

X.25 Provider

Software

X.3 settings

X.29 settings

Hardware

X.28 Packet Assembler/Disassemblers (PADs)

RAS Server

Software

RAS software

X.25 card driver(if X.25 SmartCard is installed)

Wan Services if applicable

Hardware

X.25 SmartCard (unless external PAD is used)

Cables

B. The Sequence of Events During RAS X.25 Connections

This section has two subsections because the events during RAS X.25 dial-up connections differ from the events during direct RAS X.25 connections (where both the RAS client and the RAS server have an X.25 card installed). Read the section that applies to your configuration.

X.25 Dial-Up Connections

For a successful dial-up RAS connection to a remote network over X.25 to a RAS X.25 server, the RAS client needs to make five successfull connections, that is, the RAS client has to use command mode five times and each time following the command mode switch into a data transfer mode that becomes the command mode for the next connection level. After the fifth connection the user can issue network commands to the remote network or run applications from the remote network:

Connection I—Connect to the dial-up PAD of the X.25 provider.

Connection II—Authenticate with the X.25 provider software.

Connection III—Connect over X.25 to RAS server X.25 adapter.

Connection IV—Authenticate with the RAS server service.

Connection V—Log on to the remote Windows NT domain.

These five connection phases can be broken down into the following actions:

X.25 Dial-Up Connection I

1.The RAS client dials the number for the X.25 service providers dial-up PAD.

2.The dial-up PAD and the client modem establish a connection. (The RAS server is not involved yet, that is, the RAS server is not aware of the RAS client call to the X.25 dial-up PAD.)

X.25 Dial-Up Connections II and III

The RAS client supplies miscellaneous information, including but not limited to:

For X.25 Dial-Up Connection II

PAD configuration parameters to set databits, echo, etc.

User name to identify the user for billing purposes to the X.25 provider.

Password to maintain security on the X.25 customer account.

For X.25 Dial-Up Connection III

X.3 parameters to configure the X.25 network according to RAS specifications.

The RAS server X.121 address to call the RAS server host PAD configured with Eicon WAN services. The host PAD accepts the X.25 connection and the client and host PADs go into data transfer mode.

This information is supplied by the RAS client through two methods depending on your configuration:

The RAS client displays a RAS Terminal window (available in Windows For Workgroups 3.11, Windows 95, Windows NT 3.1, 3.5, 3.51, and 4.0) and the user types the information.

The RAS client executes a logon script that provides the information with the correct timing which is critical.

X.25 Dial-Up Connection IV

The RAS client and the RAS server begin the RAS client authentication conversation. If the RAS client is authenticated as an authorized RAS client, the RAS connection is established and the RAS client and server go into data transfer mode.

X.25 Dial-Up Connection V

The RAS client logs on to the remote domain for network access. RAS 1.1 clients need to log on with the Net Logon command. RAS for Windows for Workgroups 3.11 clients can log on using Log On/Off icon in the Network group in Program Manager. Windows NT RAS clients are logged on automatically with the credentials they provided during system startup, or if those credentials differ from the remote domain credentials are prompted for their credentials for the remote domain when accessing resources that require proper permission.

X.25 Direct Connections

For a RAS client to connect to a remote Windows NT network over a direct X.25 to X.25 RAS connection between RAS client with a X.25 card installed and RAS server (also using an X.25 card), the RAS client needs to make three successful connections:

Connection I—Connect over X.25 to the RAS server Eicon WAN services.

Connection II—Authenticate with the RAS server service.

Connection III—Log on to the remote Windows NT domain.

X.25 Direct Connection I

The RAS client issues X.3 PAD configuration parameters to set data bits, echo, etc. and calls the RAS server X.121 address using a script in Pad.inf. The RAS server host PAD configured with Eicon WAN services responds and accepts the X.25 connection. The client and host PADs go into data transfer mode.

X.25 Direct Connection II

The RAS client and the RAS server begin the RAS client authentication conversation. If the RAS client is authenticated as an authorized RAS client, the RAS connection is established and goes into data transfer mode.

X.25 Direct Connection III

The RAS client logs on to the remote domain for network access. RAS 1.1 clients for OS/2 need to log on with the Net Logon command. Windows NT RAS clients are logged on automatically with the credentials they provided during system startup, or if those credentials differ from the remote domain credentials are prompted for their credentials for the remote domain when accessing resources that require proper permission

Troubleshooting Scripts using Device.log and RAS Terminal

Before writing scripts to automate the process of logging onto a PAD, use the RAS Terminal feature to familiarize yourself with the logon sequence of events. For more information on activating the RAS Terminal feature, see the section “Implementing an X.25 RAS Client-to-Server Dial-Up or Direct Connection” above.

To find errors that prevent your scripts from working, log all information passed between RAS, the modem, and/or the PAD (including errors reported by any other intermediary device in your configuration) by turning on RAS logging (see “ENABLING LOGGING AND CREATING A Device.log FILE” in this section below).

After you enable logging, the Device.log file is created (when you start RAS) in the Windows NT %systemroot%\SYSTEM32\RAS subdirectory or the Windows for Workgroups \WINDOWS directory.

If an error is encountered during script execution, execution halts. Determine the problem by studying any RAS error messages that appear on the screen and by studying the Device.log file contents. Make necessary corrections to the script and then restart RAS. If you are running Windows for Workgroups RAS 3.11 and the script execution halts even though you verified all lines to be error free, read the paragraph titled “Potential Pad.inf Problem in Windows for Workgroups” in the implementation section below.

The Device.log file appends any communication as long as RAS is not restarted. If you restart RAS, the Device.log file is erased and re-created. Therefore, if you make changes to Pad.inf during your script development which always require you to restart RAS, and you need to save the current traces contained in the Device.log file, rename the Device.log file before starting RAS again.

Enabling Logging and Creating a Device.log or Modemlog.txt File

To enable logging and create a Device.log file under Windows NT 3.x or 4.0:

Warning

Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

1.Hang up any connections, and exit from Remote Access.

2.Run Registry Editor (REGEDT32.EXE).

3.From the HKEY_LOCAL_MACHINE subtree, go to the following key:

SYSTEM\CurrentControlSet\Services\RasMan\Parameters

4.Change the value of the Logging parameter to 1:

Logging:REG_DWORD:0x1

Logging begins when you restart Remote Access or start the Remote Access Server service (if your computer is receiving calls). You do not need to shutdown and restart Windows NT.

To enable logging and create a Device.log file under Windows for Workgroups:

1.Using a text editor such as Windows Notepad, edit the System.Ini file.

2.In the [Remote Access] section, add the following line:

LOGGING=1.

3.Save the file.

In Windows 95 the Device.log text file is named Modemlog.txt instead and is created in the Windows directory when you restart Windows and RAS.

To enable logging and create a Modemlog.txt file under Windows 95:

1.On your Desktop double-click My Computer.

2.Double-click Dial-Up Networking

3.Double-click Make New Connection and click Configure.

4.Click the Connection tab and click on Advanced.

5.Click the Record A Log File check box.

Troubleshooting RAS X.25 Client Pad.inf Script Timing Problems

Many script problems occur because of timing problems in the command-response dialog between the RAS client and the dial-up PAD. Often the RAS client sends commands too soon to the dial-up PAD because the PAD is still processing the first command while the second command already arrives from the RAS client. In those cases the second command is lost by the time the PAD becomes available. If the PAD has a buffer to store the command, the timing becomes less of an issue, but most PADs do not have buffers for storing remote commands.

To diagnose timing problems and measure timing intervals precisely, you may use a serial analyzer such as a Hewlett Packard HP 4957A, but a serial analyzer is not required. Serial analyzers can be expensive relative to using the trial and error method of troubleshooting a script which takes longer, but usually is successful, too.

To prevent the RAS X.25 client from sending commands too soon, use the COMMAND = without the carriage return macro (<cr>), or the COMMAND = <PAD_X.28_or_other_command> without <cr>, and the LOOP = commands. The tricky part is that the amount of time delayed with these commands varies by the speed of your processor and the presence of caching software in your RAS client. Therefore, on a 386-based computer the COMMAND= and the COMMAND= <PAD_X.28_or_other_command> cause a longer delay than on a 486-based or Pentium-based computer.

For example, if your Device.log or Modemlog.txt file shows that a certain command in your script is not received by the PAD, insert a “COMMAND=“ line before that command to gain about a 2 second delay.

For more information, see the text and the examples in the Switch.inf and Pad.inf files in the Windows NT <SystemRoot>\System32\RAS directory.

After the X.25 provider has given you the commands you need to send from your script or RAS Terminal screen to log on to the dial-up PAD, start out by issuing the commands manually in a RAS Terminal window. Once you verified that this works you can start building a script either from scratch or by copying one of the existing scripts to the end of the Pad.inf file and renaming and modifying that script to suite your X.25 provider equipment.

Potential Pad.inf Problem in Windows for Workgroups

RAS for Windows for Workgroups 3.11 reportedly may under certain circumstances not execute Pad.inf scripts completely even though no error was encountered in the script. If that problem occurs you can try copying your Pad.inf script to the Switch.inf file and replace the special Pad.inf macros X25address, Userdata, and Facilities (if applicable) with the actual values because Switch.inf does not support these macros in Windows for Workgroups. See the section “Activating an X.25 Script in Switch.inf in Windows for Workgroups 3.11 RAS.”

Note

If you are using Windows for Workgroups make sure that you have the RAS program files with a file date of April 1994 or later installed. The update to these RAS files is free. Call Microsoft Technical Support to obtain these files. These files make RAS memory usage more efficient and eliminate error 640 and other symptoms. For more information see the Microsoft Knowledge Base on www.microsoft.com or your TechNet CD.

Troubleshooting the X.25 Provider X.3 Parameters

See the information provided above under “X.3 RAS Specifications and Potential Problems.”

Troubleshooting the RAS X.25 Server During Setup

Problem: After calling the RAS server X.121 address the following server PAD response appears on the X.25 provider monitoring equipment:

call cleared - remote directive

(the X.25 provider helpdesk person sees this on the screen) and the RAS Client Device.log file captures:

clr conf

Solution: This is a sign of the RAS server Eicon card not being properly initialized. Make sure that the Eicon software is not changed from the default configuration. Verify the COM port used by the Eicon software, for example, COM10, is not changed to another COM port, for example, COM4.

Eicon Software Trace Utility

Eicon Technologies provides the EiconCard Loadable Module Management Utility (ECMODULE) which allows the tracing of all activity on the Eicon card. These traces may have to be interpreted with the help of an Eicon support engineer.

Troubleshooting Transmission Reliability Problems

The following are X.25 troubleshooting tips from the Windows NT 4.0 Help File:

Problem: After connecting through a dial-up PAD, the server consistently fails to authenticate the client.

Solution: If the remote access server is running and clients cannot connect to it directly through an X.25 smart card or an external PAD, the dial-up PAD may have the wrong X. 3 parameters or serial settings. Ask your administrator for the correct settings, listed in the Chapter 9 “X. 25 PAD Support” in the Networking Supplement of Windows NT Server 4.0.

Problem: A connection has been established, but network drives are disconnecting, and you are dropping sessions or getting network errors.

Solution: Congestion on the Remote Access server's leased line may be the cause. The administrator should make sure that the speed of the leased line can support all the COM ports at all speeds clients use to dial in.

For example, four clients connecting at 9600 bps (through dial-up PADS) require a 38,400-bps (four times 9600) leased line on the server end. If the leased line does not have adequate bandwidth, it can cause timeouts and degrade performance for connected clients. This example assumes the Remote Access Service is using all the bandwidth. If it is sharing the bandwidth, fewer connections can be made.

Problem: While transferring files, you frequently get the error messages “Network drive disconnected” or “Network drive no longer exists.”

Solution: On X. 25 smart cards, change the Negotiate network parameters option in the X. 25 settings to Yes. This problem arises when X.25 parameters, such as the size of the send and receive window, are set differently for the server, the network, and the client X.25 software.

By enabling the Negotiate network parameters option on the client's (if using the direct X. 25 connection) and the server's X.25 software, you let the server, the network, and the client use commonly negotiated X.25 network parameters.

Topic 4 is not included here. This topic is better explained with this article.

Problem: A modem connected to a dial-up PAD connects a lower speed than it should.

Solution: Replace the modem with a compatible one from the list in the Setup program.

The following section is from the Windows NT 3.51 and 4.0 RasRead.txt file:

Troubleshooting Remote Disconnections

When a client connection is cleared, the system event log of the RAS server running X.25 can be examined for an error message. The event log can record why the remote client or the remote network disconnected.

If the remote client (through a dial-up PAD or local PAD) disconnects, the following warning message will appear in the system event log:

Remote DTE cleared the X.25 call on XPADxxx, X.25 Return Codes: Cause yy (hex) Diagnostic yy (hex)

The “XPADxxx” is the port name defined in the XPAD configuration. “yy” is a hex string. For DTE clearing the cause will always be 00. The Diagnostic code can be 00--indicating that the remote client requested a disconnect--or another non-zero value. When the diagnostic code is non-zero it indicates a clearing due to the remote client's dial-up PAD service. Contact the remote client's X.25 service provider to determine the problem.

If the X.25 network disconnects, the following warning message will appear in the system event log:

Network cleared the X.25 call on XPADxxx, X.25 Return Codes: Cause yy (hex) Diagnostic yy (hex)

The “XPADxxx” is the port name defined in the XPAD configuration. “yy” is a hex string. For a network clearing the cause value will always be a non-zero value. The diagnostic code in the cause can be any value. Consult your local X.25 service provider with the cause and diagnostic value to determine the exact reason for the network disconnect.

Appendix A: Windows NT 4.0 Networking Supplement Manual RAS X.25 Chapter

chapter 9 - X.25 PAD support

An X.25 network uses a packet-switching protocol to transmit data. This protocol relies on an elaborate worldwide network of packet-forwarding nodes (Data Communications Equipment [DCEs]) that participate in delivering an X.25 packet to its designated address.

Dial-up Asynchronous Packet Assemblers/Disassemblers (PADs) constitute a practical choice for Remote Access clients because they don’t require an X.25 line to be plugged into the back of the computer. Their only requirement is the telephone number of the PAD service for the carrier.

Note

This Chapter is specific to X.25 PADs. X.25 cards can also be supported through WAN miniport drivers.

The Remote Access Service lets you access the X.25 network in two general ways:

Server/Client | Method of access
Client (for the Windows or Windows NT operating systems) | Asynchronous Packet Assemblers/Disassemblers (PADs)
Server and client (for Windows NT systems only) | Direct connections

The next section tells how to access the X.25 network in both ways for specific configurations.

X.25 Configurations

The Remote Access Service for X.25 networks offers two configurations for the client and one for the server:

Table 9.1 X.25 Configurations

Client/Server | Configuration
Client | Dial-up PAD
Client | Direct connection to the X.25 network through X.25 smart card
Server | Direct connection to the X.25 network through X.25 smart card

Pad.inf Format

Similar in format to Modem.inf (which contains script information used to talk to the modem), Pad.inf contains conversations between the client software and the PAD. For details, see Appendix C, “Understanding Modem.inf.” Pad.inf is located in the \systemroot\SYSTEM32\RAS folder.

The macros in the following list are reserved words, which you cannot define in Pad.inf to create a new entry. Reserved words are case insensitive.

x25address

diagnostics

userdata

facilities

Caution

Using reserved words as macro names in Pad.inf could result in unpredictable behavior of the Remote Access software.

Sample Pad.inf

The following sample Pad.inf file will help you create a section within Pad.inf for your X.25 network. This example shows an entry for Sprintnet:

[SPRINTNET] ;The following three lines are temporary. DEFAULTOFF= MAXCARRIERBPS=9600 MAXCONNECTBPS=9600 ; The next line will give a delay of 2 secs - ; allowing the PAD to initialize COMMAND= NoResponse COMMAND= NoResponse ; The @ character sets the SPRINTNET PAD for 8 databit communication. COMMAND=@ NoResponse COMMAND= NoResponse ; The D character requests a 9600 speed. COMMAND=D<cr> ; We don't care for the response so we ignore it. OK=<ignore> ; A carriage return line feed again to initialize ; the PAD read/write buffers COMMAND=<cr><lf> OK=<ignore> COMMAND=<cr><lf> OK=<ignore> ; Set X.3 settings on the PAD which make it work well with RAS. ; Broken into two parts since the line is too long. COMMAND=SET 1:0,2:0,3:0,4:1,5:0,6:1,7:0,8:0,9:0,10:0,11:0<cr> OK=<ignore> ; Set the other half of X.3 parameters COMMAND=SET 12:0,13:0,14:0,15:0,16:0,17:0,18:0,19:0,20:0,21:0,22:0<cr> OK=<ignore> ; Finally try to call RAS X25 server COMMAND=C <x25address><cr><lf> CONNECT=<match>“CONNECT” ERROR_DIAGNOSTICS=<cr><lf><Diagnostics> ; CONNECT response means that the connection completed fine. ; X25ERROR response means connection attempt failed - the X25 CAUSE and ; DIAGNOSTIC information will be extracted from the response and ; sent to the user. ; ERROR responses are for generic failures.

After this sample conversation for SPRINTNET is completed (with the correct responses), the X.25 connection is established. If errors are detected during the PAD conversation, no connection is made.

Note

The Remote Access Service currently works with PADs set to 8 data bits, 1 stop bit, and no parity. Consult the documentation for the PAD to see how to install these settings.

In Pad.inf, you can use the COMMAND_ series of commands (COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN) or the generic COMMAND. But do not mix the two families of commands. For more information on the COMMAND_ series, see Appendix C, “Understanding Modem.inf.”

Troubleshooting

For troubleshooting information, see the Remote Access online Help.

Accessing X.25 Through Dial-Up PADs

Operating between the client and the Remote Access server, an asynchronous PAD converts serially-transmitted data into X.25 packets. When the PAD receives a packet from an X.25 network, it puts the packet out on a serial line, making communication possible between the client and the X.25 network.

Remote Access clients can connect with Remote Access servers through dial-up PAD services supplied by X.25 carriers, such as Sprintnet and Infonet. After the client’s modem (modem A in Figure 9.1) connects to the PAD’s modem (modem B), the client software must converse with the dial-up PAD. When their conversation is successfully completed, a connection is established between client and server. The conversation (command/response scripts) for the PADs supported by an X.25 carrier is stored in the Pad.inf file. Remote Access software supplies one example. To customize your PAD, see “Pad.inf Format,” in this chapter.

For example, Pad.inf contains two Sprintnet entries: Sprintnet Standard and Sprintnet Alternate. Generally, if you are calling through 9600 bits-per-second (bps) or faster dial-up PADs, try Sprintnet Standard. If you are calling through 2400 bps or slower dial-up PADs, try Sprintnet Alternate.

If one Sprintnet entry fails to connect reliably, try the other one. Sprintnet dial-up PADs should work with both.

Note

For dial-up PADs, you must use the COMMAND= format, not the COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN format.

Figure 1.1 shows how a client connects to the Remote Access server through a dial-up PAD and the X.25 network.

Figure 1.1 Connecting to the Server Through a Dial-Up PAD

Note

For best results when using a dial-up PAD, use a modem that matches the one used by the PAD carrier (or at least matches the V. protocol supported by the carrier’s modem).

The following table compares connecting through dial-up PADs and connecting directly to the X.25 network:

Table 1.2 Comparison of Dial-Up PADs to Connecting Directly

Dial-Up PAD | Direct connection
Saves the expense of a dedicated leased line (direct connection). | Requires expensive leased line.
Allows connections from hotels, airports, homes—anywhere a phone line is available. | Requires users to dial in from a fixed location.
Requires two steps to connect. | Connects conveniently in one step.
Limits maximum communication speed to whichever speed is slower, the modem’s or the PAD’s. | Lets communication take place up to the speed of a leased line, 56 kilobytes (K).
Allows less control in configuring PADs. | Offers greater reliability.
Only a client can connect through a dial-up PAD. | Both servers and clients can connect directly.

PAD and Serial Configuration

To configure your PAD correctly, set the X.3 parameters according to the information shown in Table 9.3 later in this chapter.

The configuration of the dial-up PAD should be as follows:

8 data bits

1 stop bit

No parity serial communication

For dial-up PADs, make sure your vendor supports this configuration. The PADs might already be set to the correct configuration for connecting directly through an internal X.25 smart card. If they are, do not change the configuration.

Connecting to the X.25 Network Directly

RAS also supports connecting directly from the remote computer to the X.25 network through a smart card, which acts like a modem. An X.25 smart card is a hardware card with a PAD embedded in it. To the personal computer, a smart card looks like several communication ports attached to PADs. To access the X.25 network through a direct connection, you must have

a direct line connection to an X.25 network (clients only)

a smart card

Note

The server side always requires an X.25 smart card, but the client side requires one only when connecting to the X.25 network directly.

Note

For connecting to the network directly, you must use the COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN format.

Figure 1.2 shows how the server and a Windows NT client (both equipped with smart cards) connect to the X.25 network directly.

Figure 1.2 Connecting to X.25 Directly

Callback

The Remote Access server does not support callback on X.25 networks.

Setting Up the Remote Access Server for an X.25 Network

After installing Windows NT Server and adding the Remote Access Service, follow these steps:

To set up the Remote Access server for an X.25 network

1.Install the X.25 smart card (according to the manufacturer’s instructions).

A communications driver for the X.25 smart card that emulates communication ports is supplied by the hardware manufacturer or by a third party.

2.Make sure your X.25 smart card is configured with the X.3-parameter values shown in Table 9.3.

3.From the list of devices on the Remote Access Setup dialog box, select an entry corresponding to the X.25 smart card.

4.In setting up the Remote Access server, make sure that the ports selected are configured for dial-in.

Note

Make sure that the speed of the leased line can support all the serial communication (COM) ports at all speeds at which clients will dial in. For example, 4 clients connecting at 9600 bps (through dial-up PADs) will require a 38,400-bps (4 times 9600) leased line on the server end. If the leased line does not have adequate bandwidth, it can cause time-outs and can cause the performance for connected clients to degrade.

Table 1.3 X.25 Configuration Values

Parameter number | X.3 parameter | Value
1 | PAD Recall | 0
2 | Echo | 0
3 | Data Fwd. Char | 0
4 | Idle Timer | 1
5 | Device Ctrl | 0
6 | PAD Service Signals | 1
7 | Break Signal | 0
8 | Discard Output | 0
9 | Padding after CR | 0
10 | Line Folding | 0
11 | Not Set |
12 | Flow Control | 0
13 | Linefeed Insertion | 0
14 | Padding after LF | 0
15 | Editing | 0
16 | Character Delete | 0
17 | Line Delete | 0
18 | Line Display | 0
19 | Editing PAD Srv Signals | 0
20 | Echo Mask | 0
21 | Parity Treatment | 0
22 | Page Wait | 0

Caution

Failure to set these values as shown prevents the Remote Access Service from functioning properly. For information on setting these values, see the instructions with your X.25 smart card.

Setting Up Remote Access Clients

This section tells how to set up Remote Access clients for connecting to the X.25 network through PAD services and for connecting to the X.25 network directly.

Connecting Through Dial-Up PADs

Following these steps to connect a client to an X.25 network:

1.Dial from the client’s modem to a PAD (modem-to-modem).

2.Establish a connection over the X.25 network between the PAD and the server-side X.25 smart card.

After you’ve established a connection, communicate as you would through any asynchronous connection. For a complete description of connecting through dial-up PADs, see “Accessing X.25 Through Dial-Up PADs,” earlier in this chapter.

Configuring Client PADs

The client PAD, through which a remote computer connects to the X.25 network, might have previously been set to X.3-parameter values that are incompatible with the Remote Access Service. Therefore, it is important to configure the X.25 smart card on the Remote Access server so that it changes the client PAD’s X.3 settings to the values in Table 9.3 as soon as a connection is established through X.29 commands. To configure an X.25 smart card to make these changes, see the configuration manual for your specific card.

Note

If the X.25 smart card on the server end does not support commands for the X.29 language, the client PAD script must set the X.3 parameters locally. If you have problems, contact the support site for your X.25 smart card vendor.

Connecting Directly

To set up the client for connecting directly to the X.25 network, follow the procedures used in setting up the Remote Access server. See “Setting Up the Remote Access Server for an X.25 Network,” earlier in this chapter. Make sure the communication ports are selected as dial-out.

Configuring Remote Access Software for X.25

Connecting to a server through an X.25 network is similar to connecting through a phone line. The only difference is that the phone book entry must specify an X.25 PAD type and an X.121 address.

To add a phone book entry with X.25 or to add X.25 to an existing entry

See RAS online Help. This online Help also provides troubleshooting information.

Appendix B: General X.3 Parameter Description

This is a general listing of X.3 Packet Assembler/Disassembler (PAD) parameters. There are 22 standard PAD parameters since 1984. Parameters 16, 17, 18, and 19 describe editing functions that are not used with RAS.

For more information on how to set these parameters with RAS, see the paragraph titled “X.3 RAS Specifications and Potential Problems” above.

Parameter 1: PAD recall

Description: This enables an escape from the PAD on-line state (data transfer mode) to the PAD command state on receipt of a specific character. When the PAD receives this character, the PAD prompt is displayed on your terminal monitor.

Parameter 2: Echo

Description: This parameter is set to “0” (zero) for echo and “1” fornon-echo. One of the most frequently used parameters, this is handy for applications used for suppression of text when you are typing in your name and password. When this parameter is set, all characters received from the terminal are echoed, excluding those specified by parameters 5,12,20,22. Setting parameters 12 or 22 to non-zero values suppresses character echo (XON and OFF) even if parameter 2 is set to echo on.

Parameter 3: Data Forwarding Signal (characters)

Description: This value is bit-mapped. The PAD does not usually transmit one character at a time; it prefers large blocks of data, such as lines of text. A normal character used for this parameter is [carriage return = 2]. A PAD manufacturer's manual should have a table showing the options for this parameter.

Parameter 4: Idle Time Delay

Description: With the Data Forwarding, this parameter provides the capability to forward data to a host based on idle time. If there is data in the buffer and there has been no additional characters received in the IDLE TIME, the buffer is sent to the host. The time units are in 0.05 seconds and the values range from 1 - 255. The implementation of the time unit sizes can vary from vendor to vendor.

Parameter 5: Flow Control - PAD to Terminal

Description: This parameter tells the PAD to transmit the XON/OFF characters to the DTE, depending on the buffer state.

Parameter 6: PAD Result Code Control

Description: This controls how the PAD result codes are transmitted to the terminal. The parameter can stop the PAD from sending service codes back to the terminal in response to events as the X.25 calls for clear or reset.

Parameter 7: Action on Receipt of Break from Character Terminal

Description: This parameter is bit-mapped. The break action here is a sequence (from the host that the PAD is connected to) for indicating that attention is required. This can be used in the interruption of a long transmission that the host may think is hung in a loop or stuck in constant transmit mode.

Parameter 8: Discard Output

Description: Set this parameter so that you can abort a running process on the remote system by pressing a [break] key. If set to zero [0], normal data delivery is used.

Parameter 9: Padding after Carriage Return

Description: Specifies the number of {NUL} characters to transmit after a carriage return.

Parameter 10: Line Folding

Description: This allows for the formatting of data into regular line lengths when delivered to the character terminal. If a line length is specified, a [carriage return / line feed] must be transmitted.

Parameter 11: Terminal Speed

Description: This is a READ ONLY value. The parameter shows the current DTE speed. It is automatically set by the PAD using the last AT command.

Value | Baud Rate
0 | 110
2 | 300
3 | 1200
4 | 600
5 | 75
12 | 2400
13 | 4800
14 | 7200 or 9600
15 | 14400 or 19200
16 | 38400

Parameter 12: Flow Control of the PAD by Local Terminal

Description: This is basically the opposite of parameter 5: it allows the character terminal to control the flow control.

Parameter 13: Line Feed Insertion after Carriage Return

Description: This specifies whether the PAD inserts a line feed character after carriage returns. This applies only in the PAD on-line state.

Parameter 14: Padding after Line Feed

Description: This is the same as parameter 9 except that the padding {NUL} characters instead of a carriage return are inserted after a line feed.

Parameter 15: Editing

Description: This specifies whether editing is used in the PAD on-line state.

Parameter 16: Character Delete

Note

Parameters 16, 17, 18, and 19 help describe the available editing functions. If editing is enabled, parameter 4 (Idle Time Delay) is ignored.

Description: This defines the delete character to delete the last character in the editing buffer. ASCII 8 is the backspace character.

Parameter 17: Line (buffer) Delete

Description: This defines the line delete character. ASCII 24 is <Ctrl-X>.

Parameter 18: Line Display

Description: This defines the line display. If you enter the character specified and editing is enabled, the editing buffer is displayed. ASCII 18 is <Ctrl-R>.

Parameter 19: Editing PAD Result Codes

Description: This defines the effect of editing buffered characters with the character delete and line delete functions.

Parameter 20: Echo Mask

Description: Bit-Masked Parameter. If parameter 2 is set to 1, this parameter lets you select the characters that are echoed.

Parameter 21: Parity Treatment

Description: This controls the parity and character format used by the terminal. Best left in the “OFF” condition.

Parameter 22: Page Wait

Description: This allows for pagination of data sent to the terminal. If the terminal display can display 20 lines and this parameter is set to 20, the PAD sends 20 lines of data then stops transmission.

Appendix C: Using Pad.inf with Non-X.25 RAS Connections

In Windows for Workgroups 3.11 and Windows NT 3.1 and 3.50 Pad.inf has the advantage over Switch.inf that it supports three macros (variables): X.121 Address, User Data, and Facilities that are getting their values from the X.25 user interface. This makes Pad.inf more user-friendly and secure because the password does not need to be entered permanently in the Pad.inf script like it would have to in the Switch.inf file.

For example, calling a RAS server with an intermediary security device switched in-line where the security device requires a user ID and password in addition to the Windows NT RAS credentials becomes more secure and user-friendly by using the Pad.inf file rather than Switch.inf. In those cases where the password for the intermediary security device is changing every few seconds or minutes, the use of the variables in Pad.inf file is virtually the only feasible solution because quickly editing the Switch.inf file to enter the password, saving the changes and then starting RAS and making the call may take so much time that the password has changed again in the meantime.

However, in Windows NT 3.51 and 4.0, Switch.inf supports two variables: Username and Password which are conveniently obtained through the familiar Windows NT logon dialog box. The Username and Password variables are not available in Windows for Workgroups 3.11, Windows NT 3.1 and 3.5 RAS. For more information, see your RAS manual and online help for X.25 topics.

Note

Pad.inf was designed for X.25 connectivity. Although using Pad.inf with non-X.25 networks may work, it has not been tested by, and is not supported by Microsoft.

Appendix D: List of Electronic and Hardcopy RAS documentation in the Different RAS Versions

The following list shows all RAS versions to-date - regardless of X.25 support - and whether they ship with a hard copy of the manual or only a softcopy manual or only online help. All RAS versions ship with online help, however, the early RAS versions do not contain nearly as much information in the online help as the later versions.

The following RAS version ship with a hard copy of the manual:

Remote Access for MS-DOS, versions 1.0, 1.1, 1.1a

Remote Access for OS/2, version 1.0, 1.1

Windows NT operating system version 3.1

Windows NT Advanced Server version 3.1

Windows NT Workstation versions 3.5, and 3.51

Windows NT Server versions 3.5, and 3.51

The following RAS versions only have online help:

RAS for Windows for Workgroups only has online help documentation.

RAS for Windows 95

The following RAS versions ship online help and with a printable, electronic version of the manual on the compact disc. A hard copy of the manual can be purchased for a small fee:

Microsoft Windows NT Workstation version 4.0

Microsoft Windows NT Server version 4.0

Note

The RAS server and RAS client online help may contain information on different topics.

Appendix E: Other RAS sources

The Windows NT 3.51 Resource Kit Update 2 manual has a comprehensive RAS Reference that discusses all RAS versions up to Windows NT 3.51 and Windows 95.

The RAS Troubleshooter on the Microsoft web at: http://www.microsoft.com

Microsoft TechNet (Knowledge Base and White Papers)

The Microsoft Knowledge Base on the web and on Microsoft TechNet: http://www.microsoft.com/technet

For More Information

For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/ntserver or the Windows NT Server Forum on MSN™ The Microsoft Network (GO WORD: MSNTS).

Appendix F: The New Script Language for Windows 95 and Windows NT 4.0

This script language is not supported for use in the Windows NT Pad.inf file! Use it with RAS for PPP and SLIP dial-up networking, for example, to access the Internet via an Internet access provider. Using the script language in a *.scp script file for X.25 dial-up has not been tested by Microsoft and is therefore not supported, however, it may work. Also Windows 95 has not been tested with X.25 dial-up and this script language, however, it may work, too.

Dial-Up Scripting Command Language / For Dial-Up Networking Scripting Support

1.0 Overview

Many Internet service providers and online services require you to manually enter information, such as your user name and password, to establish a connection. With Scripting support for Dial-Up Networking, you can write a script to automate this process.

A script is a text file that contains a series of commands, parameters, and expressions required by your Internet service provider or online service to establish the connection and use the service. You can use any text editor, such as Microsoft Notepad, to create a script file. Once you've created your script file, you can then assign it to a specific Dial-Up Networking connection by running the Dial-Up Scripting Tool.

2.0 Basic Structure of a Script

A command is the basic instruction that a script file contains. Some commands require parameters that further define what the command should do. An expression is a combination of operators and arguments that create a result. Expressions can be used as values in any command. Examples of expressions include arithmetic, relational comparisons, and string concatenations.

The basic form of a script for Dial-Up Networking follows:

; ; A comment begins with a semi-colon and extends to ; the end of the line. ; proc main ; A script can have any number of variables ; and commands variable declarations command block endproc

A script must have a main procedure, specified by the proc keyword, and a matching endproc keyword, indicating the end of the procedure.

You must declare variables before you add commands. The first command in the main procedure is executed, and then any subsequent commands are executed in the order they appear in the script. The script ends when the end of the main procedure is reached.

3.0 Variables

Scripts may contain variables. Variable names must begin with a letter or an underscore ('_'), and may contain any sequence of upper- or lower-case letters, digits, and underscores. You cannot use a reserved word as a variable name. For more information, see the list of reserved words at the end of this document.

You must declare variables before you use them. When you declare a variable, you must also define its type. A variable of a certain type may only contain values of that same type. The following three types of variables are supported:

Type | Description
integer | A negative or positive number, such as 7, -12, or 5698.
String | A series of characters enclosed in double-quotes; for example, “Hello world!” or “Enter password:”.
Boolean | A logical boolean value of TRUE or FALSE.

Variables are assigned values using the following assignment statement:

variable = expression

The variable gets the evaluated expression.

Examples:

integer count = 5 integer timeout = (4 * 3) integer i boolean bDone = FALSE string szIP = (getip 2) set ipaddr szIP

3.1 System Variables

System variables are set by scripting commands or are determined by the information your enter when you set up a Dial-Up Networking connection. System variables are read-only, which means they cannot be changed within the script. The system variables are:

Name | Type | Description
$USERID | String | The user identification for the current connection. This variable is the value of the user name specified in the Dial-Up Networking Connect To dialog box.
$PASSWORD | String | The password for the current connection. This variable is the value of the user name specified in the Dial-Up Networking Connect To dialog box.
$SUCCESS | Boolean | This variable is set by certain commands to indicate whether or not the command succeeded. A script can make decisions based upon the value of this variable.
$FAILURE | Boolean | This variable is set by certain commands to indicate whether or not the command failed. A script can make decisions based upon the value of this variable.

These variables may be used wherever an expression of a similar type is used. For example,

transmit $USERID

is a valid command because $USERID is a variable of type string.

4.0 String Literals

Scripting for Dial-Up Networking supports escape sequences and caret translations, as described below.

String Literal | Description
^char | Caret translation
<cr> | Carriage return
<lf> | Linefeed
\” | Double-quote
\^ | Single caret
\< | Single '<'
\\ | Backslash

If char is a value between '@' and '_', the character sequence is translated into a single-byte value between 0 and 31. For example, ^M is converted to a carriage return.

If char is a value between a and z, the character sequence is translated into a single-byte value between 1 and 26.

If char is any other value, the character sequence is not specially treated.

Examples:

transmit “^M” transmit “Joe^M” transmit “<cr><lf>“ waitfor “<cr><lf>“

5.0 Expressions

An expression is a combination of operators and arguments that evaluates to a result. Expressions can be used as values in any command.

An expression can combine any variable, or integer, string, or boolean values with any of the unary and binary operators in the following tables. All unary operators take the highest precedence. The precedence of binary operators is indicated by their position in the table.

The unary operators are:

Operator | Type of Operation
- | Unary minus
! | One's complement

The binary operators are listed in the following table in their order of precedence. Operators with higher precedence are listed first:

Operators | Type of Operation | Type Restrictions
* / | Multiplicative | Integers
+ - | Additive | integers Strings (+ only)
< > <= >= | Relational | Integers
== != | Equality | Integers, strings, booleans
and | Logical AND | Booleans
or | Logical OR | Booleans

Examples:

count = 3 + 5 * 40 transmit “Hello” + “ there” delay 24 / (7 - 1)

6.0 Comments

All text on a line following a semicolon is ignored.

Examples:

; this is a comment transmit “hello”; transmit the string “hello”

7.0 Keywords

Keywords specify the structure of the script. Unlike commands, they do not perform an action. The keywords are listed below.

proc name

Indicates the beginning of a procedure. All scripts must have a main procedure (proc main). Script execution starts at the main procedure and terminates at the end of the main procedure.

endproc

Indicates the end of a procedure. When the script is executed to the endproc statement for the main procedure, Dial-Up Networking will start PPP or SLIP.

integer name [ = value ]

Declares a variable of type integer. You can use any numerical expression or variable to initialize the variable.

string name [ = value ]

Declares a variable of type string. You can use any string literal or variable to initialize the variable.

boolean name [ = value ]

Declares a variable of type boolean. You can use any boolean expression or variable to initialize the variable.

8.0 Commands

All commands are reserved words, which means you cannot declare variables that have the same names as the commands. The commands are listed below:

delay nSeconds

Pauses for the number of seconds specified by nSeconds before executing the next command in the script.

Examples:

delay 2; pauses for 2 seconds delay x * 3; pauses for x * 3 seconds

getip value

Waits for an IP address to be received from the remote computer. If your Internet service provider returns several IP addresses in a string, use the value parameter to specify which IP address the script should use.

Examples:

; get the second IP address set ipaddr getip 2 ; assign the first received IP address to a variable szAddress = getip

goto label

Jumps to the location in the script specified by label and continues executing the commands following it.

Example:

waitfor “Prompt>“ until 10 if !$SUCCESS then goto BailOut; jumps to BailOut and executes commands ; following it endif transmit “bbs^M” goto End BailOut: transmit “^M”

halt

Stops the script. This command does not remove the terminal dialog window. You must click Continue to establish the connection. You cannot restart the script.

if condition then

commands

endif

Executes the series of commands if condition is TRUE.

Example:

if $USERID == “John” then transmit “Johnny^M” endif

label :

Specifies the place in the script to jump to. A label must be a unique name and follow the naming conventions of variables.

set port databits 5 | 6 | 7 | 8

Changes the number of bits in the bytes that are transmitted and received during the session. The number of bits can be between 5 and 8. If you do not include this command, Dial-Up Networking will use the properties settings specified for the connection.

Example:

set port databits 7

set port parity none | odd | even | mark | space

Changes the parity scheme for the port during the session. If you do not include this command, Dial-Up Networking will use the properties settings specified for the connection.

Example:

set port parity even

set port stopbits 1 | 2

Changes the number of stop bits for the port during the session. This number can be either 1 or 2. If you do not include this command, Dial-Up Networking uses the properties settings specified for the connection.

Example:

set port stopbits 2

set screen keyboard on | off

Enables or disables keyboard input in the scripting terminal window.

Example:

set screen keyboard on

set ipaddr string

Specifies the IP address of the workstation for the session. String must be in the form of an IP address.

Examples:

szIPAddress = “11.543.23.13” set ipaddr szIPAddress set ipaddr “11.543.23.13” set ipaddr getip

transmit string [ , raw ]

Sends the characters specified by string to the remote computer.

The remote computer will recognize escape sequences and caret translations, unless you include the raw parameter with the command. The raw parameter is useful when transmitting $USERID and $PASSWORD system variables when the user name or password contains character sequences that, without the raw parameter, would be interpreted as caret or escape sequences.

Examples:

transmit “slip” + “^M” transmit $USERID, raw

waitfor string [ , matchcase ] [ then label

{ , string [ , matchcase ] then label } ]

[ until time ]

Waits until your computer receives one or more of the specified strings from the remote computer. The string parameter is case-insensitive, unless you include the matchcase parameter.

If a matching string is received and the then label parameter is used, this command will jump to the place in the script file designated by label.

The optional until time parameter defines the maximum number of seconds that your computer will wait to receive the string before it execute the next command. Without this parameter, your computer will wait forever.

If your computer receives one of the specified strings, the system variable $SUCCESS is set to TRUE. Otherwise, it is set to FALSE if the number of seconds specified by time elapses before the string is received.

Examples:

waitfor “Login:” waitfor “Password?”, matchcase waitfor “prompt>“ until 10 waitfor “Login:”then DoLogin, “Password:”then DoPassword, “BBS:”then DoBBS, “Other:”then DoOther until 10

while condition do

commands

endwhile

Executes the series of commands until condition is FALSE.

Example:

integer count = 0 while count < 4 do transmit “^M” waitfor “Login:” until 10 if $SUCCESS then goto DoLogin endif count = count + 1 endwhile

...

9.0 Reserved Words

The following words are reserved and may not be used as variable names.

And | boolean | databits | delay
do | endif | endproc | endwhile
even | FALSE | getip | goto
halt | if | integer | ipaddr
keyboard | mark | matchcase | none
odd | off | on | or
parity | port | proc | raw
screen | set | space | stopbits
string | then | transmit | TRUE
until | waitfor | while |

Appendix G: Troubleshooting RAS 1.0 and 1.1 on a MS OS/2 1.3 Server Running MS LAN Manager

The following are two Microsoft Knowledge Base troubleshooting articles that focus on RAS 1.0 and 1.1 installed on computers running Microsoft OS/2 1.3 and LAN Manager 2.1 or later.

Part 1 (of 2)--Troubleshooting RAS on an OS/2 1.x Server [lanman]

ID: Q98518 CREATED: 06-MAY-1993 MODIFIED: 26-JAN-1995

2.10 2.10a 2.20

MS-DOS PUBLIC | kbnetwork

The information in this article applies to:

Microsoft LAN Manager versions 2.1, 2.1a, and 2.2
Microsoft Remote Access Service versions 1.0 and 1.1

SUMMARY

This is part 1 of a two-part article meant to supplement (not replace) information provided in the “Remote Access Administrator's Guide,”Chapter 4, “System Requirements.” It will help you troubleshoot problems by verifying that basic requirements are met.

To ensure proper operation of RAS 1.0 or 1.1 on an OS/2 1.21 or 1.3 server (OS/2 2.0 is currently not supported), verify that the following elements are present — preferably BEFORE you run the RAS Setup program:

1.Serial Ports/Device Drivers

One or more serial ports.

One or more OS/2 serial port device drivers.

Part 1 (the rest of this article) provides information on item 1: serial drivers and boards for ISA, EISA, MCA, Hewlett-Packard (HP) and 3Com computers, Digiboards, AST 4 port boards, and X.25 configurations. Part 2 of this article provides information on items 2-6 below:

2. Modems

One or more modems.

All supported modems are listed in the RAS 1.1 MODEMS.INF file.

Unsupported modems may also work.

3.Serial Cable

External modems require properly wired serial cables.

4.LAN Manager

LAN Manager 2.1 or later with one protocol/network in addition to AsyBEUI. LAN Manager 2.1 or later must be installed with at least one network (for example, a loopback driver, or NetBEUI plus a MAC driver) in addition to the RAS AsyBEUI. This is because RAS 1.0 and 1.1 function as a gateway and expect another network to be present.

5.User-Level Security

RAS MUST have user-level security--it does not support share-level security.

6.PDC, BDC, Member Server or Standalone Status

A RAS server can be configured as a primary or backup domain controller, a member-server, or a standalone.

Note

For details on topics other than SERIAL PORTS/DEVICE DRIVERS, refer to part 2 of this article, or query on the following words in the Microsoft Knowledge Base:

MORE INFORMATION

1. Serial Ports and OS/2 Serial Port Device Drivers

Under OS/2 1.3, serial ports cannot be accessed without serial device drivers. Each serial driver/COM-port combination has its own hardware requirements and limitations, so they are discussed separately below.

At least one serial port must be available and properly configured, but remember that COM ports have specific and sometimes unique OS/2 serial device driver requirements. Third party serial boards or proprietary built-in ports usually require their own device drivers.

For example: Digiboards require XALL.SYS.

You must install an OS/2 serial port device driver through the CONFIG.SYS file. Depending on the serial port hardware, you may also have to install proprietary device drivers.

Serial Port/Driver Combinations

1.1ISA and EISA (but not certain HP machines and 3COM 3Servers) machines

use COM01.SYS. COM01.SYS must be loaded in the CONFIG.SYS file. It supports ONLY serial ports COM1 and COM2 on ISA and EISA machines, NOT COM3 and COM4.

SERIAL 1 COM1: I/O Address = 3F8h IRQ = 4

SERIAL 2 COM2: I/O Address = 2F8h IRQ = 3

Note

RAS requires that the serial port in use be configured as above. COM01.SYS does not perform a DosOpen call to the serial port until the serial port is actually used, so COM01.SYS loads during CONFIG.SYS time even if the port is misconfigured or there is an IRQ or I/O conflict between one of the COM ports and another device. For example: if a network card is configured for IRQ3, COM01.SYS loads but a system error “SYS 1620” occurs when a MODE COM2: command is issued.

Hewlett-Packard EISA machines: use COMHP01.SYS.

Note

Find out your HP model number--this may NOT apply to all models.

1.2COMHP01.SYS

supports COM1-COM4 with COM1 and COM2 configured as above, but you need to set up COM3 and COM4 with the following I/O addresses and IRQ settings:

SERIAL 3 COM3 I/O Address = 3E8h, IRQ = 10

SERIAL 4 COM4 I/O Address = 2E8h, IRQ = 11

These are discussed (as is COMHP01.SYS) in the README.TXT file in C:\OS2\SUPPORT.

1.3MCA machines

use COM02.SYS (COM01.SYS CANNOT be used): COM02.SYS must be used on Micro Channel machines and loaded in the CONFIG.SYS file. COM02.SYS supports serial ports COM1, COM2, and COM3. IRQ3 is shared by COM2 and COM3.

COM1: I/O Address = 3F8h IRQ = 4

COM2: I/O Address = 2F8h IRQ = 3

COM3: I/O Address = 2F8h, IRQ = 3

On Micro Channel machines, COM2-8 are shared at IRQ3, and I/O ports 2F8, 3220 (hex), 3228, 4220, 4228, 5220, and 5228. In OS/2 1.3, however, COM02.SYS can support only COM1-COM3.

Some add-in serial boards are supported so that you can get ports COM2 and/or COM3 on, for example, an IBM PS/2 Model 80. One supported add-in board is the IBM DUAL ASYNC adapter, which has two 9-pin serial ports built into it.

1.4Computers with Digiboards (Micro Channel, ISA, or EISA)

use XALL.SYS. For older products, use DGX.SYS.

The information in the rest of this section was verified in April 1993:

The OS/2 XALL.SYS device driver supports the entire line of Digichannel intelligent asynchronous serial communication controllers and must be loaded in the OS/2 Config.sys file. You can adjust its functionality with device line parameters.

The OS/2 DGX.SYS device driver supports older non-intelligent serial Digiboards such as the PC4 board, and is also configured with the help of device line parameters.

Note

Digiboard does NOT ship the XALL.SYS OS/2 driver with their hardware. You must order it by calling (612) 943-9020 or obtain itfrom their BBS at (612) 943-0812.

(Communication settings: N,8,1; baud 300, 1200, 2400, 9600; V.32, V.42 and V.42bis standards are supported.)

Note

On EISA bus machines with EISA Digiboards you must verify that the XALL.SYS parameter: /p:xxxx has a 4-digit I/O address, the first digit of which is the EISA Digiboard card's bus slot number. This first digit is often forgotten, which prevents the driver from loading properly.

1.5AST 4-port serial board: use COM01A.SYS

This board is NOT supported by Microsoft, but no problems have been reported with it and we provide this information as a convenience. The driver is available on the Microsoft BBS at (425) 936-MSDL in the LAN Manager area. Load it just as you would COM01.SYS. Microsoft has not tested this driver with OS/2 1.3 and therefore does NOT guarantee proper performance.

1.63COM 3Servers

3S400 servers: use COM01S.400

3S500 AND 3S600 servers: use COM01S.500

The CONFIG.SYS file loaded by the LAN Manager installation tape has the appropriate 3COM serial port driver already referenced but still REMarked out so that it does NOT allow the serial port to be used. To make it usable, simply remove the REM on that line, save the file, shutdown and reboot your server.

Note

On 3COM servers, only COM1 and COM3 are available--the COM2 port is reserved for the built-in Localtalk port. A 3Com RAS server can use only COM1 and COM3 unless a third party driver and serial port hardware (such as Digiboard) is installed to make COM ports above COM3 available.

COM01S.400 and COM01S.500 expect the serial ports to be configured as follows (these are the defaults):

COM1: I/O Address = 3F8h, IRQ = 4

COM3: I/O Address = 2F8h, IRQ = 3

Note

The 3Com upgrade toolkits for LAN Manager 2.1 and 2.2 contain a disk for installing RAS on 3servers. For 2.1, insert this disk once you start RemSetup (Remote Setup for 3 Servers--located in the LAN Manager directory on the 3server).

Follow the same procedure for the 3COM upgrade toolkit for LAN Manager 2.2, but when you install RAS, insert the disk labeled “Services for Macintosh Remote Installation for 3Server” — the labels for the RAS and the Macintosh services are mixed up.

Note

The “LAN Manager Installation and Configuration Guide” for 3Servers incorrectly assumes that a REMarked outline in the STARTUP.CMD file exists for the RAS. Please add the following line to the STARTUP.CMD file just below the group of similar lines.

Call c:\lanman\3startms.cmd remoteaccess remoteaccess

Note

If you configure RAS for more ports than are physically present (for example, you request a COM4 on a standard 3s500 system where only COM1 and COM3 exist) then the 3Server might hang when RAS is initialized. To cure such a problem, you must edit the STARTUP.CMD file and REMark out the RAS “Call” line. For information on how to do this, refer to the LAN Manager for 3Com servers documentation explaining the CONSOLE mode of 3Servers.

1.7 X.25 drivers and cards: use the vendor's X.25 card and driver

If your server is running RAS over an X.25 network, then in addition to the X.25 card driver RAS needs a COM01.SYS or other driver in order to function and recognize COM ports present on the server. For example: the X.25 card from Eicon, Inc. emulates a maximum of 13 COM ports (COM4- COM16) if there are three regular serial ports on the server already.

Note

If more than 13 COM ports are configured, the RAS service terminates upon startup with a TRAP D during NET START REMOTEACCESS. The number of COM ports configurable also depends on other programs running simultaneously and competing for the same resources needed by the Eicon driver software, so if software of this type is running, RAS probably has to be configured for fewer ports before it can start successfully. Start out with 9 or 10 ports configured and then work your way up towards 13.

Eicon software version 2 release 2 (v2r2) is out of date as of April 1993. Please upgrade to the latest version: version 3 release 1 (v3r1).

For support with the Eicon driver installation or to upgrade to the latest version, please contact Eicon Customer Support Services at (514) 631-2592 (EST).

For more information on debugging X.25 problems with RAS, refer to the RAS 1.1 Release Notes in the RAS retail package.

For details on RAS requirements other than serial ports and device drivers, please see “Part 2 (of 2)-- Troubleshooting RAS on an OS/2 1.x Server.”

REFERENCES

RAS 1.1 Release Notes

LAN Manager “Installation and Configuration Guide”

“Remote Access Administrator's Guide,” Chapter 4, System Requirements

Additional reference words: sfm 2.10 2.1 2.10a 2.1a 2.20 2.2

KBCategory: kbnetwork

KBSubcategory: rmt

Part 2 (of 2)--Troubleshooting RAS on an OS/2 1.x Server [lanman]

ID: Q98517 CREATED: 06-MAY-1993 MODIFIED: 30-SEP-1994

2.10 2.20

MS-DOS

PUBLIC | kbnetwork

The information in this article applies to:

Microsoft LAN Manager versions 2.1, 2.1a, and 2.2

Microsoft Remote Access Service versions 1.0 and 1.1

Summary:

This is part 2 of a two-part article meant to supplement (not replace) information provided in the Remote Access Administrator's Guide, Chapter 4, “System Requirements.” It will help you troubleshoot problems by verifying that basic requirements are met.

To ensure proper operation of RAS 1.0 or 1.1 on an OS/2 1.21 or 1.3 server (OS/2 2.0 is currently not supported at all) verify that the following elements are present — preferably BEFORE running the RAS Setup program:

1.Serial Ports/Device Drivers

One or more serial ports.

One or more OS/2 serial port device drivers.

Part 1 (a separate article) provides information on item 1: serial drivers and boards for ISA, EISA, MCA, HP and 3Com computers, Digiboards, AST 4 port boards, and X.25 configurations.

Part 2 (the rest of this article) provides information on the next five required items:

2.Modems

One or more modems.

All supported modems are listed in the RAS 1.1 MODEMS.INF file.

Unsupported modems may also work.

3. Serial Cable

External modems require properly wired serial cables.

4. LAN Manager

LAN Manager 2.1 or later with one protocol/network in addition to AsyBEUI. LAN Manager 2.1 or later must be installed with at least one network (for example: a loopback driver, or NetBEUI and a MAC driver) in addition to the RAS AsyBEUI. This is because RAS 1.0 and 1.1 function as gateways and expect another network to be present.

5. User-Level Security

RAS MUST have user-level security--it does not support share-level security.

6. PDC, BDC, Member Server or Standalone Status

A RAS server can be configured as a primary or backup domain controller, a member-server, or a standalone.

Note

For details on Serial Ports/Device Drivers, refer to part 1 of this article, or query on the following words in the Microsoft Knowledge Base:

Part 1 (of 2)--Troubleshooting RAS on an OS/2 1.x Server

MORE INFORMATION

1.Modems

At least one modem must be available. RAS can use internal and external modems. Microsoft supports all modems listed in the RAS 1.1 MODEMS.INF file at a baud rate not to exceed the rate listed with the “MAXBAUD=“ parameter in each modem's section. The MODEMS.INF file is the current listing.

An unsupported modem MAY work if you:

Click a supported modem in RAS Setup that is emulated by the unsupported modem.

– Or –

Create its own MODEMS.INF file section containing the proper commands.

To do this, refer to these sources:

RAS 1.1 README.TXT file section “Using Non-Supported Modems” and “Modem Initialization String.”

“RAS Administrator's Guide” Appendix A, under “Adding a New Modem to MODEMS.INF.”

The modem manufacturer's modem manual (for the correct codes for the “COMMAND=“ line in the MODEMS.INF file).

Note

A Modem does not have to be hooked up to a serial port in order for the “NET START REMOTEACCESS” server service to load. Also the RASADMIN utility starts properly (if everything else is set up correctly) and shows the RAS server as running. However, if you access the COM port status screen through the RASADMIN “Server” menu, by selecting “Communication Ports” and then “Port Status,” you will see these text strings:

During Initialization:

Line condition: “Initializing modem”

Modem condition: “Unknown”

Unknown/No modem:

Line condition: “Line non-operational

Modem condition: “Modem not responding”

“Hardware failure”

“Hardware failure” means that the modem failed for some reason after a “No Errors” condition. Turning the modem off could also cause this condition.

RAS recognized the modem's response:

Line condition: “Waiting for Call”

Modem condition: “No Errors”

2.Serial Cable

External modems require properly wired serial cables. For wiring diagrams, see the RAS 1.0 manual, Appendix A, pages 80, 81, or the RAS 1.1 manual, Appendix A, pages 92 and 93.

Note

Serial mouse adapter cables are usually NOT wired correctly formodem communication purposes and should not be used.

3.LAN MANAGER

LAN Manager 2.1 (or later) with one protocol/network in addition to AsyBEUI.

If the loopback driver is not used, RAS requires that you install a network adapter card that uses a Certified Network Driver Interface Specification (NDIS) driver in addition to NetBEUI (or other protocol).

4.User-Level Security

User-level security is essential, because RAS relies on the User Accounts Subsystem database for keeping track of user names, passwords, and RAS permissions. Even so, users who are logged on to a RAS server can access LAN resources that have share-level security. For more information see the “RAS Administrator's Guide,” Chapter 2, “User-level Security.”

5.RAS Server Configured as PDC, BDC, Member Server, or Standalone:

If the RAS server is supposed to be separate from other domains or simply a non-networked machine, the easiest choice is primary domain controller.” (See LAN Manager 2.1 Administrator's Guide, Chapter 4, page 62: “Changing a Server's Role”).

Note

“Error 67” when starting RASADMIN on a standalone server.

Even if the server is configured as “standalone,” RASADMIN first tries to verify your administrator privilege by finding a primary domain controller with the domain name specified in the “domain = “ line of the LANMAN.INI [workstation] section. Most standalone configurations have no valid domain with that name and RAS issues the message:

Error 67: This network name cannot be found.

If LANMAN.INI specifies a valid domain name where you also have an administrator account with the same password as in your standalone RAS server's user accounts database, RASADMIN starts, but it focuses on the other machine instead of the local standalone server. However, depending on the circumstances, RASADMIN issues other errors such as:

Error 2320: The computer isn't active on this domain

– Or –

Error 5: Insufficient privilege

If you receive these errors, click OK, then type in the dialog box the standalone RAS server's computer name as it appears in the LANMAN.INI [workstation] section (for example: computername=rasserver) preceded by two backslashes:

\\rasserver (then press ENTER)

The RAS server service should now be properly installed.

Note

In LAN Manager 2.1a and later, the hardcoded domain name “standalone” allows users to log on faster if validation by a domain controller is bypassed. RASADMIN of RAS version 1.x is not aware of this feature and still responds with the errors shown above even if “domain = standalone” is specified in LANMAN.INI.

REFERENCES

RAS 1.1 Release Notes

LAN Manager “Installation and Configuration Guide”

LAN Manager 2.1 “Administrator's Guide,” “Changing a Server's Role,” page 62

Remote Access “Administrator's Guide,” Appendix A, “Adding a New Modem to MODEMS.INF”; Chapter 2, “User-level Security”

RAS 1.0 manual, Appendix A, pages 80, 81

RAS 1.1 manual, Appendix A, pages 92, 93

KBCategory: kbnetwork

KBSubcategory:

Additional reference words: 2.10 2.10a 2.20

Legal Disclaimers

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.

The third-party products discussed here are manufactured by vendors independent of Microsoft; we make no warranty, implied or otherwise, regarding these products' performance or reliability.

The third-party contact information included in this article is provided to help you find the technical support you need. This contact information is subject to change without notice. Microsoft in no way guarantees the accuracy of this third-party contact information.

THESE MATERIALS ARE PROVIDED “AS-IS,” FOR INFORMATIONAL PURPOSES ONLY.

NEITHER MICROSOFT NOR ITS SUPPLIERS MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU.

NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL, INCIDENTAL, DIRECT, INDIRECT, SPECIAL, AND LOSS OF PROFITS. BECAUSE SOME STATES/JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT’S AND ITS SUPPLIERS’ ENTIRE LIABILITY IN ANY MANNER ARISING OUT OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE, SHALL NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.


Regini.exe

Windows NT® Resource Kits

Contents

Introduction

Command-line syntax

Creating a Regini script file

Script file syntax

Line formatting

Registry Key names

Key name syntax

Kernel and User key names

ACLs

Value entries

Sample script files

Storing a user name for automatic administrative logon

Adding a value for the current user in the Exchange client subkey

Setting the default user name

Complex sample

Introduction

Regini is a command-line utility that you can use to edit the Windows NT Registry. Regini runs the scripts you write that add and modify Registry subkeys and value entries.

When you want to edit the Registry directly, use a Registry editor.

Caution

Changing the Registry by using a Registry editor can have unforeseen effects that can prevent you from starting your computer. Whenever possible, use programs such as Control Panel or System Policy Editor to configure Windows NT.

You can use Regini for batch implementation of corporate standards, including display, sound, and security settings. When you install new device drivers or hardware, however, use the Setup program provided for that purpose.

Command-line Syntax

To run Regini, at the command prompt, type:

regini ScriptFile [ScriptFile...]

where ScriptFile is the filename (and optionally the full path) of a script file used to modify the Windows NT Registry.

For example:

regini \\myserver\public\myfolder\srv.ini

runs Regini, and directs it to run a script file named Srv.ini from the shared folder \\Myserver\Public\Myfolder.

Creating a Regini Script File

Script File Syntax

In a Regini script file specifying Registry changes, you must locate the subkey containing the value entry to be added or changed on the first line, followed by the intended value of that value entry on the second line, using the following format:

\Registry\Key [ACL]ValueEntryName = DataType Value

where:

Keyis the name of the key or subkey containing the value entry you

wish to add or change

ValueEntryNameis the name of the value entry whose value is to be modified

DataTypeis the data type used by the value entry

Valueis the intended result

ACLis an access control list you can choose to include.

The elements of this syntax are explained in more detail below.

If a line contains an equal sign (=), then Regini interprets that line as specifying the value of a Registry value entry.

If a line does not contain an equal sign (=), Regini interprets that line as specifying the name of a Registry key or subkey.

Note

Make sure the text editor you use to create the script file inserts a carriage return at the end of each line. Missing carriage returns can cause unpredictable results.

For example, a Regini script file named Srv.ini, in the shared directory \\Myserver\Public\Myfolder, contains the following text:

\Registry\Machine\System\CurrentControlSet\Services\Lanmanserver \ParametersDiskSpaceThreshhold = REG_DWORD 0x00000000

The following, typed at the command prompt, adds the DiskSpaceThreshhold value entry to the Registry or changes the value that is already there:

regini \\myserver\public\myfolder\srv.ini

Note

Script files can have any extension. They must be saved in ANSI format, but are converted to Unicode when read from the disk. Currently, there is no way to specify a Unicode text file as the script file.

Line Formatting

The format of the script file is line-based. If you are unable to fit all the information for a Registry subkey name or value entry on one line, use the backslash character (\) as a line-continuation character.

For example:

123456\

1234 \

12

is treated as single line containing:

1234561234 12

Registry Key Names

Key Name Syntax

If a line does not contain an equal sign (=), then the line specifies the name of a Registry key or subkey. In a Regini script file, the subkey name consists of all text from the first non-blank character to the end of the line, including spaces, on any line that does not contain an equal sign.

Leading spaces are significant. If there are no leading spaces, then the named subkey is an absolute path in the Registry.

For example:

\Registry\Machine\Software

– or –

USER:Control Panel

In the second example, USER: is replaced by the full path to the root of the currently logged-on user's profile (for example, \Registry\Users\S-x-x-xxxx...).

If a line in the script file does not contain an equal sign, and there are one or more spaces at the beginning of that line, then the subkey name on that line is defined in relation to the subkey preceding it in the Registry hierarchy. If the number of leading spaces is the same as in the preceding subkey, then Regini locates the subkey at the same level. If the number of leading spaces is lower, Regini locates the subkey one level higher; if the number is higher, Regini locates the subkey one level lower.

For example:

\Registry\Machine\Software

Level1a

Level2a

Level2b

Level3a

Level1b

Kernel and User Key Names

Note that Regini works with Kernel Registry strings. When you access the Registry in User mode to modify the HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, or HKEY_CURRENT_USER keys, the string is converted to the following in Kernel mode:

HKEY_LOCAL_MACHINE is converted to \Registry\Machine.

HKEY_USERS is converted to \Registry\User.

HKEY_CURRENT_USER is converted to \Registry\User\User_SID, where User_SID is the current user's security identifier (SID).

ACL

After the subkey name, you can optionally specify an access control list (ACL). The ACL is a list of decimal numbers separated by spaces within square brackets. The decimal numbers represent the following user rights:

1.Administrator Full

2.Administrator R

3.Administrator RW

4.Administrator RWD

5.Creator Full

6.Creator RW

7.World Full

8.World R

9.World RW

10.World RWD

11.Power Users Full

12.Power Users RW

13.Power Users RWD

14.System OpFull

15.System OpRW

16.System OpRWD

17.System Full

18.System RW

19.System R

20.Administrator RWX

Value Entries

If a line in a script file contains an equal sign (=), then that line specifies a value for a Registry value entry. The text to the left of the equal sign, if any, is the name of the value entry. The text to the right of the equal sign specifies the data type and value of the value entry. Syntax for specifying a value is as follows:

ValueEntryName = DataType Value

where:

ValueEntryNameis the name of the value entry.

DataTypeis the data type.

Valueis the value of the entry.

The value entry name consists of all characters from the first non-blank character on the line to the last non-blank character before the equal sign. The value consists of the first non-blank character after the data type to the end of the line.

Eight data type keywords are supported by Regini. If none is specified, the default data type, REG_SZ, is used. The data types and the format of the values for each are:

Sets the Registry

Data TypeValue Datadata type toNotes

REG_SZA stringREG_SZREG_SZ is the defaut

data type.

REG_EXPAND_SZA stringREG_EXPAND_SZ

REG_MULTI_SZOne or moreREG_MULTI_SZ

strings, each

within quotes

REG_MULTISZFILEA path to a fileREG_MULTI_SZThe file is opened and

each quoted string is

added to the value.

REG_DWORDA decimalREG_DWORDUse 0x to specify a

numberhexadecimal value, 0o

to specify an octal

value, and 0b to

specify a binary value.

You can use the

strings On, Yes, or

True, which are

converted to

0x00000001, and the

strings Off, No, or

False, which are

converted to

0x00000000.

REG_BINARYTwo or moreREG_BINARYThe first decimal

decimal numbersnumber must be the

number of bytes of

data that follow. The

remaining numbers are

converted into 32-bit

numbers. The value

length is always a

multiple of 4 bytes.

REG_BINARYFILEA path to a fileREG_BINARYThe named file is

opened and its

contents stored in the

Registry as the value.

The length of the value

is the length of the file.

DELETE[No value data][No data type]If this keyword is

specified as the data

type, the value entry

name is deleted.

Sample Script Files

The sample Regini script files included in this section show how to:

Store a user name to use for automatic logon

Add a value for the current user in the Exchange client subkey

Modify several Registry keys at the same time

Storing a user name for automatic administrative logon

This example shows how to use a Regini script to set a user name for an administrative account that can log on automatically to Windows NT.

Start the computer, and press ctrl+alt+del to log on to Windows NT. In the Logon Information dialog box, type a user name and password. The user name you type is stored in the DefaultUserName value entry in the Winlogon subkey of the Registry.

To ensure that the value of DefaultUserName never changes, create a script file containing the following text:

\Registry\Machine Software Microsoft Windows NT CurrentVersion Winlogon DefaultUserName = REG_SZ USERNAME

where DefaultUserName is the value name, REG_SZ is the data type and USERNAME is the desired result or value.

Note

To log on automatically to Windows NT, you must supply the password associated with the user name. The password is stored in the DefaultPassword value entry in the Winlogon subkey of the Registry. If no password was entered in the Logon Information dialog box, you do not need to supply a password in the script file.

To reference the script file, create a batch file containing the following command:

c:\reskit\regini c:\username.ini

where the name of the script file saved is Username.ini.

To ensure that the DefaultUserName will not change, however many users log on, place this batch file in the Systemroot\Profiles\All Users\Start Menu\Programs\Startup directory.

Adding a value for the current user in the Exchange client subkey

These examples show how to add a value entry for the current user in the Exchange subkey.

You can change the value of Exchange client options in either HKEY_USERS or HKEY_CURRENT_USER.

The following two sample scripts show how to use this information with Regini when you want to add or modify multiple Registry keys.

Example 1

\registry\user\software\microsoft\exchange\client\options DictionaryLangId = REG_SZ 1033 PickLogonProfile = REG_SZ 0

Example 2

\registry\user\S-1-5-21-2185238159-1414228629-1939875897-1000\software\microsoft\exchange\client\options DictionaryLangId = REG_SZ 1033 PickLogonProfile = REG_SZ 0

Setting the default user name

This example shows how to use Regini to set the default user name in the Logon Information dialog box. This script modifies HKEY_LOCAL_MACHINE.

\Registry\Machine Software Microsoft Windows NT CurrentVersion Winlogon DefaultUserName = REG_SZ bmiller

Complex sample

The following scripts were obtained by running the Regdmp utility.

\Registry\Machine\Software Classes AudioCD [10 1 17 5] EditFlags = REG_BINARY 0x00000004 0x00000002 DefaultIcon = REG_EXPAND_SZ %SystemRoot%\system32\shell32.dll,40 shell = play play = &Play command = REG_EXPAND_SZ %SystemRoot%\system32\cdplayer.exe \ /play %1 Microsoft Rpc DCOM Protocols = REG_MULTI_SZ "ncadg_ip_udp" \ "ncadg_ipx" \ "ncacn_ip_tcp" \ "ncacn_spx" \ "ncacn_nb_nb" \ "ncacn_nb_ipx" NameService Protocol=ncacn_np NetworkAddress=\\. ServerNetworkAddress=\\. Endpoint=\pipe\locator DefaultSyntax=3 NetBios ServerProtocols ncacn_np=rpclts1.dll ncalrpc=ncalrpc ncacn_vns=rpclts8.dll ClientProtocols ncacn_np=rpcltc1.dll ncalrpc=ncalrpc ncacn_vns=rpcltc8.dll NetDDE [17 1] DDE Shares SerialNumber = REG_BINARY 8 0x09000005 0x01000000 CLPBK$ fuCmdShow = REG_DWORD 0x7 ItemList = REG_MULTI_SZ NewStyleLink = REG_SZ NumItems = REG_DWORD 0x0 OldStyleLink = REG_SZ Revision = REG_DWORD 0x1 SecurityDescriptor = REG_BINARY 0x6C \ 0x80040001 \ 0x0000004C \ 0x0000005C \ 0x00000000 \ 0x00000014 \ 0x00380002 \ 0x00000002 \ 0x00180200 \ 0x000F03FF \ 0x00000201 \ 0x05000000 \ 0x00000020 \ 0x00000220 \ 0x00180200 \ 0x000002BD \ 0x00000101 \ 0x01000000 \ 0x00000000 \ 0x00000220 \ 0x00000201 \ 0x05000000 \ 0x00000020 \ 0x00000220 \ 0x00000201 \ 0x05000000 \ 0x00000020 \ 0x00000220 SerialNumber = REG_BINARY 8 0x09000005 0x01000000 Service = REG_DWORD 0x1 SharedFlag = REG_DWORD 0x1 ShareName = REG_SZ CLPBK$ ShareType = REG_DWORD 0x4 StartAppFlag = REG_DWORD 0x0 StaticDataLink = REG_SZ ClipSrv|System


Regina REXX for Win32™

Copyright © 1995 Microsoft Corporation. All rights reserved.

Written for Microsoft Corporation by Ataman Software, Inc. (info@ataman.com).

This document describes issues specific to the Win32 port of Regina REXX.

Table of Contents

Installation4

Usage4

OLE Automation Support4

w32CreateObject4

w32ReleaseObject5

w32CallFunc, w32CallProc5

w32GetProperty6

w32PutProperty6

w32GetObject7

w32GetSubObj7

Win32 Registry Functions7

w32ExpandEnvironmentStrings8

w32RegCloseKey8

w32RegConnectRegistry8

w32RegCreateKey9

w32RegDeleteKey9

w32RegDeleteValue10

w32RegEnumKey10

w32RegEnumValue10

w32RegFlushKey11

w32RegGetKeySecDesc11

w32RegLoadKey12

w32RegOpenKey12

w32RegQueryInfoKey12

w32RegQueryValue13

w32RegQueryValue13

w32RegRestoreKey14

w32RegSaveKey14

w32RegSetKeySecDesc15

w32RegSetValue15

w32RegUnLoadKey16

Win32 Event Log Functions16

w32BackupEventLog16

w32ClearEventLog17

w32CloseEventLog17

w32FindEventLogEntry17

w32GetEventCategory18

w32GetEventData18

w32GetEventID18

w32GetEventNumStrings19

w32GetEventString19

w32GetEventTimeGenerated19

w32GetEventTimeWritten20

w32GetEventType20

w32GetNumberOfEventLogRecords20

w32OpenBackupEventLog21

w32OpenEventLog21

w32WriteEventLog21

Known Limitations22

Installation

Installation is simple, just copy REXX.EXE to a directory that is in your PATH.

Alternatively, you can run the SETUP.CMD file, this file runs REXX on a script called: INS-REXX. This script will prompt for a directory name, create the directory, then copy REXX.EXE to that directory. Finally, it will add that directory to your PATH environment variable. You will need to logoff and log back on before this new PATH setting takes effect.

Usage

Prepare a script file using NOTEPAD.EXE, or other text file editor. To execute the script, run REXX.EXE with the name of the script file.

Example:

rexx myscript.rexx

A new feature in CMD.EXE under Windows NT 3.51 allows the same script above to

be started as:

Example:

myscript.rexx

For information on how to do this, see the documentation under the /X switch when you type CMD /?.

OLE Automation Support

The OLE Automation support closely parallels that found in Microsoft Visual Basic 3.0.

The “OLEAUTO” subdirectory contains three REXX files that use OLE Automation with Microsoft Word, Microsoft Excel and a sample application called DspCalc2. See the “README.TXT” file in that subdirectory for more information on the samples.

w32CreateObject

The w32CreateObject function is the most common way to access an OLE Automation object. This function launches (if necessary) the OLE Automation server and returns a handle through which the OLE Automation object can be manipulated.

Syntax:

ObjectHandle = w32CreateObject ( OLEAutomationServerClassName )

Example:

wrd = w32CreateObject(“Word.Basic”)

w32ReleaseObject

The w32ReleaseObject subroutine is called to free up the resources obtained when an OLE Automation object was created or otherwise obtained. If you do not call w32ReleaseObject, the resources will remain in use until REXX exits.

Syntax:

call w32ReleaseObject ObjectHandle

Example:

call w32ReleaseObject wrd

Valid object handles are those obtained by calls to w32CreateObject, w32GetObject, w32GetSubObj, w32GetProperty and w32CallFunc.

w32CallFunc, w32CallProc

The w32CallFunc function is used to access a method of an OLE Automation object where you expect to receive a return value. If no return value is needed, use w32CallProc instead.

Syntax:

ReturnValue = w32CallFunc ( ObjectHandle, MethodName,[ TypeList ], [ Argument, ... ] ) w32CallProc ( ObjectHandle, MethodName, [ TypeList ], [ Argument, ... ] )

Examples:

SalesValue = w32CallFunc(wrd, “GetMergeField$”, , “Sales”) w32CallProc(wrd, “FileNew”, ‘si’, “Normal”, 0)

Optional arguments to the method can be omitted, leaving only the corresponding “,” as in the example for w32CallFunc above.

The TypeList is optional, and for many OLE Automation servers is unnecessary because automatic type conversion is usually done by the OA server. REXX is an untyped language and all its data are stored as strings, thus, if TypeList is omitted, all arguments will be sent to the OA server as strings. However some OA servers, such as Microsoft Word, require correct typing of parameters. The TypeList is simply a series of characters that define the type of each argument that follows. There should be as many type characters list in the TypeList as there are arguments listed. The type character for an omitted argument is ignored, but must be present. (I usually use ‘ ‘ as the type character for omitted arguments.)

Type Required

Type Character

Boolean

b

Currency

c

Date

d

Integer (16-bit)

i

Integer (32-bit)

I

Object Handle

o

Real Number (4 byte)

r

Real Number (8 byte)

R

String

s

w32GetProperty

The w32GetProperty function returns the value of a named property from an OLE Automation object.

Syntax:

ReturnValue = w32GetProperty ( ObjectHandle, PropertyName )

Example:

MyCaption = w32GetProperty(xl, “Caption”)

w32PutProperty

The w32PutProperty subroutine sets the value of a named property in an OLE Automation object.

Syntax:

call w32PutProperty ObjectHandle, PropertyName,Type, Value

Example:

call w32PutProperty xl, “Caption”, , “Change Window Title”

The Type is optional, and is defined using the same characters as TypeList in w32CallProc. The Type is the data type in which the OLE Automation server requires Value to be expressed.

w32GetObject

The w32GetObject function is similar to w32CreateObject. It gets an object that previously exists either saved in a disk file, or in already running OLE Automation server. It returns a handle through which the OLE Automation object can be manipulated.

Syntax:

ObjectHandle = w32GetObject ( [ Filename ], [ OAServerClassName ] )

Example:

xl = w32GetObject(“D:\MYDIR\SPREADSHEET.XLS”)

w32GetSubObj

Some OLE Automation servers, such as Microsoft Excel, have methods that return handles to sub-objects. The w32GetSubObj function is a bit of syntactic sugar that works exactly like w32CallFunc. The only difference is that the return value must be the handle of an object.

Syntax:

ObjectHandle = w32GetSubObj ( ObjectHandle, MethodName,[ TypeList ], [ Argument, ... ] )

Example:

wbs = w32GetSubObj(xl, “WorkBooks”)

Object handles obtained by w32GetSubObj should be released by w32ReleaseObject when no longer needed.

Win32 Registry Functions

The Win32 registry functions closely parallels the corresponding C functions found in the Win32 API. The descriptions below are fairly brief. Consult the Win32 SDK documentation for more detailed information.

The “W32FUNCS” subdirectory contains an example file: “registry.rexx” that uses the registry functions. See the “README.TXT” file in that subdirectory for more information on this example.

WARNING: The Win32 Registry contains information vital to the functioning of your system. The functions below should be used with caution.

w32ExpandEnvironmentStrings

The w32ExpandEnvironmentStrings function expands environment variables (names are denoted by preceding and trailing ‘%’) in the string argument using the process’ environment. It returns the expanded string.

Syntax:

expanded_string = w32ExpandEnvironmentStrings ( string )

Example:

path = w32ExpandEnvironmentStrings(“PATH=%PATH%”) say path /* says: PATH=C:\WINNT\system32;C:\WINNT;... */

w32RegCloseKey

The w32RegCloseKey subroutine closes a key handle returned by w32RegOpenKey, w32RegConnectRegistry, or w32RegCreateKey.

Syntax:

call w32RegCloseKey KeyHandle

Example:

call w32RegCloseKey hkey;

w32RegConnectRegistry

The w32RegConnectRegistry function opens a registry key on a remote host. It returns a handle to the remotely opened key.

Syntax:

hkeyRet = w32RegConnectRegistry ( hostname, hkey )

Example:

hk = w32RegConnectRegistry(“\\mainserver”, “HKEY_LOCAL_MACHINE”)

Hkey should be one of the string constants HKEY_LOCAL_MACHINE or HKEY_USERS.

w32RegCreateKey

The w32RegCreateKey creates or opens a subkey under a registry key. It returns a handle to the subkey created or opened.

Syntax:

hkeyRet = w32RegCreateKey ( hkey, subkeyname )

Example:

hk = w32RegCreateKey(“HKEY_LOCAL_MACHINE”,“Software\Microsoft\NewProduct”)

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegDeleteKey

The w32RegDeleteKey subroutine deletes the key subkey, which must be located under the key hkey. All values under subkey are also deleted.

Syntax:

call w32RegDeleteKey hkey, subkey

Example:

call w32RegDeleteKey hk, “WidgetTuningParameters”

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegDeleteValue

The w32RegDeleteValue subroutine deletes the value named valuename, which must be located under the key hkey.

Syntax:

call w32RegDeleteValue hkey, valuename

Example:

call w32RegDeleteValue whk, “WidgetMaximumSize”

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegEnumKey

The w32RegEnumKey function returns the name of the subkey of hkey specified by index.

Syntax:

subkeyname = w32RegEnumKey ( hkey, index )

Example:

firstsubkey = w32RegEnumKey(“HKEY_LOCAL_MACHINE”, 0)

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

Index ranges from 0 to w32RegQueryInfoKey(hkey, “NumSubKeys”)-1.

w32RegEnumValue

The w32RegEnumValue function returns the name of the value under hkey specified by index.

Syntax:

valuename = w32RegEnumValue ( hkey, index )

Example:

firstvalue = w32RegEnumValue(“HKEY_LOCAL_MACHINE”, 0)

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

Index ranges from 0 to w32RegQueryInfoKey(hkey, “NumValues”)-1.

w32RegFlushKey

The w32RegFlushKey subroutine cause all changes in a key to be flushed immediately to disk. The use of this subroutine is normally not necessary and should only be used in very unusual circumstances.

Syntax:

call w32RegFlushKey hkey

Example:

call w32RegFlushKey hk

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegGetKeySecDesc

The w32RegGetKeySecDesc function returns a hexadecimal string representing the self-relative security descriptor associated with key hkey.

Syntax:

secdesc = w32RegGetKeySecDesc ( hkey )

Example:

secdesc = w32RegGetKeySecDesc(“HKEY_LOCAL_MACHINE”)

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegLoadKey

The w32RegLoadKey subroutine creates subkey subkeyname under the key hkey using the key hive stored in filename.

Syntax:

call w32RegLoadKey hkey, subkeyname, filename

Example:

call w32RegLoadKey hk, “Stuff”, “D:\keyhives\stuff”

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegOpenKey

The w32RegOpenKey opens a subkey under a registry key. It returns a handle to the subkey opened.

Syntax:

hkeyRet = w32RegOpenKey ( hkey, subkeyname )

Example:

hk = w32RegOpenKey(“HKEY_LOCAL_MACHINE”,“Software\Microsoft\NewProduct”)

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegQueryInfoKey

The w32RegQueryInfoKey returns the requested information about key hkey.

Syntax:

info = w32RegQueryInfoKey ( hkey, infoname )

Example:

nKeys = w32RegQueryInfoKey(hkey, “NumSubKeys”)

infoname

Value Returned

NumSubKeys

Number of subkeys under hkey.

MaxSubKeyName

Length of longest subkey name.

NumValues

Number of values under hkey.

MaxValueName

Length of longest value name.

MaxValueData

Size of largest data item stored in a value.

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegQueryValue

The w32RegQueryValue function returns the data stored under valuename. If the data is of type REG_SZ or REG_EXPAND_SZ, a string is returned. If the data is of type REG_DWORD, a string representing that number is returned. All other data types return a hexadecimal string representation of the data.

Syntax:

value = w32RegQueryValue ( hkey, valuename )

Example:

wspeed = w32RegQueryValue(hk, “WidgetSpeed”)

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegQueryValue

The w32RegQueryValue function returns the type of the data stored under valuename.

Syntax:

type = w32RegQueryValueType ( hkey, valuename )

Example:

type = w32RegQueryValueType(hk, “WidgetSpeed”)

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

Type is returned as one of the following strings: REG_DWORD, REG_EXPAND_SZ, REG_SZ, REG_BINARY, REG_DWORD_BIG_ENDIAN, REG_LINK, REG_MULTI_SZ, REG_NONE, REG_RESOURCE_LIST, UNKNOWN.

w32RegRestoreKey

The w32RegRestoreKey subroutine overwrites hkey with information from the hive stored in filename.

Syntax:

call w32RegRestoreKey hkey, filename

Example:

call w32RegRestoreKey hk, “D:\keyhives\stuff”

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegSaveKey

The w32RegSaveKey subroutine saves the information in hkey as a hive stored in filename.

Syntax:

call w32RegSaveKey hkey, filename

Example:

call w32RegSaveKey hk, “D:\keyhives\stuff”

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

w32RegSetKeySecDesc

The w32RegSetKeySecDesc subroutine sets the security descriptor of key hkey.

Syntax:

call w32RegSetKeySecDesc hkey, secdesc

Example:

call w32RegSetKeySecDesc hk, “ff00...”

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

SecDesc is a hexadecimal string representing a self-relative security descriptor. The easiest way to make one is to create a temporary key with REGEDT32.EXE, set its security, then use the w32RegGetKeySecDesc to obtain the security descriptor.

w32RegSetValue

The w32RegSetValue subroutine sets the value of valuename to data of type type.

Syntax:

call w32RegSetValue hkey, valuename, type, data

Example:

call w32RegSetValue hk, “BinaryUserInfo”, “REG_BINARY”, “ff003a”

Hkey should be a previously obtained key handle or one of the string constants: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS.

Type is one of the following strings: REG_DWORD, REG_EXPAND_SZ, REG_SZ, REG_BINARY, REG_DWORD_BIG_ENDIAN, REG_LINK, REG_MULTI_SZ, REG_NONE, REG_RESOURCE_LIST, UNKNOWN.

Data is a string if type is REG_SZ or REG_EXPAND_SZ. Data is a string of decimal digits if type is REG_DWORD. For all other types, data is a hexadecimal string representing the data.

w32RegUnLoadKey

The w32RegUnLoadKey subroutine unloads the subkey named by subkeyname.

Syntax:

call w32RegUnLoadKey hkey, subkeyname

Example:

call w32RegUnLoadKey hk, “Stuff”

Hkey should be a previously obtained key handle or one of the string constants: HKEY_LOCAL_MACHINE, HKEY_USERS.

Subkeyname must be the name of a subkey that was previously created with w32RegLoadKey.

Win32 Event Log Functions

The Win32 Event Log functions closely parallels the corresponding C functions found in the Win32 API. The descriptions below are fairly brief. Consult the Win32 SDK documentation for more detailed information.

The “W32FUNCS” subdirectory contains an example file: “eventlog.rexx” that uses the eventlog functions. See the “README.TXT” file in that subdirectory for more information on this example.

w32BackupEventLog

The w32BackupEventLog subroutine saves the event log opened on helog in the disk file specified by filename.

Syntax:

call w32BackupEventLog helog, filename

Example:

call w32BackupEventLog helog, “D:\keyhives\stuff”

w32ClearEventLog

The w32ClearEventLog subroutine clears the event log opened on helog. If the optional argument filename is provided, the eventlog will be saved to that file.

Syntax:

call w32ClearEventLog helog, [ filename ]

Example:

call w32ClearEventLog helog

w32CloseEventLog

The w32CloseEventLog subroutine frees any resources associated with the eventlog handle helog.

Syntax:

call w32CloseEventLog helog

Example:

call w32CloseEventLog helog

w32FindEventLogEntry

The w32FindEventLogEntry subroutine reads the eventlog entry specified by eventnum into a static buffer. This buffer is allocated on a per-process basis and any call to w32CloseEventLog or w32FindEventLogEntry on ANY HANDLE will invalidate the data from the previous call to w32FindEventLogEntry. Data from the static buffer is accessed by the w32GetEventCategory, w32GetEventData, w32GetEventID, w32GetEventNumStrings, w32GetEventString, w32GetEventTimeGenerated, w32GetEventTimeWritten and w32GetEventType functions.

Syntax:

call w32FindEventLogEntry helog, eventnum

Example:

call w32FindEventLogEntry helog, 1 /*Find first eventlog entry.*/

Eventnum ranges from 1 to w32GetNumberOfEventLogRecords(helog).

w32GetEventCategory

The w32GetEventCategory function returns the event category associated with event log entry found in the last call to w32FindEventLogEntry.

Syntax:

category = w32GetEventCategory ( )

Example:

category = w32GetEventCategory()

w32GetEventData

The w32GetEventData function returns a hexadecimal string representing the binary data associated with event log entry found in the last call to w32FindEventLogEntry.

Syntax:

data = w32GetEventData ( )

Example:

data = w32GetEventData()

w32GetEventID

The w32GetEventID function returns the event identifier associated with event log entry found in the last call to w32FindEventLogEntry.

Syntax:

id = w32GetEventID ( )

Example:

id = w32GetEventID()

w32GetEventNumStrings

The w32GetEventNumStrings function returns the number of strings associated with event log entry found in the last call to w32FindEventLogEntry.

Syntax:

nStrings = w32GetEventNumStrings ( )

Example:

ns = w32GetEventNumStrings()

w32GetEventString

The w32GetEventString function returns the string denoted by index associated with event log entry found in the last call to w32FindEventLogEntry.

Syntax:

string = w32GetEventString ( index )

Example:

str = w32GetEventString(1)

Index ranges from 1 to w32GetEventNumStrings().

w32GetEventTimeGenerated

The w32GetEventTimeGenerated function returns (for the event log entry found in the last call to w32FindEventLogEntry) the date the event was generated. The format of the date is that returned by the standard C function asctime.

Syntax:

date = w32GetEventTimeGenerated ( )

Example:

date = w32GetEventTimeGenerated()

w32GetEventTimeWritten

The w32GetEventTimeWritten function returns (for the event log entry found in the last call to w32FindEventLogEntry) the date the event was written. The format of the date is that returned by the standard C function asctime.

Syntax:

date = w32GetEventTimeWritten ( )

Example:

date = w32GetEventTimeWritten()

w32GetEventType

The w32GetEventType function returns the numeric type associated with event log entry found in the last call to w32FindEventLogEntry. Errors are type 1, Warnings are type 2, and Informational messages are type 4.

Syntax:

nStrings = w32GetEventType ( )

Example:

ns = w32GetEventType()

w32GetNumberOfEventLogRecords

The w32GetNumberOfEventLogRecords function returns the number of event log records in the event log opened on helog.

Syntax:

nRecords = w32GetNumberOfEventLogRecords ( helog )

Example:

nr = w32GetNumberOfEventLogRecords()

w32OpenBackupEventLog

The w32OpenBackupEventLog function returns a handle to the events in an eventlog backup file (created by w32BackupEventLog or w32ClearEventLog) stored on host hostname specified by filename. If hostname not specified, the event log is opened on the local host.

Syntax:

helog = w32OpenBackupEventLog ( [hostname], filename )

Example:

h = w32OpenBackupEventLog(, “C:\applog.evt”)

w32OpenEventLog

The w32OpenEventLog function returns a handle to the events in the sourcename eventlog stored on host hostname. If hostname not specified, the event log is opened on the local host.

Syntax:

helog = w32OpenEventLog ( [hostname], sourcename )

Example:

h = w32OpenEventLog(“\\mainserver”, “system”)

w32WriteEventLog

The w32WriteEventLog subroutine writes an event entry to the sourcename eventlog stored on host hostname. If hostname not specified, the event log written to is on the local host. Errors are type 1, Warnings are type 2, and Informational messages are type 4.

Syntax:

call w32WriteEventLog [ hostname ], sourcename, [ eventtype ],[ category ], [ eventid ], [ data ], [ string1 ... ]

Example:

call w32WriteEventLog , “My REXX Prog”, 2, , , , “Error message”

For eventtype, Errors are type 1, Warnings are type 2, and Informational messages are type 4.

Data is optional binary data to be put into the eventlog. It is specified as a hexadecimal string.

Eventtype defaults to 1 (Error).

Category defaults to 0.

EventID defaults to 0.

At least one of data or string1 must be present.

Known Limitations

Because Win32 raises process termination and process interrupt signals in a separate thread, the SIGNAL and CALL statements cannot be used with the HALT conditions.

Regina has been modified to treat attempts to use the HALT condition as a syntax error.

The implementation of the STREAM statement’s ‘C’ option is weak when used with the READABLE, EXECUTABLE or WRITEABLE commands:

·All regular files are considered executable.

·Only the older DOS-style read-only attribute is looked at to determine read-only. Windows NT security constraints imposed under NTFS are ignored.

Forcing a NOTREADY condition on a console "file" interacts with the underlying runtime stdio functions such that the file can never be reset. [This is a hard error to describe and one that you will probably never encounter. To understand it, Look in the "srccode\trip.w32" file: files.rexx. See the sections using "<stdout>" (tests 15 and 17) that are commented out.]

At the time of this writing, Windows 95 was still in beta. Only limited testing has been done under Windows 95.


AutoExNT Service Version 1.2

AutoExNT Service
Version 1.2

Windows NT® 4.0 Resource Kits

Contents

Introduction

Requirements

Installing AutoExNT

Testing AutoExNT

Notes

Configuring AutoExNT to run at startup

Introduction

The AutoExNT service allows you to run a custom batch file, Autoexnt.bat, when you start a computer, without having to log on to that computer.

Requirements

To use the AutoExNT service, the computer must be running Windows NT version 3.5 or later.

The AutoExNT service includes the following files:

Autoexnt.exe | The AutoExNT service executable file.
Autoexnt.doc | This Readme file.
Instexnt.exe | The Setup program used to install the service.
Servmess.dll | The AutoExNT message file.

Installing AutoExNT

To install the AutoExNT service

1.Copy the Autoexnt.exe and Servmess.dll files into the Systemroot/System32 directory.

2.Using a text editor, create a batch file containing the commands you wish to include, and name it Autoexnt.bat.

3.Copy Autoexnt.bat into the Systemroot/System32 directory.

4.At the command prompt, type:

instexnt install

When installation has completed successfully, the application gives the following response:

>> CreateService AutoExNT SUCCESS with InterActive Flag turned OFF.

To view the installation processes running on the desktop, use the /interactive option. At the command prompt, type:

instexnt install /interactive

Note

If you use the /interactive option, any users who are logged on locally are able to stop the processes from running.

When installation has completed successfully, the application gives the following response:

>> CreateService AutoExNT SUCCESS with InterActive Flag turned ON.

Testing AutoExNT

To test the AutoExNT service, log on as Administrator and type the following command at the command prompt:

net start autoexnt

If the service starts correctly, Autoexnt.bat runs in a command-prompt window.

Notes

AutoExNT includes an /interactive option, analogous to the /interactive option of the at command. This option allows you to view the status of processes as they run.

As no user-environment variables have yet been declared when AutoExNT runs at system startup, you must use full pathnames.

If you need a service to be running, such as the Server or Schedule service, before you start running a dependent process, include a net start service command at the beginning of your Autoexnt.bat file.

Configuring AutoExNT to run at startup

To configure the AutoExNT service to run when you start your computer

1.Double-click Services in Control Panel.

2.In the Services list, click AutoExNT.

3.Click Startup and, in the Startup Type box, click Automatic.

4.Choose OK.

Note

When you need to access an area outside your local system (for example using the net use command), click Logon As: This Account, and specify an account that has adequate permissions on the domain, and provide a password as required.

For questions or feedback concerning this utility, please contact rkinput@microsoft.com.


Compreg.exe Version 1.01

Compreg.exe
Version 1.01

Windows NT® Resource Kits

Contents

Introduction

Command-line syntax

Examples

Notes

Introduction

Compreg is a 32-bit, character-based, command-line utility that compares local or remote Registry keys on computers running Windows NT or Windows 95.

Command-line syntax

compreg key1 key2 [-v] [-r] [-e] [-d] [-q] [-n] [-h] [-?]

where

OptionMeaning

key1 key2Local or remote Registry keys to compare (default:

HKEY_CURRENT_USER)

(example: \\HOTDOG\HKEY_LOCAL_MACHINE\Software)

The Registry subtrees can be abbreviated as follows:

HKEY_CURRENT_USER cu

HKEY_CLASSES_ROOT cr

HKEY_USERS us

If key2 is the name of a computer, the key name specified in key1 is

appended automatically.

-vVerbose. Prints both differences and matches.

rRecurse into subkeys that only exist in one key.

eSets the error level to the error code that was in effect the last time the

utility was run. By default, the error level is set to the number of

differences that were found.

dPrints only the value entry names, not the actual values.

-qQuiet. Prints only the number of differences.

-nNo color in output. By default, color is used.

-hDisplays additional help.

-?Displays this screen.

Examples

The following are examples of Compreg usage:

compreg "\lm\system\currentcontrolset\control\session manager" \\MOON

compreg HKEY_CURRENT_USER\Cheech HKEY_CURRENT_USER\Chong

The following are examples of possible output:

1 \Environment!Cpu REG_SZ,[i386] 1 \Memory Management!PagingFiles REG_MULTI_SZ,[C:\pagefile.sys 20|] 2 \Memory Management!PagingFiles REG_MULTI_SZ,[D:\pagefile.sys 43|] X \AnyKey!AnyValue REG_DWORD,[4] End of search: 3 differences found.

Notes

Output produced by this utility consists of blocks of lines. Each block describes one difference. Each line starts with 1 or 2 (indicating whether it concerns key1 or key2), followed by an exclamation mark (!), then the name of the key or value entry, and optionally the value type and data. Lines starting with an 'X' indicate values and subkeys that exist in both keys.

Blocks containing one line indicate that a particular subkey or value entry is present only in that key. Blocks containing two lines indicate that there is a difference between the data types or actual values of the entries.

In the example above, the first block indicates that the Cpu value entry in the Environment subkey is only present on the first computer (key1). The second block indicates that the PagingFiles value entry on \\MOON are located on a different drive. The third block indicates that the AnyValue value entry in the AnyKey key exists in both sources.

For questions or feedback concerning this utility, please contact rkinput@microsoft.com.


Dhcpcmd.exe

Windows NT® Resource Kits

Contents

Introduction

Command-line syntax

Dhcpcmd commands

AddIpRange

AddReservedIp

EnumClients

MibCounts

ServerConfig

Introduction

You can use the Dhcpcmd utility as an auxiliary tool to administer DHCP servers.

Command-line syntax

dhcpcmd server_IP_address command [command options]

Dhcpcmd commands

The following Dhcpcmd commands are available:

AddIpRange

Used to add a range of IP addresses to an existing scope.

Syntax: dhcpcmd scope_address addiprange start_IP_range end_IP_range

Example: dhcpcmd 127.0.0.1 addiprange 11.101.0.0 11.101.4.1 11.101.4.254

AddReservedIp

Used to add a reserved IP address to an existing scope.

Syntax: dhcpcmd scope_address addreservedip reserved_IP_address hardware_string

where hardware_string represents the hardware address.

Example: dhcpcmd 127.0.0.1 addreservedip 11.101.0.0 11.101.13.53 08002B30369B

EnumClients

Used to list the lease information in a different format.

Syntax: dhcpcmd scope_address enumclients [-v | -h]

where

Option | Meaning
-v | Lists detailed lease information.
-h | Lists lease information with hardware information.

Example : dhcpcmd 127.0.0.1 enumclients 11.101.0.0 -h

MibCounts

Displays the current DHCP server statistics.

ServerConfig

Used to display current server parameters, or to set server parameters.

Syntax: dhcpcmd scope_address config_parameter value

Examples:

dhcpcmd 127.0.0.1 serverconfig

Displays current parameters.

dhcpcmd 127.0.0.1 serverconfig backupinterval 15

Sets the database backup interval to 15 minutes.


Dhcploc.exe

Windows NT® Resource Kits

Contents

Introduction

Command-line syntax

Examples

Introduction

You can use the Dhcploc utility to detect unauthorized DHCP servers on a subnet. It displays the DHCP servers that are active on the subnet, and beeps and sends alert messages when it detects unauthorized DHCP servers.

Command-line syntax

dhcploc [-p] [-a:"list_of_alertnames"] [-i:alertinterval] computer_IP_address [IP addresses of valid DHCP servers]

where

ParameterMeaning

computer_IP_addresThe IP address of the computer on which you are running the

utility. If the computer has multiple network adapters

installed, you need to select an adapter (and the corresponding

IP address) that is connected to the subnet under test.

IP addresses of valid Specify any number of IP addresses corresponding to

DHCP serversauthorized DHCP servers. The Dhcploc utility does not

respond to packets sent from these servers. However, if you do

not include the -p option, it will display the packets it sees

from these servers.

-pDisables display of packets sent from authorized DHCP

servers.

-a:"list_of_alertnames"Sends alert messages to the names specified in

list_of_alertnames. Separate multiple names with a space in

the list, and include the quotation marks to prevent Dhcploc

from confusing the names with IP addresses.

-i:alertintervalSpecifies the alert frequency in seconds.

Examples

Output produced by the Dhcploc utility has the following format:

time (IP)computer_IP_address packet_type (S)server_IP_address [***]

***Indicates an unauthorized server.

17:34:58 (IP)0.0.0.0 NACK (S)11.11.31.84 *** 17:36:38 (IP)11.101.190.130 OFFER (S)11.101.12.226 *** 17:36:38 (IP)11.101.196.231 ACK (S)11.101.13.53 17:36:53 (IP)11.101.196.231 ACK (S)11.101.13.53 17:37:05 (IP)11.101.196.234 OFFER (S)11.101.13.53 17:37:05 (IP)11.101.193.232 OFFER (S)11.101.12.198 17:37:06 (IP)11.101.190.132 OFFER (S)11.101.12.226 ***


Event Log Dump Utility
Dumpel.exe

Windows NT® Resource Kits

Contents

Introduction

Command-line syntax

Examples

Introduction

This command-line utility can be used to dump an event log into a tab-separated text file. It can also be used to apply a filter to find or exclude certain event types. You can use this utility to dump the event log of both local and remote systems.

Command-line syntax

The options for this utility are:

OptionMeaning

-s servernameSpecifies the server whose event log to dump. Leading

backslashes on the server name are optional.

-f filenameSpecifies the output file. The default is STDOUT.

-l lognameSpecifies which log (system, application, or security) to dump.

If you specify an invalid log name, the application log will be

dumped.

-m sourcenameSpecifies the source (such as Rdr, Serial, and so on) from which

to dump records, as you can only supply one source. If you do

not include this option, all events are dumped. If you specify a

source that is not registered in the Registry, the application log

will be searched for records of this type.

-e n1 n2 n3 ...Filters for event ID nn (you can specify up to 10 event IDs). If

you include the -r switch, all records except records of these

types are dumped. If you do not include the -r option, only

records of these types are dumped, and all events from the

specified sourcename are selected. You cannot use this option

without the -m option.

-rSpecifies whether to apply a filter to find or exclude specified

sources or records.

-tIf you include this option, individual strings are separated by

tabs. If you do not include this option, they are separated by

spaces.

Examples

To dump the system event log on server \\Eventsvr to a file Event.out:

dumpel -s eventsvr -l system -f event.out

To dump the local system event log, including only rdr events 2013:

dumpel -l system -m rdr -e 2013

To dump the local application log, and include all events except ones from the garbase source:

dumpel -l application -m garbase -r


Group copy User&rsquos Guide

Windows NT Group Copy
(Grpcpy.exeRPCPY.EXE)

Windows NT® Server 4.0 Resource Kit

Users’ Guide

Contents

Introduction

Group Copy Operations

Setting the Source Domain

Setting the Destination Domain

Creating a New Group Based on Another Group

Copying to an Existing Group

Adding Names on the Clipboard to a Group

Opening a log file

Saving a log file

IntroductionBackground

Grpcopy.exeRPCPY.EXE is a graphical program that runs only under Windows NT. Its purpose is to allowsenable users to copy the usernames in an existing group to another group, in the same or another domain or on a computer running Windows NTa Winnt machine. Users of this program must have at least account operator privileges into the domains within which they want to work with.

There are four menus on the menu bar of the main GrpcpyRPCPY window: Group, Edit, View, and Help. The Group menu contains options that allow you to choose the domains and groups with which to workthat you’ll be working with. The Edit menu allows you to use the Clipboard to transfer information between groups. The View menu allows you to display or hidetoggles the toolbar and status bar on and off. The Help menu containsoffers only the Help/About command; option--there is no Help file. The application does not havefeature any reporting capabilities.

The options on the toolbar, from left to right, are: Set Source Group,; Set Destination Group,; Create New Group,; Copy Existing Group,; Copy from Clipboard,; and About.

The upper left list in the upper-left part of the screencontrol contains the names of the groups available in the domain that you have chosen as the source domain. The upper right list in the upper-right control contains the group names from the destination domain. The list at the bottom displays an event log that grows as you copy groups from one location to anotheraround; this log includes a record of any errors that mightmay have occurred during the preceding operations. Some of the errors you could potentially receive are: duplicate user in destination group; and network-related errors.

Note

Throughout this program, wherever the term “domain” is used, the context also applies to the name of a specific computer running Windows NT Workstation or Windows NT Server. This is because each computer running Windows NT effectively has its own built-in one-computer domain.

Note: Throughout this program, wherever the term “domain” is used, the context also applies to the name of a specific Windows NT workstation/server. This is because each NT box effectively has its own build-it one-machine domain.

Group Copy OperationsActions

Setting the Source Domain

When you choose the Set Source Domain option from the Edit menu or from the toolbar, or press the associated toolbar button, the Set Source Domain dialog box appears. Specify the name of the domain from whichthat you want to copy groups from, then clickchoose OK. If you wantlike to set the sSource dDomain asto a computer running Windows NTWinnt machine, just precede the computermachine name with twoa double backslashesd (for example, \\my-computermachine).

Setting the Destination Domain

When you choose the Set Destination Domain option from the Edit menu or from the toolbar, or press its toolbar button, the Set Destination Domain dialog box appears. Specify the name of the domain to whichthat you want to copy groups to. The destinationis domain canmay be the same as the source domain if you plan to copy between groups on the same domain. If you wantlike to set the dDestination dDomain as a tocomputer running Windows NT a Winnt machine, just precede the computer machine name with twoa double backslashesd (for example, \\mycomputer-machine).

Creating a New Group Based on Another Group

If you wishneed to copy a group in the source domain to a new group in the destination domain, first click on the group from whichthat you want to copy from in the upper left list in the upper-left portion of the main GrpcpyRPCPY window. CNext, choose the Create New Group option from the Edit menu. The Create New Group dialog box appears.

TypeFill in athe name and a description for the new group. T; the name and description you typese determine how the new group will appear in group lists throughout all Windows NT administration utilities. Click the appropriate option to determine whether the new group will Indicate with the radio buttons whether you want the new group to be a global group or a local group; then clickpress OK to create the group. The dialog box closes, andwill disappear; then the group copy process begins. E: each name in the source group iswill be copied to the destination group. The bottom list in the main Grpcpy GRPCPY window will logs each name as it is added to the new group, along with any errors that are encountered.

Copying to an Existing Group

If you need to copy a group in the source domain to an existing group in the destination domain, first click on the group from whichthat you want to copy from in the upper left list in the upper-left portion of the main Grpcpy GRPCPY window. Then, click on the group to whichthat you want to copy to in the upper right list in the upper-right. Next, choose the Copy to Existing Group option from the Edit menu. The Copy to Existing Group dialog box appears.

The dialog box displays some information about the source and destination groups that you have chosen. If the information is correcteverything looks right, clickpress OK to begin. The dialog box closes disappears. One by one, the names in the source group arewill be appended to the destination group. As each name is copied, a new line will appears in the log list in the main Grpcpy GRPCPY window. IOr, if a name in the source group already exists in the destination group, that name iswill be noted with an error flag in the log file.

Adding Names on the Clipboard to a Group

You can add names to a group directly from the Clipboard. You mightwould typically want to do this if, for example, you happen to have a list of e-mail names in a text file, perhaps generated by ansome other utility. The names must be in a format similar to the following:

...

DOMAIN\NameAME1

DOMAIN\NameAME2

...

If your list of names is stored in a text file, openload the file into the Notepad, and select the entirewhole text, andthen copy it to the Clipboard. Next, switch back to GrpcpyRPCPY and choose the name of the group to which you want to add the names, from the destination domain (upper right) group list in the upper-right portion of the screen.

Choose the Copy from Clipboard option from the Edit menu. A dialog box will appear, displaying the contents of the Clipboard in a read-only text boxcontrol, and presentings well as the information about the destination group. (Unfortunately, a screen shot of this dialog is unavailable because the Clipboard is locked while it is being displayed.) ClickPress OK to pastebring the names from the Clipboard into the chosen group.

Opening a log file

Choose the Open fromunder the Group menu. The Open , the file dialog box will appears, in which you can choose to allow you to pick an old log file to open. When the log file opens,This will load the information in the file is displayed ininto the logging window for viewing.

Savinge a log file

Choose the Save (or Save As) fromunder the Group mMenu to, it will save the information in the logging window to the currentworking log file. You can then open tThis file as a spreadsheet then can be loaded in Microsoft Excel to view it or Spreadsheet for viewingotherwise manipulate the data it contains or other functions.


Scanreg.exe Version 1.05

Scanreg.exe
Version 1.05

Windows NT® Resource Kits

Contents

Introduction

Command-line syntax

Examples

Introduction

Scanreg is a 32-bit, character-based, command-line 'Registry GREP' that enables you to search for strings in Registry key names, value entry names, or actual value data. You can use this utility to scan registries on local or remote computers running Windows NT or Windows 95.

Command-line syntax

scanreg [-s] searchstring [-k] [-v] [-d] [[-r]rootkey] [-c] [-e] [-n]

where

OptionMeaning

-sThe string to search for

-rThe Registry subtree from which to start searching (default:

HKEY_CURRENT_USER).

Rootkey can be abbreviated as follows:

HKEY_LOCAL_MACHINE lm

HKEY_CURRENT_USER cu

HKEY_CLASSES_ROOT cr

HKEY_USERS us

-kSearch keynames (Note: You must specify either -k -v or -d, and you may

specify any combination of the three.)

-vSearch value names

-dSearch data

-cSearch case sensitive (default: not case sensitive)

-eReturns only an exact match (default: returns all matches)

-nDisables use of color in output (default: keys red, values green, data

yellow)

Examples

Valid examples of Scanreg usage include:

SCANREG -sWindows -k
SCANREG -s:Windows -v
SCANREG -s=Windows -kvc
SCANREG -s Windows -k -ve
SCANREG -s Windows -k -v -dn
SCANREG -s Windows -kvd
SCANREG /s Windows -kvd
SCANREG /s Windows -kvd -rlm\
SCANREG /s Windows -kvd -r\software\
SCANREG /s Windows -kvd -r\\HOTDOG\lm\system
SCANREG /s Windows -kvd -
r\\HOTDOG\HKEY_LOCAL_MACHINE\system
SCANREG Windows \lm -kvd
SCANREG Windows -kvd
SCANREG Windows HKEY_CURRENT_USER\software -kvd

For questions or feedback concerning this utility, please contact rkinput@microsoft.com.


ShowACLs

ShowACLs is a 32bit command line utility that displays the NTFS permissions of files and directories. The most useful feature of ShowACLs is the ability to show permissions for a particular user. The method that ShowACLs users to perform this is by enumerating the local and global groups that the particular user belongs to and matching the users Security Identifier (SID) and the SID’s of the groups the users belongs to, to the SID’s in each ACE entry.

NTFS uses Access Control Lists (ACLs) to set permissions for users and groups on objects. ACLs are made up of Access Control Entries (ACE’s). Each ACE entry has information that controls the permissions for a specific user or group. There are currently four ACE type defined; Access Allowed, Access Denied, System Alarm and System Audit. Each ACE entry has a common ACE header and unique data structure. The SID associated with each ACE entry is contained in the data following the ACE header.

One of the problems with a command line tool like ShowACLs is the amount of information that is contained in the ACL. The first version of ShowACLs attempted to display all the data in the access mask, which was very confusing. The latest version has adopted the “standard” permissions, Full, Change and Read-Only where appropriate. If a mask does not match these predefined values, the a raw dump of the mask is performed. The following table shows the actual permissions for each of the predefined values, and the alpha keys for permissions that do not match one of these predefined values. See winnt.h in the include directory of the SDK or Visual C++ for more details on these definitions.

FullFILE_ALL_ACCESS

ChangeDELETE | SYNCHRONIZE | FILE_READ_DATA | FILE_WRITE_DATA | FILE_APPEND_DATA | FILE_READ_EA | FILE_WRITE_EA | FILE_EXECUTE | FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES | READ_CONTROL

Read-OnlyFILE_READ_DATA | SYNCHRONIZE | FILE_READ_EA | FILE_EXECUTE | READ_CONTROL | FILE_READ_ATTRIBUTES

RGENERIC_READ

WGENERIC_WRITE

XGENERIC_EXECUTE )

DDELETE

AGENERIC_ALL

dFILE_READ_DATA (directory)

lFILE_READ_DATA (file)

sSYNCHRONIZE

rFILE_READ_DATA

wFILE_WRITE_DATA

aFILE_APPEND_DATA

rEFILE_READ_EA

wEFILE_WRITE_EA

fxFILE_EXECUTE

Usage:

Showacls /s /u:domain\user filespec


SRVANY.EXE

Windows NT® Resource Kits

Copyright © Microsoft Corp. 1995 - 1997

Contents

Introduction

Notices

Installation

Specifying the application to start & its parameters

Starting & stopping the service

De-installation

Programming Considerations

Comments/limitations

Introduction

This file describes the SRVANY.EXE utility. This utility allows running Windows NT™ applications as services. The benefits include:

- allow apps to survive logoff/logon sequences, hence saving the overhead of re-starting them for each new user

- allow server apps to come-up and service requests even when no user is logged-on

- allow apps to run and perform a task in a specific logon account, different from the currently logged-on user

Notices

1. Some applications may terminate upon logoff, even though they were started as a service, if they don't ignore the WM_ENDSESSION message (or CTRL_LOGOFF_EVENT). See "Programming Considerations" below for more details.

2. When using SRVANY.EXE with Presentation Manager® applications, special configuration instructions apply - please read the README.WRI file shipped on Disk#1 of the Windows NT™ Add-On Subsystem for Presentation Manager®, version 3.51 (a Microsoft add-on product which allows running 16-bit Presentation Manager® 1.x applications in addition to the OS/2 character-mode applications supported by the Windows NT™ OS/2 Subsystem).

Installation

-> Copy SRVANY.EXE to your system and install it as a Windows NT™ service, for example:

INSTSRV MyService c:\tools\srvany.exe

-> configure via the Services applet ("Startup..." dialog) of the Control Panel as manual or automatic, as appropriate.

-> set via the Services applet ("Startup..." dialog) of the Control Panel the account for the service. If you need access to the screen & keyboard, you must choose the LocalSystem account and click the "Allow Service to Interact with Desktop", otherwise choose any account and specify the correct logon password. Note that the LocalSystem account doesn't have network access.

Specifying the application to start & its parameters

Run the Registry Editor (REGEDT32.EXE):

-> under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MyService: create a 'Parameters' key

-> under the above key, create an 'Application' value of type REG_SZ and specify there the full path of your app executable (including the extension). For example:

Application: REG_SZ: D:\TOOLS\VI.EXE

-> OPTIONAL: under the above key, create an 'AppParameters' value of type REG_SZ and specify the parameters for your app. For Example:

AppParameters: REG_SZ: C:\TMP\FOO

-> OPTIONAL: under the above key, create an 'AppDirectory' value of type REG_SZ and specify the current directory to use for the app, eg:

AppDirectory: REG_SZ: C:\TMP

The case of all above strings is not important.

There is also another way to specify the service parameters, via the Control Panel. Note that this method applies only to the case where the service is configured to be started manually (i.e. not when it is started automatically with the system):

2. Via the Control Panel, Services applet:

-> type in the Startup Parameters box the full command-line, incl. the app name. Example:

D:\\BINP\\B.EXE C:\\TMP\\FOO

(note the '\\' is needed to result in '\')

-> if you want to specify the current working directory, use the '/D' switch before the app name, eg:

/D C:\\TMP D:\\TOOLS\\VI.EXE C:\\TMP\\FOO

NOTICE: Specifying the target application via the Control Panel is usually inconvenient because the parameters have to be typed every time the service is started. However, this may be convenient in cases where the target application is different every time the service is started.

Starting & stopping the service

Start:

If the service is configured as 'Automatic', the user doesn't need to start it explicitely: it is started automatically every time when the system is re-booted.

For 'manual' services, the user may start services in several ways:

- from the Services applet of the Control Panel

or

- using the SC.EXE utility, eg: SC start MyService

or

- NET START MyService

Stop:

When you stop the service, it will terminate the application it had started. The way to stop the service is (as described above for starting):

- from the Services applet of the Control Panel

or

- using the SC.EXE utility, eg: SC stop MyService

or

- NET STOP MyService

WARNING:

When the service is stopped, it terminates the application via the WIN32 TerminateProcess() API: this is a drastic way to end an application. For example, it would not allow the application to prompt the user to save changes. Therefore, it is recommended to close the application BEFORE stopping the service.

De-installation

If you want to prevent an instance of the SRVANY utility from running until further notice, you should configure it via the Services applet ("Startup..." dialog) of the Control Panel as 'Disabled' (rather than 'manual' or 'automatic').

If you want to remove an instance of the SRVANY utility permanently:

-> If the service is running, stop it (see "Starting and stopping the service" above)

-> Run:

INSTSRV MyService remove

NOTICE: this procedure removes only one specific instance of SRVANY. Therefore, it is possible that SRVANY.EXE is still being used to start other applications as services.

Programming Considerations

For WIN32 graphical applications: when the currently logged-in user is logging-off, all WIN32 top-level windows receive WM_QUERYENDSESSION and WM_ENDSESSION messages. Some WIN32 applications choose to terminate upon receipt of such messages. In order for your WIN32 application to survive logoff, it must not do that: instead, your windows procedure should call the default windows procedure on these messages.

For WIN32 Console (i.e. character-mode) applications: when the currently logged-in user is logging-off, all Console applications receive a CTRL_LOGOFF_EVENT event from the Console.

If your Console application has registered a Console event handler (via SetConsoleCtrlHandler), it must ignore CTRL_LOGOFF_EVENT in order to survive the logoff.

Comments/limitations

-> You may install SRVANY.EXE several times with different registry parameters (i.e. running different target applications) - just use a distinct service name for each instance (e.g. MyService1, MyService2 etc.)

-> If SRVANY.EXE fails to start your application, try specifying as current directory the directory where your application is installed (see 'AppDirectory' registry key or '/D' above). SRVANY.EXE may be running under an account different than the currently logged-on user therefore environment variables may be set differently: as a result, for example, the system might have been unable to find a DLL required for your application and running it from the application's directory might help.

-> Due to a restriction enforced by Windows NT™ on services, the application can either be interactive (have a Console, read keyboard input etc.) or have network access (not both at the same time).

This limitation is less problematic than it would appear at first glance. Here is why:

If you know which servers your interactive service application needs to access, it is possible to configure these servers (or selected shares on them) to allow your service (running under the LocalSystem account) to access these servers.

a.To allow LocalSystem services on any machine in the domain to access a specific share on a server, use the Registry Editor to add the name of that share to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionShares

If named pipes on that server also need to be accessed by LocalSystem services, add them to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes

b.To allow ALL shares & pipes on the server to be accessed by LocalSystem services, add a value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\RestrictNullSessAccess, type DWORD, set to value 0

WARNING: method b) effectively allows everyone in the domain to access that server - make sure this is acceptable for you.


WINS Consistency Check Tool -- Winschk.exe

WINS Consistency Check Tool
Winschk.exe

Windows NT® Resource Kits

Contents

Introduction

Options

Introduction

Winschk is a command-line utility that checks for name and version number inconsistencies in WINS (Windows Internet Name Service) databases, monitors replication activity, and verifies replication configuration.

WINS is a service that maps computer names to IP (Internet Protocol) addresses, allowing users to communicate with other computers on a network or the World Wide Web without having to remember addresses in the form of strings of numbers.

Winschk has no switches: when run at the command prompt, it displays the following options:

0Enables or disables interactive mode

1Tests for names on WINS servers

2Checks for version number consistencies

3Monitors WINS servers and detects communication failures

4Verifies replication configuration

99Exits Winschk

These options are described in more detail below.

Options

0 - Enabling or disabling interactive mode

Allows the user to enable or disable interactive mode. In interactive mode, status messages are displayed in the command-prompt window and recorded in Winstst.log. The first time you run Winschk, interactive mode is enabled by default.

1 - Testing names on WINS servers

This option allows you to check quickly for consistency between WINS servers. This functionality is driven by two flat files, Names.txt and Servers.txt, which you can edit by using a text editor.

Servers.txt contains the IP address of a source WINS server from which a list of all the replicating WINS servers is built up to query.

Names.txt can contain multiple NetBIOS names (one per line) which need to be checked. The format of names in this file is:

name*16th_byte

for example, FOOBAR*20

Note

The names included in Names.txt must be specified in uppercase characters.

Winschk queries each WINS server with the list of NetBIOS names. It checks for consistency of IP addresses and reports any mismatched IP addresses or occurrences of "name not found". It also reports non-responsive WINS servers.

2 - Checking for version number inconsistencies

Using an RPC (remote procedure call) function, Winschk gets the owner address to version number mapping tables from different WINS servers and checks the consistency of their databases by ensuring that a WINS server always has the highest version number among the network of WINS servers for records it owns.

In the following matrix, each record is a mapping table retrieved from a particular WINS server (the order of WINS servers being the same along both dimensions of the matrix), each diagonal element should have the highest version number among all the numbers in its column.

ABCList of owners

A1008079Mapping table retrieved from A

B9575*65Mapping table retrieved from B

C7845110Mapping table retrieved from C

In this example, the intersection B with B indicates a problem that needs to be addressed.

3 - Monitoring WINS servers and detecting communication failures between WINS servers

This option monitors WINS servers periodically to ensure that both the primary and backup WINS servers are not down at the same time. Winschk records WINS server activity in Monitor.log, and alerts the administrator to any situation that needs to be addressed.

This option also periodically retrieves statistics from the WINS server, for example once every hour, to ensure that replication is not failing consistently. Communication problems might be due to a WINS server being disconnected or being down.

You can run Winschk with this option as a one-time or a continuous version. The continuous version runs every 3 hours by default. You should not run this option too frequently to avoid excessive network activity.

4 - Verifying replication configuration

Checks the Registry of a WINS server to ensure that each replication partner is configured as both pull and push and that a pull interval is defined. In this way, WINS database changes are replicated for the entire network. If Winschk detects an asymmetric partner relationship, it flags it for the administrator.

99 - Exits the tool


USING PPTP

Point-to-Point Tunneling Protocol (PPTP) is a network protocol that enables the secure transfer of data from a remote client to a private enterprise server, thus creating a virtual private network (VPN) by using TCP/IP-based data networks. PPTP supports multiple network protocols (IP, IPX, and NetBEUI) and can be used for virtual private networking over public and private networks. You can use PPTP to provide secure, on-demand, virtual networks by using dial-up lines, local area networks (LANs), wide area networks (WANs), or the Internet and other public, TCP/IP-based networks.

This white paper provides information on how to install, configure, and use PPTP on computers running the Windows NT Workstation version 4.0, Windows NT® Server version 4.0, and Windows® 95 operating systems. The main topics of this document are:

· Planning For PPTP Installation And Configuration

· What You Must Know Before Installing PPTP

· Installing And Configuring A PPTP Server

· Installing And Configuring A PPTP Client

· Using PPTP To Dial Up An ISP And Connect To A PPTP Server

· Using The Point-To-Point Protocol (PPP) To Connect To A PPTP Server By Using A PPTP Service Provided By An ISP

· Using PPTP Over The LAN To Connect To A PPTP Server

Note This document provides information about how to install, configure, and use PPTP on computers running Windows NT Server version 4.0, Windows NT Workstation version 4.0, and Windows 95. If you need information about the architecture, components, and features of PPTP, see Chapter 2 titled “Understanding PPTP.”


Planning for PPTP and Virtual Private Networks

A virtual private network (VPN) can be defined as an on-demand connection between two computers in different locations. The VPN consists of the two computers (one computer at each end of the connection) and a route, or tunnel, over the public or private network. To ensure privacy and secure communication, data transmitted between the two computers is encrypted by the Point-to Point Protocol (PPP) (a remote access protocol) and then routed over a previously established dial-up or LAN connection by a PPTP device. In Windows NT and Windows 95 terminology, this device is referred to as a virtual private network or VPN.

PPTP uses the VPN device to establish and maintain private, secure communication between computers. It does this by using Remote Access Service (RAS) and Dial-Up Networking to communicate over dial-up lines and public and private networks.

You can use PPTP in the following three scenarios:

· In the most common scenario, you can connect your workstation to a remote network by making a Dial-Up Networking connection to an Internet Service Provider (ISP) and then tunneling through the Internet to a PPTP server that is attached to both the Internet and to the remote network. Once you are connected to the PPTP server, you can transparently access any public or private network that is connected to it.

· If you have a permanent IP connection to a PPTP tunnel server, you can use Dial-Up Networking to connect directly to that tunnel server. You can then use that PPTP server to tunnel to any public or private network that is connected to it.

· Some ISPs are introducing a service that automatically tunnels your traffic to a PPTP server on a remote network. If your ISP supports this service, you can use Dial-Up Networking to make a dial-up connection to the ISP’s PPTP tunnel server. You can then use that tunnel server to tunnel to any public or private network that is connected to it.


Hardware Requirements


The PPTP Server

The computer that is configured as a PPTP server must have the minimum configuration required to run Window NT Server version 4.0. In addition, two network adapter cards, also referred to as network interface cards (NICs), are required. One adapter is connected to the Internet; the other is connected to the private enterprise network.

One of the primary advantages of PPTP is that it reduces or eliminates the need for dedicated, telecommunications equipment to support remote and mobile users who need to connect to the enterprise network. PPTP enables secure use of public or outsourced telecommunication networks. This reduces the cost of owning and maintaining dedicated, telecommunications equipment.


The PPTP Client

A PPTP client can be a computer configured with either Windows NT Workstation version 4.0, Windows NT Server version 4.0, or Windows 95. The minimum hardware configuration for a PPTP client depends on which operating system is being used.

If the PPTP client is a remote or mobile enterprise user that connects to an enterprise PPTP server by using dial-up lines over the Internet, additional hardware is required, such as an analog modem or Integrated Service Digital Network (ISDN) device and a device for telephone access (for example, a telephone wall jack.)

If the PPTP client is connecting over the LAN to a PPTP server, the additional hardware required is the network adapter that is physically wired to the LAN network.


Network Protocols on the Private Enterprise Network

PPTP enables you to use virtual private networking over public TCP/IP networks and retain existing network protocols, network node addresses, and naming schemes on the private enterprise network. Thus, no changes to existing network configurations and to network-based applications are required when using PPTP to tunnel across the Internet or other TCP/IP-based public networks. For example, IPX or NetBEUI clients can continue to run applications on the private network that require these protocols.

Name resolution methods used on the private network—such as Windows Internet Naming Service (WINS) for NetBIOS computers, Domain Name System (DNS) for TCP/IP host names, and Service Advertisement Protocol (SAP) for IPX networking—do not need to be changed. In addition, IP addresses that are not valid on the Internet can be used on the private network.

Note, however, that the address and name resolution schemes on the private enterprise network must be correctly configured. If they are not, PPTP clients are unable to communicate with computers on the private network.


Before Installing PPTP

Before you begin installing PPTP, it is important that you understand the following points:

· PPTP uses Microsoft’s implementation of RAS and the Point-to-Point Protocol (PPP) to establish connections with remote computers by using dial-up lines, Ethernet networks, or token ring networks. PPP provides remote-user authentication and data encryption between the PPTP client and the PPTP server. Thus, to use PPTP you must install and configure RAS with Dial-Up Networking on both PPTP clients and PPTP servers.

· Because PPTP requires RAS and the PPP protocol, you must establish a PPP account with your ISP to use PPTP over an ISP connection to the Internet.

· PPTP uses virtual devices called VPNs. When you configure PPTP, you install and configure VPNs in RAS as if they were physical devices, just like modems.

· PPTP is installed and configured on PPTP clients and PPTP servers only. Computers on the route between the PPTP client and PPTP server do not require PPTP installation.

· A PPTP server can be placed behind a firewall on the private enterprise network to ensure that traffic in and out of the private network over the PPTP server is secured by the firewall computer. (For more information, see the document “Understanding PPTP.”)

· To ensure enterprise network security, PPTP clients must be authenticated (just like any other remote user using RAS and Dial-Up Networking) in order to connect to the private enterprise network.

· Using the Internet to establish a connection between a PPTP client and a PPTP server means that the PPTP server must have a valid, Internet-sanctioned IP address. However, the encapsulated IPX, NetBEUI, or TCP/IP packets sent between the PPTP client and the PPTP server can be addressed to computers on the private enterprise network using private network addressing or naming schemes. The PPTP server disassembles the PPTP packet from the PPTP client and forwards the packet to the correct computer on the private network.


Installing and Configuring PPTP on a PPTP Server

PPTP is installed on a Windows NT-based server as a network protocol by using the Protocols tab in the Network option of Control Panel. You can add, configure, and remove PPTP by using the Protocols tab.

This section explains how to install and configure the PPTP protocol on a PPTP server and assumes the following:

· Windows NT Server version 4.0 is installed.

· One or more network adapters are installed. In most cases, two or more network adapters are required: one to connect to the Internet and one or more to connect to enterprise networks.

· TCP/IP is installed and bound to the network adapter connected to the private enterprise network, and the adapter is connected to the Internet.

· The network protocol used on the private enterprise network, (TCP/IP, NetBEUI, or IPX) is installed and bound to the adapter(s) connected to the private enterprise network.

· The PPTP server is configured with a static IP address.

· RAS, with Dial-Up Networking, is installed and configured.

· You know how many simultaneous connections with remote PPTP clients you want the PPTP server to support, so that you can configure the correct number of VPN devices.

· Configuring a computer running Windows NT Server version 4.0 as a PPTP server involves three major procedures:

· Installing PPTP and then selecting the number of VPN devices

· Adding the VPN devices as RAS ports and devices

· Configuring encryption and authentication options


Installing PPTP on a PPTP Server

To install the PPTP protocol on a computer running Windows NT Server version 4.0

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network in Control Panel.

3. Click the Protocols tab, and then click Add to display the Select Network Protocol dialog box. The Select Network Protocol dialog box is illustrated in the following figure.

Figure 1 - Selecting the PPTP network protocol

4. Select Point To Point Tunneling Protocol and click OK.

5. Type the drive and directory location of your Windows NT Server version 4.0 installation files in the Windows NT Setup dialog box, and then click Continue. The PPTP files are copied from the installation directory, and the PPTP Configuration dialog box appears, as shown in the following figure.

Figure 2 - Configuring the number of VPN devices for the PPTP server

6. Click the Number of Virtual Private Networks drop-down arrow to select the number of simultaneous VPNs you want the server to support. You can select a number between 1 and 256. Typically, multiple VPNs are installed on a PPTP server to enable multiple clients to connect simultaneously to the PPTP server. The server can be configured to support a maximum number of 256 simultaneous VPN connections.

7. Click OK, and then click OK again in the Setup Message dialog box.

8. In the Remote Access Setup dialog box you can do either of the following:
a) Temporarily stop installation of PPTP by clicking Cancel, closing Network, and shutting down and restarting the computer. Note that you must perform the procedure described in the following section “Adding VPN Devices as RAS Ports on a PPTP Server” to complete installation of PPTP.
b) Continue installation of PPTP by clicking Add to add the VPN devices installed with PPTP to RAS. (See step 5 of the following procedure.)


Adding VPN Devices as RAS Ports on a PPTP Server

After installing PPTP, you must add the VPN devices to RAS. Follow these steps to add VPN devices on a computer running Windows NT Server version 4.0.

To configure VPN devices on the PPTP server

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Network in Control Panel.

3. Click the Services tab and select Remote Access Service.

4. Click Properties to display the Remote Access Setup dialog box.

5. Click Add. The Add RAS Device dialog box appears, as shown in the following figure.

Figure 3 - Adding the VPN devices to RAS on the PPTP server

6. Click the RAS Capable Devices list arrow to display VPN devices that must be added and configured as a port and device in RAS.

7. Select a VPN device and click OK. Repeat steps 5, 6, and 7 until all the VPNs are added to the Remote Access Setup dialog box.

8. Select a VPN port and click Configure. Verify that the Receive calls only option in the Port Usage dialog box is selected and then click OK to return to the Remote Access Setup dialog box. (If you also use this server as a PPTP client and want to use this VPN device to dial out as a PPTP device, select Dial-out.)

9. Repeat the last step for each VPN device that is displayed in the Remote Access Setup dialog box. (By default, VPN devices on a computer running Windows NT Server version 4.0 are automatically configured with the Receive calls only option, but you should verify this configuration.)

10. Click Network to display the Network Configuration dialog box. Verify that only TCP/IP is checked in the Server Settings box in the Network Configuration dialog box. Click OK to return to the Remote Access Setup dialog box.

11. Click Continue.

12. Close Network, shut down, and then restart the computer.


Configuring PPTP Server Encryption and Authentication Options

This section provides procedures and information about configuring a PPTP server. This involves three steps:

· Encrypting data sent over the Internet

· Accepting only PPTP packets from the Internet

· Accessing a private network


Configuring Server Encryption for PPTP

The encryption of data is performed by the remote access protocol, PPP. You enable encryption by configuring each VPN device that was added and configured in RAS. This configuration is identical to configuring encryption for other RAS devices, such as a modem.

To enable encryption on a VPN device on the PPTP server

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Network in Control Panel.

3. Click the Services tab and select Remote Access Service.

4. Click Properties to display the Remote Access Setup dialog box (shown below).

Figure 4 - Selecting a VPN device for encryption on the PPTP server

5. Select a VPN device for which you want to enable encryption, and then click Network. The Network Configuration dialog box appears.

Figure 5 - Configuring the VPN device with encryption on the PPTP server

6. Select Require Microsoft encrypted authentication and Require data encryption. This configures RAS and PPP to enforce Windows NT-based authentication of all remote clients connecting to the PPTP server.

7. Click OK to return to the Remote Access Setup dialog box.

8. Click Continue.

9. Close Network, shut down, and then restart the computer.


Configuring PPTP Filtering on the PPTP Server

Enabling PPTP filtering provides a form of security for your private network by configuring an adapter on the computer to block all packets except PPTP packets. In a multi-homed computer, such as a PPTP server with one adapter connected to the enterprise network and another adapter connected to the Internet, PPTP filtering should be enabled on the adapter over which the PPTP connection is being made.

In other words, if remote or mobile users connect to the enterprise network by using the PPTP server and the Internet, PPTP filtering should be enabled on the server adapter that is connected to the Internet. PPTP filtering in this case is enabled by configuring TCP/IP settings for the adapter that is connected to the Internet.

Note When PPTP filtering is enabled, all other network packets are ignored. Thus, packets from TCP/IP utilities such as ping and tracert are not accepted by the adapter on which PPTP filtering is enabled. This provides security, but it also means it can be difficult to troubleshoot possible problems on the PPTP server by using the TCP/IP troubleshooting utilities.

To enable PPTP filtering on an adapter in the PPTP server

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Network in Control Panel.

3. Click the Protocols tab, select TCP/IP Protocol, and then click Properties.

4. Click the IP Address tab, and then click Advanced.

5. Click the Adapter drop-down arrow and select the adapter connected to the Internet. Click Enable PPTP Filtering, as shown in the following dialog box. Note that filtering is enabled only on network adapters. Filtering cannot be enabled on modems or ISDN devices.

Figure 6 - Enabling PPTP Filtering on the PPTP server

6. Click OK, click OK again, and then close Network.

7. Shut down and then restart the computer.


Configuring LAN Routing on the PPTP Server

RAS must be configured to access your private network using the appropriate network protocols in order to enable the PPTP server to forward a packet from a PPTP client to the correct destination computer. For more information about general RAS server configuration (for example, using TCP/IP, IPX, or NetBEUI), see Rassetup.hlp in the \Systemroot\System32 directory.

Once RAS is configured to access the private network, a PPTP server requires the following configuration:

· The TCP/IP protocol must be configured to enable IP forwarding.

· The default route on the private network (intranet) must be suppressed by adding a Registry entry.

· You must prevent RAS from changing source IP addresses of incoming packets.

· Static routes to the private network must be established.


Enable IP Forwarding

You must enable IP forwarding on the PPTP server.

To enable IP forwarding

1. Click Start, point to Settings, and then click Control Panel.

2. Double-click Network in Control Panel.

3. Click the Protocols tab, select TCP/IP, and then click Properties.

4. Click the Routing tab, and then click Enable IP Forwarding.

5. Click OK, click OK again, and then close Network.


Adding the DontAddDefaultGateway Registry Entry

By default, Windows NT Server and Windows NT Workstation both place a default route (0.0.0.0) on each network adapter in a computer. This causes the server to send packets of unknown IP addresses to the network adapter configured with the default route. This is the normal and desired action of a router.

However, you must change this default setting if a server is connected to a private network (intranet) and the Internet. You must disable the automatic addition of a default route on the network adapter for the private network. You do this on the PPTP server by adding the DontAddDefaultGateway Registry entry with a value of REG_DWORD 0x1 in the following Registry location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \network adapter\Parameters\Tcpip\DontAddDefaultGateway

This entry prevents the default route from being added to PPTP server’s network adapter. Use a Registry editor to add this entry, and then shut down and restart the computer.

After the DontAddDefaultGateway entry is created you must add static routes for the network adapter. These static routes must configure the PPTP server to route incoming data from the Internet to the correct server on the private network. This procedure is explained below.


Preventing RAS from Changing Source IP Addresses

By default, RAS changes the source IP address of packets it routes, from the IP address of the client sending the packets to its own source IP address.

You must disable this functionality in order for LAN-to-LAN routing to function. You do this on the PPTP server by adding the DisableOtherSrcPackets Registry entry with a value of REG_DWORD 0

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \RasArp\Parameters

This entry prevents the RAS server from changing the source address of packets it forwards.


Adding Static Routes for the Private Network

You add static routes to your private network on the PPTP server by using the route command at the command prompt. The static entries can be added by using a .bat file that contains the routes or by using the route command with the -p (persistent) option.

The route command causes all subnets and computers on the private network to be known to the PPTP server. Without the necessary route commands, the PPTP server would broadcast for every address required by PPTP clients.

To add the static routes to the PPTP server, run route with the -p option at the command prompt, as shown in the following example:

C:\>route -p 172.16.48.10

The route command must identify all the computers or networks you want PPTP clients to reach.

For more information about LAN-to-LAN routing using RAS, consult the Windows NT Server version 4.0 Networking Supplement, Chapter 4, “Routing in Windows NT,” or the Microsoft Knowledge Base article Q121877, available at www.microsoft.com.


Installing and Configuring PPTP on a Windows NT-based Client

The procedures in this section assume the following:

· Windows NT Workstation version 4.0 or Windows NT Server version 4.0 is installed.

· TCP/IP is installed on the computer.

· RAS with Dial-up Networking is installed on the computer.

· An analog modem, ISDN device, or other modem device is installed and configured in RAS to enable you to make a dial-out connection from the computer.

· If you are using the Internet to connect to the PPTP server, you have a PPP account with your ISP.


Installing PPTP on a Windows NT-based Client

To install the PPTP protocol on a client running Windows NT Workstation version 4.0 or Windows NT Server version 4.0

1. Click Start, point to Settings, and then click Control Panel.

2. In Control Panel, double-click Network.

3. Click the Protocols tab, and then click Add to display the Select Network Protocol dialog box, shown in the following figure.

Figure 7 - Selecting the PPTP network protocol on the PPTP client

4. Select Point To Point Tunneling Protocol and click OK.

5. Type the drive and directory location of your installation files in the Windows NT Setup dialog box, and then click Continue.

The PPTP files are copied from the installation directory and the PPTP Configuration dialog box appears, as shown in the following figure.

Figure 8 - Adding a VPN device on the PPTP client

1. Click the Number of Virtual Private Networks drop-down arrow and select the number of VPN devices you want the client to support. You can select a number between 1 and 256 for computers running Windows NT Workstation version 4.0 or Windows NT Server version 4.0. Typically, only one VPN is installed on a PPTP client.

Note If the PPTP client is an ISP server running Windows NT Server version 4.0, you can select multiple VNP devices as needed to simultaneously support the PPP clients using the ISP server to connect to a PPTP server. Windows NT Server version 4.0 supports a maximum number of 256 VPN devices.

2. Click OK, and then click OK in the Setup Message dialog box.

3. In the Remote Access Setup dialog box, you can do either of the following:
a) Temporarily stop installation of PPTP by clicking Cancel, closing Network, and then shutting down and restarting the computer. Note that you must perform the procedure described in the following section “Adding a VPN Device as a RAS Port on the PPTP Client” to complete installation of PPTP.
b) Continue installation by clicking Add to add to RAS the VPN device installed with PPTP. (See step 5 of the procedure described in the following section.)


Adding a VPN Device as a RAS Port on the PPTP Client

You must add the VPN device to RAS after installing PPTP. Follow these steps to add a VPN device on a computer running Windows NT Workstation version 4.0.

To configure a VPN device on the PPTP client

1. Click Start, point to Settings, and then click Control Panel.

2. In Control Panel, double-click Network.

3. Click the Services tab and select Remote Access Service.

4. Click Properties to display the Remote Access Setup dialog box.

5. Click Add. The Add RAS Device dialog box is illustrated in the following figure.

Figure 9 - Adding the VPN to RAS on a PPTP client

6. Click the RAS Capable Devices list to display the VPN devices that must be added and configured as a port and device in RAS.

7. Select the VPN1 - RASPPTPM device, and then click OK. (If you installed PPTP with more than one VPN device, repeat steps 5, 6, and 7 until all the VPNs are added to the Remote Access Setup dialog box.)

8. By default, the VPN device on a computer running Windows NT Workstation version 4.0 is configured to dial out only. Select the VPN port and click Configure. Verify that the Dial out only option in the Port Usage dialog box is the only option selected, and then click OK. This returns you to the Remote Access Setup dialog box.

9. Click Network to display the Network Configuration dialog box.

10. Verify that the TCP/IP option in Dial out Protocols is the only option checked, and then click OK.

11. Click Continue.

12. Close Network, shut down, and then restart the computer.


Configuring Dial-Up Networking on the Windows NT-based PPTP Client

PPTP is most commonly used for enabling secure and encrypted communications to private enterprise networks via the Internet. In this scenario, the PPTP client must have two phonebook entries: one to connect to the Internet via an ISP and one to connect to a PPTP server on the target network.

However, if you are using PPTP to connect to a PPTP tunnel server on your LAN, you only need to have one phonebook entry: the PPTP server phonebook entry.

The following procedures describe how to use Dial-Up Networking to create phonebook entries for the ISP and the PPTP server.


Creating the Phonebook Entry to Dial an ISP

If you are using PPTP and Dial-Up Networking to connect to a PPTP server over the Internet, you need to create a phonebook entry for your ISP.

Note You do not need to create a phonebook entry for your ISP if you are using a LAN connection to dial up a PPTP server on the LAN.

Before starting the following procedures, make sure you have:

· Installed all network protocols used on the private network to which you want to connect.

· Configured RAS to dial out using those network protocols.

To create a new ISP entry by using the Phonebook wizard

Click Start, point to Programs, point to Accessories, and then click Dial-Up Networking. (If this is the first phonebook entry you are creating, the Dial-Up Networking dialog box appears. Click OK.)

1. Type a name for your phonebook entry, such as the name of your ISP, in the Name the new phonebook entry box, and then click Next.

2. Click I am calling the Internet and click Next. This configures the phonebook entry to use TCP/IP and PPP as the Dial-Up Networking protocols.

3. Select your modem device in the Select the modem or adapter this entry will use box, and then click Next.

4. Type the ISP's phone number in the Phone number box. Click Use Telephony dialing properties if you need to add an area code or other prefix. Click Alternatives if you have an alternative phone number for your ISP.

5. Click Next, and then click Finish.

6. Verify the phonebook entry by using the following procedure.

To verify or edit your ISP phonebook entry

1. Click More in Dial-Up Networking, and then click Edit entry and modem properties to verify that your ISP phonebook entry is correctly configured. The Edit Phonebook Entry dialog box is illustrated in the following figure.

Figure 10 - Example phonebook entry used to dial up an ISP

2. Review the information on the Basic tab to ensure that the phone number is correct and that the correct modem or ISDN device is selected. Make any necessary changes.

3. Click the Server tab. The Server tab is illustrated in the following figure.

Figure 11 - Verifying the dial-up server properties

4. Review the information on the Server tab to ensure that the Dial-up server type displays “PPP: Windows NT, Windows 95 Plus, Internet.”

5. In the Network protocols box, ensure that TCP/IP is selected.

6. Click TCP/IP Settings to display the PPP TCP/IP Settings dialog box. Ensure that the TCP/IP settings conform to the IP address and name server information specified by your ISP.

7. By default, the options Enable software compression and Enable PPP LCP extensions are selected. These settings are compatible with most ISP services. Check with your ISP before changing these default settings.

8. Click the Script tab, and then select None. The PPP protocol provided in RAS is designed to automate remote logon. If your ISP requires a manual logon, consult your ISP for the correct configuration.

9. Click the Security tab. Click Accept only Microsoft encrypted authentication. The configures PPP to encrypt the user name and password for remote logon to a server that enforces Windows NT authentication.

10. Click OK, and then click Close to complete the ISP phonebook entry.


Creating the Phonebook Entry to Dial a PPTP Server

You must create a phonebook entry to connect to your PPTP server by using a VPN device.

Note You do not need to create a phonebook entry for your PPTP server if your computer is not PPTP-enabled and you are using a PPTP service provided by your ISP.

Before starting the following procedures you must have:

· Installed all network protocols (IP, IPX, NetBEUI) used on the private network to which you want to connect.

· Configured RAS to dial out using the network protocols (IP, IPX, NetBEUI) used on the private network.

To create an phonebook entry to dial-up a PPTP server by using a VPN device

1. Click Start, point to Programs, point to Accessories, and then click Dial-Up Networking. (If this is the first phonebook entry, a Dial-Up Networking dialog box appears. Click OK.)

2. Type the name of your PPTP server in Name the new phonebook entry, and click Next.

3. Click I am calling the Internet and click Next. This configures the phonebook entry to use TCP/IP and PPP as the Dial-Up Networking protocols.

4. Select RASPPTPM(VPN1) in the Select the modem or adapter this entry will use box, and then click Next.

5. Type the IP address of the adapter on the PPTP server that is connected to the Internet in the Phone Number box.

Note If your PPTP server has an Internet registered DNS name, you could alternatively enter its DNS name in this field.

1. Click Next, and then click Finish.

2. Verify the phonebook entry by using the following procedure.

Note If you are configuring the VPN device on an ISP server running Windows NT Server version 4.0 that is configured with multiple VPN devices, repeat this procedure for each VPN device.

To verify or edit your phonebook entry for the PPTP server

1. Click More in Dial-Up Networking, and then click Edit entry and modem properties to verify that your PPTP server phonebook entry is correctly configured. The Edit Phonebook Entry dialog box appears, as illustrated in the following figure.

Figure 12 - Example phonebook entry for PPTP server and a VPN device

2. Review the information on the Basic tab to ensure that the phone number is correct and that the RASPPTPM(VPN1) device is selected. Make any necessary changes.

3. Click the Server tab.

Figure 13 - Verifying the dial-up server configuration on the PPTP client

4. Review the information on the Server tab to ensure that the Dial-up server type displays “PPP: Windows NT, Windows 95 Plus, Internet.”

5. In the Network protocols box, ensure that the network protocols used on your private network are selected. Any selected protocol (TCP/IP, IPX/SPX, NetBEUI) must already be installed on the PPTP client you are configuring. In addition, RAS must be configured to use that protocol to dial out. Note that TCP/IP does not need to be selected unless it is the protocol used on your private network.

6. If you use TCP/IP on your private network, click TCP/IP Settings to display the PPP TCP/IP Settings dialog box. Ensure that the TCP/IP settings conform to the settings required by the RAS configuration on the PPTP server. This includes the Enable software compression and Enable PPP LCP extensions settings

7. Click the Script tab, and then select None. The PPP protocol used in RAS is designed to automate remote logon. If your ISP requires a manual logon, consult your ISP for the correct configuration.

8. Click the Security tab. Click Accept only Microsoft encrypted authentication. The PPP protocol encrypts the user name and password for remote logon. The user name and password used to log on to the current session can be used by selecting Use current username and password. You are prompted by the PPTP server if this box is not selected. Both methods are encrypted and are therefore secure.

Note If you are configuring the VPN device on an ISP server running Windows NT Server version 4.0 that is configured with multiple VPN devices, repeat this procedure for each VPN device.


Installing and Configuring PPTP on a Windows 95-based Client

Virtual Private Networking is provided as a standalone upgrade to Windows 95, entitled “Dial-Up Networking 1.2 Upgrade.” This section explains how to install and configure Virtual Private Networking and assumes the following:

· Windows 95 is installed.

· An analog modem, ISDN device, or other modem device is installed and configured in Dial-Up Networking to enable you to make a dial-out connection from the computer.

· If you are using the Internet to connect to the PPTP server, you have a PPP account with your ISP.

· You have installed all the network protocols used by your ISP and on the private network to which you want to connect.

· You have the Dial-Up Networking upgrade, including the executable file Msdun12.exe.


Installing PPTP on a Windows 95-based Client

To install the PPTP protocol on a client running Windows 95

1. Insert your installation disk and double-click Msdun12.exe.

2. Setup asks if you want to install Microsoft Dial-Up Networking. Click Yes.

3. Setup displays a license agreement. When you have read it, and if you accept its terms, click Yes.

4. Setup copies several files, and then asks if you want to restart your computer. Click Yes.

5. Setup restarts your computer. Depending on your configuration, you may need to log on to your computer.

6. Setup copies more files, including some files from your original Windows 95 installation source. If Setup cannot locate your installation source, it will ask you for your original Windows 95 compact disc or setup disks.

Note Setup may notify you of a version conflict and ask you if you want to keep your original file. If so, click Yes.

7. If you are running Setup for the first time, a dialog box appears, explaining that the DHCP client was unable to obtain an IP address and asking if you want to see future DHCP messages. Click No.

8. Setup restarts your computer. Depending on your configuration, you may need to log on to your computer again. You will then be ready to configure Dial-Up Networking.


Configuring Dial-Up Networking on Windows 95

You can configure two types of connections: a connection to the Internet through your ISP and a tunnel connection to the PPTP server on the target network. Depending on how you will be using PPTP, you may not need to configure both types of connections.

PPTP is most commonly used for enabling secure and encrypted communications to private enterprise networks using a serial (modem) or ISDN connection to the Internet. In this scenario, you must configure both connections: one connection to the Internet through an ISP and one tunnel connection through the Internet to the PPTP server on the target network.

However, if you are using PPTP to connect to a PPTP tunnel server on your LAN, you only need to configure a connection to the tunnel server.

The following procedures describe how to use Dial-Up Networking to configure ISP and PPTP connections.


Creating the Connection to Your ISP

If you are using PPTP and Dial-Up Networking to connect to a PPTP server over the Internet, you need to create a connection for your ISP.

To create a new ISP entry by using the Make New Connection wizard

1. Click Start, point to Programs, point to Accessories, and then click Dial-Up Networking. The Dial-Up Networking window appears.

2. Click Make New Connection. The Make New Connection wizard appears.

3. Click Next. The following screen appears.

4. Type a name for the connection, such as the name of your ISP, in Type a name for the computer you are dialing.

5. Select your modem device in Select a modem, and then click Next. The following screen appears.

Figure 15 – Adding a phone number to the ISP connection

6. Type the ISP phone number in Telephone number.

7. Click Next, and then click Finish. A connection icon is created in the Dial-Up Networking folder, as shown in the following figure.

Figure 16 – Example icon for an ISP connection

8. Verify your connection by using the following procedure.

To verify or edit your ISP connection

1. In My Computer, right-click the connection icon in the Dial-Up Networking folder, and then click Properties to verify that your ISP connection is correctly configured. The following dialog box appears.

Figure 17 – Verifying the basic configuration of the ISP connection

2. Review the information on the General tab to ensure that the phone number is correct and that the correct modem or ISDN device is selected. Make any necessary changes.

3. Click the Server Types tab. The Server Types tab is illustrated in the following figure.

Figure 18 - Verifying the network configuration of the ISP connection

4. Review the information on the Server Types tab to verify that the Type of Dial-Up Server box displays “PPP: Windows 95, Windows NT 3.5, Internet.”

5. In the Advanced options box, clear the Log on to the network checkbox. This option is not necessary for ISP connections, and clearing it will enable you to connect to your ISP more quickly.

Note You do not generally need to change the Enable software compression or Require encrypted password options.

6. In the Allowed network protocols box, ensure that TCP/IP is selected and that the other network protocols are not selected. Canceling the selection of other network protocols will enable you to connect to your ISP more quickly.

7. Click TCP/IP Settings to display the PPP TCP/IP Settings dialog box. Ensure that the TCP/IP settings conform to the settings required by your ISP provider.

Note You do not generally need to change the values on the Scripting tab. However, if your ISP requires a manual logon, you can use a script to automate the process. If you wish to use a script, consult your ISP for the correct configuration.

Also, you do not generally need to change the values on the Multilink tab. Multilink enables you to use two devices (such as modems or ISDN devices) of the same type and speed for a single dial-up link. If you have two such devices and your ISP supports the multilink feature, consult your ISP for the correct configuration.

8. Click OK.


Creating the Connection to a PPTP Server

You must create connection to your PPTP server by using a VPN device.

To create a connection to dial up a PPTP server by using a VPN device

1. Click Start, point to Programs, point to Accessories, and then click Dial-Up Networking. The Dial-Up Networking window appears.

2. Click Make New Connection. The Make New Connection wizard appears, as illustrated in the following figure.

Figure 19 – Creating a connection to a PPTP server

3. Type a connection name, such as the name of your PPTP server, in the Type a name for the computer you are dialing box.

4. Select Microsoft VPN Adapter in the Select a modem box, and then click Next. The following dialog box appears.

Figure 20 – Adding the name of the PPTP server to the connection

5. In the Host name or IP address box, type the name or IP address of the PPTP server that is connected to the Internet.

6. Click Next, and then click Finish. A connection icon is created in the Dial-Up Networking folder, as illustrated in the following figure.

Figure 21 – Example icon for a PPTP server connection

7. Verify the PPTP server connection by using the following procedure.

Note Keep in mind that after you connect to a PPTP server on a remote network, your workstation will be connected to that remote network as if you were physically attached to it. Therefore, you must ensure that your workstation and its applications support the protocols native to that network.

To verify or edit the connection to your PPTP server

1. In My Computer, right-click the PPTP server connection icon in the Dial-Up Networking folder, and then click Properties to verify that your PPTP server connection is correctly configured. The PPTP Server dialog box appears, as illustrated in the following figure.

Figure 22 – Verifying the basic configuration for a PPTP server connection

2. Review the information on the General tab to ensure that the host name or IP address is correct and that Microsoft VPN Adapter is selected. Make any necessary changes.

3. Click the Server Types tab. The Server Types tab is illustrated in the following figure.

Figure 23 – Verifying the network connection for a PPTP server connection

4. In the Advanced options box, make sure the Log on to network checkbox is selected only if the target network requires workstations to log on to a network.

Note Network operating systems such as Microsoft Windows for Workgroups, Microsoft Windows NT and Novell NetWare require you to log on to a network. In contrast, UNIX-based networks generally do not require you to do so. Contact your network administrator for more information.

5. In the Allowed network protocols box, ensure that the network protocols used on the target network are selected. Any selected protocol (TCP/IP, IPX/SPX, or NetBEUI) must already be installed on the client workstation you are configuring. Note that TCP/IP does not need to be selected unless it is the protocol used on your target network.

6. If you use TCP/IP on your private network, click TCP/IP Settings to display the TCP/IP Settings dialog box. Ensure that the TCP/IP settings conform to the settings required for a client on the target network. (The default settings are appropriate for most networks. Contact your network administrator for more information.)

7. Click OK.


Using PPTP to Connect to a PPTP Server by Dialing an ISP

With PPTP, you can connect your workstation to a remote network by tunneling through the Internet to a PPTP server on that network. To do so, you must make two connections. First, you must connect to the Internet through an ISP. Next, you must create a tunnel to the target network. This section explains how to make these connections using Windows NT and Windows 95 -based clients.


Connecting to a PPTP Server Using a Windows NT-based PPTP Client

To connect to a PPTP server using a Windows NT-based PPTP client

1. In My Computer, double-click Dial-up Networking.

2. Click More and select User Preferences. On the Appearance tab, clear the Close on dial checkbox. Click OK.

3. In the Dial-Up Networking dialog box, click the drop-down arrow in the Phonebook entry to dial list to select the entry for your ISP phonebook entry, and then click Dial.

4. After connecting to your ISP, click the drop-down arrow in the Phonebook entry to dial list once more to select the entry for your PPTP server. Click Dial.


Connecting to a PPTP Server Using a Windows 95-based PPTP Client

To connect to the Internet using a Windows 95-based PPTP client

1. In My Computer, double-click Dial-up Networking.

2. Double-click the connection icon that was created for your ISP.

3. In the Connect To dialog box that appears, enter the user name and password required by your ISP, and then click Connect.

4. The resulting connection is illustrated in the following figure.

Figure 24 – Connecting to the Internet through an ISP

To connect to the target network using a tunnel to the PPTP server

1. After connecting to your ISP, click the icon that was created for your PPTP server.

2. Enter the user name and password required for the target network.

3. In the Connect To window, click Connect.

4. You now have two connections, as shown in the following figure.

Figure 25 – Creating a tunnel to the PPTP server


After Connecting to a PPTP Server

After you connect successfully to the PPTP server on the remote network, the ISP routes all traffic sent from your workstation over the Internet to the PPTP server. The PPTP server then routes the traffic to the correct computer on the remote network. Consequently, you will only see computers and servers on the remote network. You will no longer see the Internet unless the remote network itself provides access to the Internet.


Dialing an ISP PPTP Service to Connect to a PPTP Server

Some ISPs are introducing a service that automatically tunnels your traffic to a PPTP server on a remote network. (Your ISP will be able to tell you whether this service is available.)

You can use Dial-Up Networking to make a connection to a PPTP server across the Internet if your ISP provides a PPTP service. You do this by using Dial-Up Networking and your modem or ISDN device to connect to your ISP server. You do not need to define a VPN connection because the ISP server makes the connection to the PPTP server for the PPP client.

Contact your ISP to find out whether they have a PPTP server that provides a PPTP service and, if so, how to connect to that server.


Using PPTP Over the LAN to Connect to a PPTP Server

PPTP clients with a permanent IP connection to a PPTP tunnel server can use PPTP tunneling over that IP connection. For example, suppose that you are in a networked office environment and your network has a PPTP tunnel server. You can then use that PPTP server to tunnel to any private network that is connected to that PPTP server, such as the personnel department’s private network. Thus, you can create a virtual private network by using your direct LAN connection. Data sent from your PPTP client to another computer on the LAN is encrypted and secure because you are using a PPTP server to connect to the remote computer.

In the following scenario, the PPTP client uses Dial-Up Networking over a LAN connection instead of a telephone line. Only one connection to the PPTP server is required.


Connecting To A PPTP Server Using A Windows NT PPTP Client

To connect to a PPTP server over a LAN connection

1. In My Computer, double-click Dial-up Networking.

2. Click More and select User Preferences. On the Appearance tab, clear the Close on dial checkbox, and then click OK.

3. In the Dial-Up Networking dialog box, click the drop-down arrow in the Phonebook entry to dial list to select the entry for your PPTP server.

4. Click Dial.


Connecting To A PPTP Server Using A Windows 95 PPTP Client

To connect to a PPTP server over a LAN connection

1. Click My Computer, and then click Dial-up Networking.

2. Click the icon that you have created for your PPTP server.

3. Enter the user name and password required for the target network.

4. Click Connect.

5. You now have a connection to your PPTP server, as illustrated in the following figure.

Figure 26 – Making a connection to the PPTP tunnel server


After Connecting to a PPTP Server

After you successfully connect to a PPTP server, all traffic from your computer is first routed to your PPTP server, which then forwards your data across the LAN to the remote computer. Your PC will behave is if it were physically connected to the remote network. While the tunnel is open, you will continue to see computers and servers on your immediate LAN subnet. However, you may not be able to see hosts and servers on other subnets on your LAN. Contact your network administrator for more information.


Microsoft® Windows NT® Server Resource Kit

Release Notes

Copyright © Microsoft Corp. 1993 - 1997

This online document may contain important information that is not included in the online Help or the printed documents that are part of the Windows NT Server Resource Kit. In particular, this online document contains information not available in other information sources about setting up the Resource Kit utilities. This document also contains information on changes to the utilities that occurred after publication of the printed documents.

Patches with the most current corrections to the utilities and their documentation, as well as the POSIX and Perl public domain source code files, are available on the Internet at the following Microsoft FTP site: ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt40/.


1.0 Setup for the Resource Kit Software

There is now a Master Setup Program (MSETUP.EXE) that provides an overview Setup screen and an easy way to launch the installation programs for all the different products that ship on the Resource Kit CD, including the main Setup program. This program starts automatically when you insert the Resource Kit CD.

However, if you need to install a separate component at a later time, you can go to the root directory of the Windows NT Server Resource Kit compact disc (CD) and use the MSETUP.EXE file. Those utilities that are not installed by the main Setup program have an installation program in their subdirectory under the \APPS directory.

Important: Notice that many of the utilities will not work unless you are logged on as a member of the Administrators group.

The following is a list of some of the main directories on the Windows NT Server Resource Kit CD. For a list of all the first- and second-level directories on the CD, see Section 5.0, "Directory Structure of the Windows NT Server Resource Kit Supplement 2 CD."

\COMMONWindows NT Server Resource Kit platform-independent support files and

online documentation

\ALPHAWindows NT Server Resource Kit Utilities for Digital Alpha AXPTM RISC-

based computers

\I386Windows NT Server Resource Kit Utilities for x86-based computers

\APPS\CLIENTSClient-based Administration Tools for Windows NT Server

\APPS\CRYSTALCrystal Reports Event Log Viewer

\APPS\DBWEBMicrosoft dbWeb

\APPS\IE301Microsoft Internet Explorer 3.01

\APPS\INDEXWindows NT Index Server

\APPS\RASMGRRemote Access Manager

\APPS\SP3Service Pack 2 for Windows NT 4.0

\APPS\TECHNETMicrosoft TechNet

\APPS\THEMESDesktop Themes for Windows NT 4.0

\APPS\WCATWeb Capacity Analysis Tool

\APPS\WEBADMINWebAdministration of Microsoft Windows NT Server

\SOURCE\GNU\PERLSource code for Perl5 utility

\SOURCE\GNU\POSIXSource code for POSIX utilities

\SOURCE\GNU\REXXSource code for REXX utility

Important: These tools have not been localized: they are written and tested in English only. Using these tools with a different language version of Windows NT Workstation or Windows NT Server may produce unpredictable results.


1.1 Hardware-Platform and Other Issues

The following is a list of issues relating to various Resource Kit utilities that are included in this Supplement 2 release of the Windows NT Server Resource Kit. Most of them refer to utilities that do not work on one hardware platform or another. Hopefully, most of these issues will be resolved by the next release.

· dbWeb - Works only on x86-based computers.

· DiskSave - Works only on x86-based computers.

· NLMonitor - Works only on x86-based computers.

· NLTest - Works only on x86-based computers.

· NTDETECT.COM (INSTALLD.CMD) - Works only on x86-based computers.

· UPTOMP.EXE - Works only on x86-based computers.

· RUNEXT - Works only on x86-based computers.

· TweakUI - Works only on x86-based computers.

· WCAT: Web Capacity Analysis Tool - Works only on x86-based computers.


1.2 General Setup Instructions

To set up the standard Resource Kit utilities:

1. Start Windows NT Server and insert the Windows NT Server Resource Kit Supplement 2 CD in the CD-ROM drive.

The Windows NT Server Resource Kit Setup master setup screen appears. Notice that options that are only available on certain hardware platforms are not highlighted.

2. Click the Install Resource Kit option.

3. Follow the instructions on screen to complete Setup of the standard utilities.

To set up additional items at a later time from the CD or a network sharepoint:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: msetup or network address\msetup.exe and choose the OK button.

The Windows NT Server Resource Kit Setup master setup screen appears. Notice that options that are only available on certain hardware platforms are not highlighted.

3. Click the option that you want to install.

4. Follow the instructions on screen to complete Setup of your selected item.

The Setup program provides two options for setting up the Windows NT Server Resource Kit on your hard disk: Typical Setup and Custom/Complete Setup. Typical Setup installs all the Resource Kit files onto your hard disk and requires a maximum of 52 MB of free space. Custom/Complete Setup, however, enables you to choose specific items and minimize the amount of space used on your hard disk.

Setup creates a Resource Kit 4.0 folder on the Start menu with shortcuts for the installed utilities. For more information about these utilities, choose the Resource Kit Tools Overview (RKTOOLS.HLP) shortcut.

Setup also adds the \NTRESKIT directory (or the directory name you choose for installing the utilities) to the PATH System environment variable. (If you want to change your PATH, you can do so by using the System option in Control Panel after the Resource Kit installation is complete.)

Some Resource Kit utilities require separate or additional setup besides the steps described above. The following sections describe some special setup requirements and how to set up items at a later date. For more information about each of these utilities and others with additional requirements, see the Overview of Windows NT Resource Kit Tools (RKTOOLS.HLP) online Help file.


1.3 Index Server

To set up Index Server:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\index\hardware platform\language filename

or network address\apps\index\hardware platform\language filename and choose the OK button.

For example, type D: \apps\index\i386\idxsveng.exe to obtain the International English version for use on an x86-based computer.

For information on the Index Server installation variables, see the INDEX.TXT file in the

\APPS\INDEX subdirectory.

3. Follow the instructions on screen to complete Setup.


1.4 Desktop Themes for Windows NT 4.0

To set up Desktop Themes for Windows NT 4.0 at a later date:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\themes\setup.exe or network address\apps\themes\setup.exe and choose the OK button.

3. Follow the instructions on screen to complete Setup.

For information about using these desktop themes, see the RKTOOLS.HLP online Help file.


1.5 Web Administration for Microsoft Windows NT Server

To set up Web Administration for Microsoft Windows NT Server at a later date:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\webadmin\setup.exe or network address\apps\webadmin\setup.exe and choose the OK button.

3. Follow the instructions on screen to complete Setup.

For information about using Web Administration for Microsoft Windows NT Server, see the RKTOOLS.HLP online Help file.


1.6 Web Capacity Analysis Tool

To set up the Web Capacity Analysis Tool (WCAT) at a later date:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\wcat\i386\wcsetup.exe or network address\apps\wcat\i386\wcsetup.exe and choose the OK button.

3. Follow the instructions on screen to complete Setup.

For information about using WCAT, see the RKTOOLS.HLP online Help file.


1.7 Microsoft TechNet

To set up Microsoft TechNet at a later date:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\technet\setup.exe or network address\apps\technet\setup.exe and choose the OK button.

3. Follow the instructions on screen to complete Setup.

For information about using Microsoft TechNet, see the TechNet online Help file.


1.8 Client-based Administration Tools for Windows NT Server

To set up the Client-based Administration Tools for Windows NT Server at a later date:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\clients\setup.exe or network address\apps\clients\setup.exe and choose the OK button.

3. Follow the instructions on screen to complete Setup.

For information about using these tools, see each tool's individual Help file.


1.9 Microsoft dbWeb

To set up Microsoft dbWeb:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\dbweb\setup.exe or network address\apps\dbweb\setup.exe and choose the OK button.

3. Follow the instructions on screen to complete Setup.

For information about using Microsoft dbWeb, see the RKTOOLS.HLP online Help file.


1.10 Remote Access Manager

To set up Remote Access Manager at a later date:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\rasmgr\setup.exe or network address\apps\rasmgr\setup.exe and choose the OK button.

3. Follow the instructions on screen to complete Setup.

For information about using Remote Access Manager, see the RKTOOLS.HLP online Help file.


1.11 Crystal Reports Event Log Viewer

To set up Crystal Reports for the Windows NT Server Resource Kit at a later date:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\crystal\crw45ntr.exe or network address\apps\crystal\crw45ntr.exe and choose the OK button.

3. Follow the instructions on screen to complete Setup.

For information about using Crystal Reports, see the README.HLP file in the \APPS\CRYSTAL sub-directory on the Resource Kit CD or the RKTOOLS.HLP online Help file.


1.12 Internet Explorer 3.02

To set up Internet Explorer 3.02 on x86-based computers:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\ie30x\setup.exe or network address\apps\ie30x\setup.exe and choose the OK button. (The subdirectory is still called Ie301. Shouldn’t that change to Ie302? And is the Setup.exe file from the correct date?)

3. Follow the instructions on screen to complete Setup.

For information about using Internet Explorer, see the Internet Explorer online Help file.


1.13 Service Pack 3 for Windows NT 4.0

To set up Service Pack 3:

1. Click Start, and then click Run.

2. In the Run dialog box, type cd_driveletter: \apps\sp3\hardware platform filename or network address\apps\sp3\hardware platform filename and choose the OK button.

For example, type D: \apps\sp3\nt4sp3_i.exe to obtain the Service Pack for use on an x86-based computer. Notice that Service Pack 3 no longer supports the MIPS (and PPC?) hardware platform .

3. Follow the instructions on screen to complete Setup.


1.14 Perl 5 Source Code

The Perl 5 scripting language is installed during the main Resource Kit Setup process. However, if you also want the source code and additional files for building purposes, you need only copy those files from the CD.

To install the Perl 5 source code and additional libraries:

· At the command prompt, type the following lines:

xcopy cd_driveletter:\source\perl c:\perl /s

c:

cd \perl

Perl 5's source code should compile with your own compiler on any platform supported by Windows NT Workstation or Windows NT Server. With a slight alteration to the installation script, Perl 5 will also run on Windows 95. You must change the script to use COMMAND.EXE for Window 95 instead of CMD.EXE, which is used in Windows NT.

To run Perl 5, you will need a computer running Windows NT Workstation 3.5 or Windows NT

Server 3.5 or later, with at least 2 MB of disk space free. If you plan on building from the source, the amount of disk space required increases to at least 10 MB.

For the most current information on and source code for Perl 5, see:

http://www.activeware.com

the Perl home page on the World Wide Web.


1.15 POSIX Source Code

The \SOURCE\POSIX directory contains the C language source code to the POSIX utilities that are shipped with the Windows NT Resource Kit. This source code and the POSIX utility binaries are not supported by Microsoft and have not undergone formal testing. If they do not work correctly and you are a proficient C programmer, you may be able to fix any bugs yourself. Consult the Win32 Software Development Kit for Windows NT for background information on building POSIX programs.

To install the POSIX source code:

· At the command prompt, type the following lines:

xcopy cd_driveletter:\source\posix c:\posix /s /e /i

c:

cd \posix

longname

Notice that the partition to which you copy the source code must have the NTFS file system. Also, from the directory to which you copied all the source code, you must run the LONGNAME.BAT file before attempting to compile any of the utilities. This batch file renames many of the files to their correct name, which is often longer than the standard 8.3 filename. If you do not run this batch file, the utilities will not compile correctly.

The following utilities may require code changes to make them work on RISC-based computers: AR.EXE, CC.EXE, DEVSRV.EXE, LD.EXE, MAKE.EXE. For example, CC.EXE invokes "CL386" to compile other programs; on RISC-based computers, you must change the code to invoke the proper compiler.

The following copyright notice applies to both the POSIX utilities provided in binary form as well as the source code on the compact disc.

Copyright (c) 1988, 1989, 1990 The Regents of the University of California. All rights reserved.

This code is derived from software contributed to Berkeley by Adam de Boor.

This software and documentation is based in part on BSD Networking Software licensed from the Regents of the University of California, Berkeley. We acknowledge the role of the Computer Systems Research Group and the Electrical Engineering and Computer Sciences Department of the University of California, Berkeley, and the Other Contributors in its development.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions

and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions

and the following disclaimer in the documentation and/or other materials provided with the

distribution.

3. All advertising materials mentioning features or use of this software must display the following

acknowledgement: This product includes software developed by the University of California,

Berkeley and its contributors.

4. Neither the name of the University nor the names of its contributors may be used to endorse

or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


1.16 REXX Source Code

The Regina REXX scripting language is installed during the main Resource Kit Setup process. However, if you also want the source code and additional files for building purposes, you need only copy those files from the CD.

To install the Regina REXX source code:

· At the command prompt, type the following lines:

xcopy cd_driveletter:\source\rexx c:\rexx

c:

cd \rexx


2.0 Other Online Documents

The following table describes other online documents that contain important information about files available with the Windows NT Server Resource Kit.

Document Description

______________________________________________________________________________

AUDITCAT.HLPHelp file for audit categories from the Event Viewer

COUNTERS.HLPHelp file containing Performance Monitor Counter Definitions

HCLNT4.HLPThe Hardware Compatibility List, describing all hardware that has been tested and found compatible with Windows NT version 4.0 as of August, 1996

INTERNET.HLPThe online Help version of the printed Windows NT Server Internet Guide

NETWORK.HLPThe online Help version of the printed Windows NT Server Networking Guide

NTCARD40.HLPAdapter card Help, describing hardware settings for many Windows NT-compatible sound cards, network adapters, and SCSI adapters

NTEVNTLG.MDBAn Access database file containing the Windows NT Event Log messages

NTMSGS.HLPWindows NT Messages Help file for Windows NT version 4.0. This file replaces the Windows NT Messages Access database file that shipped in previous versions of this Resource Kit.

NTRKSUP1.HLPThe online Help version of the printed Windows NT Server Resource Kit Supplement 1 book

NTRKSUP2.HLPThe online Help book for Windows NT Server Resource Kit Supplement 2, which does not have a printed book. This includes new documentation on PPTP and RAS.

OS2API.TXTA list of compatible APIs in the OS/2 subsystem

POSIX.DOCDocumentation for the POSIX utilities, whose source is located on the Resource Kit CD in the \SOURCE\GNU\POSIX subdirectory

REGENTRY.HLPThe Windows NT Registry Entries online Help file, with parameters and usage information about the important values for services, devices, drivers, and software

RESGUIDE.HLPThe online Help version of the printed Windows NT Server Resource Guide

RIPROUTE.WRIDocumentation on routing with Windows NT Server

RKINET.HLPA Help file consisting of jumps to useful Windows NT and Resource Kit information on the Internet

RKTOOLS.HLPHelp for the Resource Kit utilities, describing the required files, syntax, and other usage issues, along with examples for using these tools

WINLOGO.DOCThe Designed for Windows NT and Windows 95 Logo Handbook

WORKSTN.HLPThe online Help version of the printed Windows NT Workstation Resource Guide


3.0 Resource Kit Support Policy

The SOFTWARE supplied in the Windows NT Server Resource Kit is not supported under any Microsoft standard support program or service. Customers may, however, report Windows NT Server Resource Kit issues and bugs by sending Internet mail to Rkinput@Microsoft.com or by referring to one of the options listed in the Windows NT Server Start Here book, which is included with the Windows NT Server product. Microsoft will, at its sole discretion, address issues and bugs reported in this manner. This electronic mail address is only for Windows NT Server Resource Kit-related issues.

NO WARRANTIES. Microsoft expressly disclaims any warranty for the SOFTWARE PRODUCT. The SOFTWARE PRODUCT and any related documentation is provided “as is” without warranty or condition of any kind, either express or implied, including without limitation, the implied warranties or conditions of merchantability, fitness for a particular purpose, or noninfringement. The entire risk arising out of use or performance of the SOFTWARE PRODUCT remains with you.

NO LIABILITY FOR DAMAGES. In no event shall Microsoft or its suppliers be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or any other pecuniary loss) arising out of the use of or inability to use this Microsoft product, even if Microsoft has been advised of the possibility of such damages. Because some states/jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you.


4.0 File List for the Windows NT Server Resource Kit Supplement 2 Utilities

The following is an alphabetical list of the tools included on the Windows NT Server Resource Kit Supplement 2 CD. For more information on them, please refer to the RKTOOLS.HLP online Help file.

ADDUSERS.EXE: AddUsers - Command-line utility, creates or writes user accounts to a comma delimited file.

ANIEDIT.EXE: Animated Cursor Creator - Windows-based tool for drawing and editing animated cursors.

APIMON.EXE: API Monitor

ASSOCIATE.EXE

(Updated) ATANALYZR.EXE: AppleTalk network device ANaLYZeR

AUDITCAT.HLP: Audit Categories Help

(New) AUDITPOL.EXE: AuditPol

AUTOEXNT.EXE: AutoExNT Service - Enables you to start a batch file, AUTOEXNT.BAT, at boot time without having to log on to the computer on which it will run.

(Updated) AUTOLOG.EXE: Windows NT Auto Logon Setter

BREAKFTM.EXE: Automated Mirror Break/Restore Utility

BROWMON.EXE: Browser Monitor - Windows-based tool, shows browser status.

BROWSTAT.EXE: Browser Status - Command-line utility, diagnoses browser problems and shows browser status.

C2CONFIG.EXE: Windows NT C2 Configuration Manager

CHOICE.EXE: Input from Batch Files - (MS-DOS 6.0 utility).

(Updated) CLIP.EXE: Clip

(New) CLIPSTOR.EXE

CMDHERE.EXE: Command Prompt Here

COMPREG.EXE - A Win32 character-based/command-line "Registry DIFF" that enables you to compare any two local and/or remote Registry keys in both Windows NT and Windows 95.

COMPRESS.EXE: File Compress - Command-line utility, compresses files. Needed for Setup customization.

(Updated) COUNTERS.HLP : Windows NT Performance Counters Help

Crystal Reports Event Log Viewer - Provides an easy way to extract, view, save, and publish information from the Windows NT system, application, and security event logs in a variety of formats.

dbWeb

(New) DEFPTR.EXE: Default Printer

DELPROF.EXE: User Profile Deletion Utility

DELSRV.EXE

(New) DEPENDS.EXE: Dependency Walker

Desktop Themes for Windows NT 4.0

DESKTOPS.EXE: DeskTops

DFLYDIST.EXE: Compound File Layout User Tool

(Updated) DH.EXE - Command-line utility, enables you to lock heaps, tags, stacks, and objects.

DHCPCMD.EXE: DHCP Administrator's Tool - Command-line utility.

(Updated) DHCPLOC.EXE: DHCP Server Locator Utility - Command-line utility, detects unauthorized DHCP servers on a subnet.

(Updated) DIRUSE.EXE: Directory Disk Usage - Command-line utility, shows disk space used per directory.

DISKMAP.EXE

DISKSAVE.EXE - Enables you to save the Master Boot Record and Boot Sector as binary image files.

DISKUSE.EXE - Command-line utility, scans directories on a hard disk and reports on space used by each user.

(New) DNSCMD.EXE

DOMMON.EXE: Domain Monitor - Windows-based tool, gives status on domains, domain controllers, trust relationships.

DRIVERS.EXE: Device Driver Information - Command-line utility, shows what drivers have loaded.

DSKPROBE.EXE: DiskProbe

DUMPEL.EXE: Dump Event Log - Command-line utility, dumps the event log to a file.

EM2MS.EXE

EMWAC Server CGI Gateway Scripts

ENUMPRN.EXE

EXCTRLST.EXE: Extensible Performance Counter List

EXETYPE.EXE: Finding the Executable Type - Command-line utility, identifies the hardware platform of a .EXE file.

EXPNDW32.EXE: File Expansion Utility - File Expansion utility, expands the compressed files on Windows NT distribution media.

FILEVER.EXE: FileVer - Command-line utility, examines the version resource structure of a file or a directory of files and displays information on the versions of executable files.

(New) FILEWISE.EXE

FINDGRP.EXE: Find Group - Command-line utility, finds all group memberships of a specified user.

(Updated) FIXACLS.EXE: Reset System File Permissions

FLOPLOCK.EXE: Lock Floppy Disk Drives - Command-line utility or service that restricts access to floppy drives.

FORFILES.EXE

FREEDISK.EXE

FTEDIT.EXE: FT Registry Information Editor - Windows-based tool, enables you to create, edit, and delete fault tolerance sets for disk drives and partitions of local and remote computers.

GETMAC.EXE

GETSID.EXE

GFLAGS.EXE

GLOBAL.EXE

GRPCPY.EXE: Group Copy

HCLNT4.HLP: Hardware Compatibility List - HCL in online Help format

(Updated) HEAPMON.EXE

IFMEMBER.EXE - Command-line utility, checks whether the current user is a member of a specified group.

IMAGEDIT.EXE: Image Editor - Windows-based tool, enables the creation of icons and cursors, and also used by the Animated Cursor Creator.

Index Server

INSTALLD.CMD (NTDETECT.COM): Startup Hardware Detector

INSTSRV.EXE: Service Installer - Installs any service.

KERNPROF.EXE: Kernel Profiler

KILL.EXE: Task Killing Utility - Command-line utility, use to end one or more tasks, or processes.

KIX32.EXE: KiXtart 95

(New) KIXGRP.EXE

LAYOUT.DLL

LEAKYAPP.EXE: LeakyApp

LINKCK.EXE: Link Checker

(Updated) LOCAL.EXE

LOGEVENT.EXE: Event Logging Utility

(New) LOGOFF.EXE

LOGTIME.EXE

MIBCC.EXE: SNMP MIB compiler

MONITOR.EXE: Performance Data Logging Service and Configuration Tool

(Updated) MUNGE.EXE

NETCLIP.EXE: Remote Clipboard Viewer

NETCONS.EXE: Net Connections

(New) NETDOM.EXE

NETSVC.EXE: Command-line Service Controller - Command-line utility, remotely starts, stops, and queries the status of services.

(Updated) NetTime for Macintosh

NETWATCH.EXE: Net Watcher - Windows-based tool, shows who is connected to shared directories.

NLMON.EXE

NLTEST.EXE

NOW.EXE: Now - Displays the current date and time on STDOUT, followed by any command-

line arguments you add.

(Updated) NTCARD40.HLP: Adapter Help - Describes settings for hardware supported under Windows NT.

NTDETECT.COM (INSTALLD.CMD): Startup Hardware Detector

(Updated) NTEVNTLG.MDB

(Updated) NTIMER.EXE

(Updated) NTMSG.HLP

(New) NTRIGHTS.EXE

NTUUCODE.EXE: 32-Bit UUDecode and UUEncode Utility

OH.EXE

OLEVIEW.EXE: OLE/COM Object Viewer

OS2API.TXT - List of compatible APIs in the OS/2 subsystem.

PASSPROP.EXE

(Updated) PATHMAN.EXE: Pathman

(Updated) PERF2MIB.EXE: Performance Monitor MIB Builder Tool

(Updated) PerfLog: Performance Data Log Service

PERFMTR.EXE: Performance Meter - Text-mode utility, provides performance information.

(Updated) Performance Tools

Perl 5 Scripting Language

PERMCOPY.EXE

PERMS.EXE: File Access Permissions per User - Command-line utility.

PFMON.EXE: Page Fault Monitor

PMON.EXE: Process Resource Monitor - Command-line utility.

POLEDIT.EXE: Windows NT System Policy Editor

POSIX Utilities

Power Toys

PSTAT.EXE: Process and Thread Status - Command-line utility, shows process statistics. Useful for debugging problems.

PULIST.EXE

PVIEWER.EXE: Process Viewer - Windows-based tool, shows the processes running in the system and allows ending processes and boosting priority.

QSLICE.EXE: CPU Usage by Processes - Windows-based tool.

QUICKRES.EXE: Quick Resolution Changer

RASLIST.EXE

RASUSERS.EXE: Enumerating Remote Access Users - Command-line utility.

RCMD.EXE: Remote Command Service - Remotely administers and runs command-line programs, client program. Used with RCMDSVC.EXE.

(New) REG.EXE

REGBACK.EXE: Registry Backup - Command-line utility, backs up Registry hives to files without the use of tape.

REGDMP.EXE

(Updated) REGENTRY.HLP: Windows NT Registry Entries - Online Help file

REGFIND.EXE

Regina REXX Scripting Language

REGINI.EXE: Registry Change by Script - Command-line utility, good for Setup programs.

REGKEY.EXE: Logon and FAT File System Settings - Windows-based tool, sets new Registry settings without actually editing the Registry. (Not on PPC RISC-based computers)

REGREST.EXE: Registry Restoration - Command-line utility, restores Registry hives from files.

(Updated) Remote Access Manager

(Updated) Remote Console

(Updated) REMOTE.EXE: Remote Command Line - Command-line utility, runs command-line programs on remote computers.

Remote Kill

RIPROUTE.WRI: Routing with Windows NT Server

RMTSHARE.EXE: Remote Share - Command-line utility, sets up or deletes shares remotely and can grant and remove ACLs on those shares.

ROBOCOPY.EXE: Enhanced Network File-Copying Utility - Command-line utility.

RSHSVC.EXE: TCP/IP Remote Shell Service

RSHXMENU.EXE: Security Power Toy

RUNEXT: Run Extension

SC.EXE

SCANREG.EXE - A Win32 character-based/command-line "Registry GREP" that enables you to search for any string in keynames, valuenames, and/or valuedata in local or remote Registries keys in both Windows NT and Windows 95.

SCLIST.EXE

SCOPY.EXE: File Copy with Security - Command-line utility.

SECADD.EXE

SECEDIT.EXE

(Updated) SETEDIT.EXE

SETUPMGR.EXE: Setup Manager - Windows-based tool, enables Windows NT to be installed or upgraded remotely.

SETX.EXE

ShareUI

SHORTCUT.EXE

(Updated) SHOWACLS.EXE

SHOWDISK.EXE

SHOWGRPS.EXE

SHOWMBRS.EXE

SHUTDOWN.EXE and SHUTGUI.EXE: Remote Shutdown - Command-line and GUI utilities, remotely shut down a server.

(New) SIPANEL.EXE: Soft Input Panel

SLEEP.EXE: Batch File Wait - Command-line utility, waits for a specified amount of time. Useful in batch files.

SNMPMON.EXE: SNMP Monitor

SNMPUTIL.EXE: SNMP Browser

SOON.EXE: Near-Future Command Scheduler

SRVANY.EXE: Applications as Services Utility

SRVCHECK.EXE

SRVINFO.EXE

SRVINSTW.EXE: Service Installer Wizard

(New) SRVMON.EXE: Service Monitor

(Updated) SU.EXE - Enables you to start a process running as an arbitrary user.

(Updated) SUBINACL.EXE: SubInAcl

SYSDIFF.EXE

TDISHOW.EXE: TDI Tracing Utility - Command-line utility, traces packets going across the TDI layer.

TELNETD.EXE: Telnet Server Beta

TEXTVIEW.EXE: TextViewer

TIMEOUT.EXE

(Updated) TIMESERV.EXE: Time Synchronizing Service - Command-line utility or service.

TIMETHIS.EXE: TimeThis

TIMEZONE.EXE

TLIST.EXE: Task List Viewer

TLOCMGR.EXE: Telephony Location Manager

TOPDESK.EXE: Multiple Desktops - Windows-based tool.

(Updated) TOTLPROC.EXE

TweakUI

TZEDIT.EXE: Time Zone Editor - Windows-based tool.

UPTOMP.EXE: Uni to Multiprocessor Upgrade Utility

USRSTAT.EXE

USRTOGRP.EXE: Add Users to Groups - Command-line utility, adds users to local or global groups from a user-specified input text file.

VDESK.EXE

(New) WAITFOR.EXE

WCAT: Web Capacity Analysis Tool

Web Administration of Microsoft Windows NT Server

WhoAmI

(Updated) WINAT.EXE: Command Scheduler

WINDIFF.EXE: File and Directory Comparison - Windows-based tool.

WINEXIT.SCR: Windows Exit Screen Saver - Logs the current user off after a specified time has elapsed.

(Updated) WINLOGO.DOC: "Designed for Windows NT and Windows 95" Logo Handbook

(Updated) WinMsdP.EXE - Command-line utility, generates a text file of all the information in WINMSD.

WINSCHK.EXE

WINSCL.EXE

WINSDMP.EXE: WinsDump

WNTIPCFG.EXE: Graphical IPConfig Utility

XCACLS.EXE


5.0 Directory Structure of the Windows NT Server Resource Kit Supplement 2 CD

The following is the directory structure of the Windows NT Server Resource Kit Supplement 2 CD. The subdirectory names on the CD correspond to the categories from which you can choose during the Setup process. When installed, the files for the utilities that you selected during Setup will be located on your hard disk under the \NTRESKIT directory (unless you assigned a different directory name) or one of its subdirectories.

ALPHA

COMMON

COMPDIAG

CONFIG

DESKTOP

FAULTTOL

FILEBAT

GNU

INET

NETADMIN

NETDIAG

PERFTOOL

REGISTRY

SETUP

SIPANEL

SYS

APPS

CLIENTS

CRYSTAL

DBWEB

IE301

INDEX

RASMGR

SP3

TECHNET

THEMES

WCAT

WEBADMIN

COMMON

COMMON

COMPDIAG

CONFIG

DESKTOP

DOCS

FAULTTOL

FILEBAT

INET

NETADMIN

NETDIAG

PERFTOOL

REGISTRY

SETUP

SIPANEL

I386

COMMON

COMPDIAG

CONFIG

DESKTOP

FAULTTOL

FILEBAT

GNU

INET

NETADMIN

NETDIAG

PERFTOOL

REGISTRY

SETUP

SIPANEL

SYS

SOURCE

GNU


ROBOCOPY

Robust File Copy Utility

Version 1.70

Windows NT® Resource Kits

Copyright © Microsoft Corp. 1995 - 1997

Contents

New features in this version

Introduction

Command line usage

Usage notes

The output log

The run summary

NEW FEATURES IN THIS VERSION

Restartable Copies :

Specify /Z on the command line and failed file copies will restart from close to the

point of failure, which can save a lot of time for large files. Previous versions of

Robocopy would always restart failed copies from the beginning of the file.

%Copied Progress Indications :

By default, the program now regularly displays %copied during each file copy.

Specify /NP (No Progress) on the command line to turn this feature off.

Wait for sharename creation :

Specify /TBD (sharename To Be Defined) on the command line to request this.

Robocopy will then wait for a sharename to be created by retrying on error 67.

Previous versions would always quit on this error.

Force creation of short file names.

Specify /FAT on the command line to tell Robocopy to create destination files with

names that conform to the traditional 8.3 file name format, rather than long file

names. This can be useful when copying to downlevel file systems.


INTRODUCTION

Robocopy is a Win32 console-mode application designed to simplify the task of maintaining an identical copy of a directory tree in multiple locations, either on the same machine, or in separate network locations. Robocopy effectively provides file replication on demand.

Robocopy is robust. If Robocopy encounters recoverable network errors whilst scanning directories or copying files it will simply wait a while and retry the operation. You can control the time between retries and the number of retries to attempt before giving up.

Robocopy is efficient. By default, if a file exists in both the source and destination, Robocopy will only copy the file if the two files have different timestamps, or different sizes. This saves time if the source and destination are separated by a slow network link. Optionally, you may specify that copies are restartable in the event of a copy failure to save even more time if your network links are unreliable.

Robocopy is flexible. You can choose to copy a single directory, or walk a directory tree. You can specify multiple filenames and wildcards to select which source files are candidates for copying. You can exclude source files from being copied by name, path, wildcard, or file attributes. You can exclude directories from being walked by name or path. You can chose to copy only files with the Archive attribute set, and you can choose whether or not to turn off the Archive bit in the source file after copying. The program classifies files by whether or not they exist in the source directory, the destination directory, or both. In the latter case the program further classifies files by comparing time stamps and file sizes between the source file and the corresponding destination file. You have complete control over which of these file classes will be copied. You can also choose to move files rather than copy them. And you can also choose to purge (delete) destination files and directories that no longer exist in the source, and thereby maintain the destination as an exact replica of the source.

Robocopy is informative. Robocopy produces console output (which can be redirected to a disk file for later perusal) which lists the directories processed, which files are copied (and why), network errors, and incompatibilities between the source and destination directory tree structures. Optionally, you can also ask Robocopy to show estimated time of arrival of copied files, list which files are skipped (and why), and highlight differences in the structure of the source and destination trees that might merit further investigation, or require housekeeping. By default, Robocopy displays copy progress indication (% copied) for each file.

Finally, Robocopy runs fine as a scheduled job. Just configure the Schedule service to log on as a user who has appropriate access to the source and destination directories, and specify remote directories as UNC names on the scheduled Robocopy command line.


COMMAND LINE USAGE

Run Robocopy with no command line arguments for brief usage instructions:

------------------------------------------------------------------------------- ROBOCOPY v 1.70 : Robust File Copy for Windows NT : by kevina@microsoft.com ------------------------------------------------------------------------------- Started : Wed Aug 28 01:23:45 1996 Usage : ROBOCOPY source destination [file [file]...] [options] source : Source Directory (drive:\path or \\server\share\path). destination : Destination Dir (drive:\path or \\server\share\path). file : File(s) to copy (names/wildcards - default is "*.*"). options : /S : copy Subdirectories, but not empty ones. /E : copy subdirectories, including Empty ones. /T : Timestamp all destination files, including skipped files. /R:n : number of Retries on failed copies - default is 1 million. /W:n : Wait time between retries - default is 30 seconds. /REG : Save /R:n and /W:n in the Registry as default settings. /TBD : wait for sharenames To Be Defined (retry error 67). /FAT : create destination files using 8.3 FAT file names only. /X : report all eXtra files, not just those selected. /V : produce Verbose output, showing skipped files. /L : List only - don't copy, timestamp or delete any files. /A+:[R][A][S][H] : add the given Attributes to copied files. /A-:[R][A][S][H] : remove the given Attributes from copied files. /XA:[R][A][S][H] : eXclude files with any of the given Attributes /A : copy only files with the Archive attribute set. /M : like /A, but remove Archive attribute from source files. /XF file [file]... : eXclude Files matching given names/paths/wildcards. /XD dirs [dirs]... : eXclude Directories matching given names/paths. /XC | /XN | /XO : eXclude Changed | Newer | Older files. /XX | /XL : eXclude eXtra | Lonely files and dirs. /IS : Include Same files. /Z : Copies files in restartable mode. /NP : No Progress - don't display % copied. /ETA : show Estimated Time of Arrival of copied files. /MOVE : Move files and dirs (delete from source after copying). /PURGE : delete dest files/dirs that no longer exist in source.


USAGE NOTES

Use within a Unix Shell

All Robocopy switches can be specified Unix-style (e.g. you can use -ETA instead of /ETA), and source and destination directory paths can be specified using the Unix-style delimiter "/" rather than the native Windows-style delimiter "\".

The only restriction is that any argument that starts with a "/" is taken to be a switch if it only contains a single "/". Thus //server/share/dir and /download/test are treated as paths, but /dir is treated as a switch. This is to avoid any possible confusion between switches and single-level paths subordinate to the root of a drive. To specify such a directory as an argument, use an alternate expression for its path, such as X:/dir or //server/C$/dir.

Use with Windows 95 and Windows NT 3.5x

Robocopy is a Unicode application, and will not run under Windows 95, because Windows 95 does not provide full Unicode support.

Also, Robocopy uses the new CopyFileEx() Win32 API, which is specific to Windows NT 4.0, and therefore will not run under Windows NT 3.5x.

Walking a Directory Tree

By default Robocopy will only process the single source directory specified on the command line. To process the whole directory tree beneath the source directory, you should use the /S switch or the /E switch. Both these options will walk the source tree, the only difference being that /S will refrain from creating new empty directories in the destination tree.


Retries

Most file system operations that that fail and return an error will cause the program to wait and then retry the operation until it succeeds or the retry limit is reached. By default there will be 30 seconds between retries, and up to one million (1000000) retries. Use /W:n to change the wait time in seconds between retries, and /R:n to change the retry limit, where n is a positive decimal integer, or zero if you do not want retries or wait times between retries. If invalid values are given for /W or /R, the respective default value is used.

To change the default retry parameters, use the /REG switch on a valid Robocopy command that specifies non-default values for /W and /R. When /REG is used, the values you specify for /W and /R will be stored in the Registry and used as default values for /W and /R in future Robocopy runs where /W and /R are not specified on the command line. Simply specify /W and/or /R on the command line to override the stored settings.

Note that certain errors in some operations will not be retried, where practical experience indicates this would be futile. For example, an error of "Network Name Not Found" usually indicates that a remote computer exists, but does not have a sharepoint with the given name. As manual intervention will be required to correct this (by creating a suitable sharename on the remote computer), this error is generally not retried, and the attempted operation fails.

However, in some instances, this might not be the correct action for this error. For example, in a software publishing environment it is quite common to delete a sharename, update the contents of the sharepoint, then recreate the sharename. In this situation you should use the /TBD switch, which instructs the program to retry when it encounters a "network name cannot be found." error, on the assumption that we are waiting for the sharename to be defined.

Normally Robocopy will restart failed copies from the beginning of the file. You can override this default behaviour by specifying the /Z switch, which requests restartable copies - with /Z, failed copies will restart from close the point of failure rather than the beginning of the file. There is one exception to this - if the file's size or timestamp is modified between retries, the file has obviously been changed, and the copy is restarted from the beginning of the file.


Specifying File and Directory Names

By default, Robocopy assumes that any non-switch command-line argument is some form of file name, path, or wildcard. These may be intermingled with switch arguments, but the command line is easier to read if they are grouped together. The actual meaning of such a name depends on where they appear in the command in relation to any /XF or /XD switches.

The command line is parsed from left to right. There must be two non-switch arguments before any /XF or /XD switch, and these are taken to be the pathnames of the source and destination directories respectively.

Thereafter any non-switch argument is taken to be an Include Filespec - either a filename or wildcard (but not a path) naming one or more files (or sets of files) to include and consider as candidates for copying, until a /XF or /XD switch is found.

Note that if no Include Filespecs are found in the command line, a default of "*.*" (all files) is assumed. Also note that these Include Filespecs must be specified as individual arguments separated from other arguments by white space, and not appended to the source or destination directory pathnames as in, for example, the Xcopy command.

/XF (eXclude Files) informs the program that subsequent filenames, paths and wildcards are Files to exclude from copying (Exclude Filespecs rather than Include Filespecs), until a subsequent /XD switch is found.

/XD (eXclude Directories) informs the program that subsequent filenames and paths are Directories to exclude from copying (Exclude Dirspecs rather than Include or Exclude Filespecs), until a subsequent /XF switch is found.

Note the subtle differences in allowed values here :

ArgumentsNamesPathsWildcards

Source DirectoryYesYesNO

Destination DirectoryYesYesNO

Include FilespecsYesNOYes

Exclude FilespecsYesYesYes

Exclude DirspecsYesYesNO

Example : ROBOCOPY c:\source d:\dest *.c* /XF *.cpp /S /XD bin c:\source\unwanted

This command would cause Robocopy to walk the directory tree whose root is c:\source, except subdirectories named "bin", and the subdirectory c:\source\unwanted. Files whose extensions begin with "c" will be copied, except those whose extension is ".cpp".


Robocopy File Classes

For each directory processed Robocopy constructs a list of files matching the Include Filespecs, in both the source and destination directories. The program then cross-references these lists, seeing which files exist where, comparing file times and sizes where possible, and places each selected file in one of the following classes :

Exists inExists inSource/DestSource/Dest

File ClassSourceDestinationFile TimesFile Sizes

LonelyYesNon/an/a

SameYesYesEqualEqual

ChangedYesYesEqualDifferent

NewerYesYesSource > Destn/a

OlderYesYesSource < Destn/a

ExtraNoYesn/an/a

MismatchedYes ( file)Yes (directory)n/an/a

By default, Changed, Newer and Older files will be considered to be candidates for copying (subject to further filtering described below), Same files will be skipped (not copied), and Extra and Mismatched files (and directories) will simply be reported in the output log.

Use the following switches to override this default behaviour :

/XLeXclude Lonely files

/ISInclude Same files

/XCeXclude Changed files

/XNeXclude Newer files

/XOeXclude Older files

Use the following switch to suppress the reporting and processing of Extra files :

/XXeXclude eXtra files

To just make sure the destination tree includes the current version of all source files, you do not need to specify any of these arguments. Robocopy's default behaviour will be all you need for most situations.

Use /XO with caution. If you terminate Robocopy whilst it is copying, any incompletely copied file will almost certainly have a later file time than the source file. If you restart the same copy, Robocopy will see this file as an Older file, and will skip it if you use /XO. Bear this in mind if you are using /XO and need to kill a copy. The most appropriate use for /XO is to synchronise two directory trees that can each be updated simultaneously in disjoint areas. Using /XO and copying first in one direction, and then the other, will ensure that the latest files are present in both directory trees.

Note that specifying /XL restricts the program to copying files from the source directory tree only if a corresponding file of the same name already exists in the destination. This provides a convenient mechanism for maintaining a copy of a selected subset of the source tree.

Also note that specifying /IS on its own with no other selection switches forces a total refresh of the destination tree, should you ever need to do this.


File Times and File Names

It is recommended that you make sure that both the source and destination directories reside on an NTFS partition, wherever possible. Copying to downlevel file systems (HPFS or FAT) will work, but you may lose long filenames, and file times may suffer from rounding errors on the destination. This is of course due to the superior capabilities of the NTFS file system.

For example, file time granularity is 100 nanoseconds on NTFS, but only 2 seconds on FAT, so copying a file from NTFS to FAT always causes file times to be rounded to a value that the FAT file system can handle. Accordingly, Robocopy considers file times to be identical if they are within two seconds of each other. Without this 2-second leeway, the program might erroneously classify many otherwise unmodified files as Older or Newer files, which would result in a great deal of unnecessary copying of these unchanged files.

Sometimes this handling of file times needs to be overridden. For example, assume an NTFS tree is copied temporarily to FAT, then later the FAT tree (and all its rounded FAT file times) is copied to a local NTFS drive. Later, there may be need to recreate the original tree exactly. Refreshing the whole tree would do the job, but it would inefficient for a large tree. In such a scenario you should use the /T switch to force the copying of just file times for Same files, rather than the whole file that would be copied if /IS was used.

When the destination is on a FAT or HPFS partition, you may also experience problems when copying files and directories with long names, or whose names included extended Unicode characters. To overcome these problems, use the /FAT switch. This tells Robocopy to create destination files using system-generated names in the standard 8.3 FAT file system format, rather than trying to create long or extended filenames on downlevel file systems.

Attribute Processing

By default, Robocopy ignores source file attributes when selecting files to copy - any file matching other specified conditions will be copied regardless of its attribute settings.

The /A and /M switches both modify this behaviour, and cause only those source files with the Archive attribute set to be selected for copying. After copying the Archive attribute of the source file is left unmodified (still set) if /A was used, or reset (turned off) if /M was used.

Furthermore, the /XA:[R][A][S][H] (eXclude Attributes) switch can be used to exclude files from being copied if one or more of the given attributes is set. For example, you could specify /XA:R to prevent Read-only files from being copied. Similarly, /XA:SH would prevent any files with either or both of the System or Hidden attributes set from being copied.

After a file is successfully copied to the destination, the destination file's attributes are set to match those of the source file, except for the Archive bit, which is always set (turned on). This is to identify newly copied files and make it easy to back them up.

To modify this default behaviour, /A+:[R][A][S][H] (Attribute add) and /A-:[R][A][S][H] (Attribute subtract) can be used. For example, /A-:A would cause the Archive attribute to be reset, and /A+:R would render all copied files Read-only in the destination.

The exact order of attribute operations on newly copied destination files is as follows :

1.Attributes are copied from the corresponding source file.

2.The Archive attribute is set (turned on).

3.Attributes specified by /A+:[R][A][S][H] are set (turned on).

4.Attributes specified by /A-:[R][A][S][H] are reset (turned off).


Moving Files

Rather than copying files, it is often desirable to move them instead, especially if disk space is at a premium on your network. Robocopy's /MOVE switch provides this facility. It causes source files to be deleted from the source directory tree after they have been successfully copied to the destination.

Note that even with /MOVE specified, Robocopy will only delete those source files that it successfully copies to the destination. This applies even to skipped Same files as there is no absolute guarantee that a skipped source file is identical to its corresponding destination file, even if the file times and sizes are identical, until immediately following a successful copy.

Therefore it is perfectly normal for files and directories to remain in the source tree even after a Robocopy has walked the tree with /MOVE specified. The user must decide whether or not it is safe to delete the remaining entries, and, if so, delete them manually.

True Replication

If you require the destination directory tree to be maintained as an exact mirror of the source directory tree, and have files and directories deleted from the destination whenever they disappear from the source, you can use the /PURGE switch (at your own risk).

/PURGE causes Robocopy to delete ALL Extra and Mismatched destination files and directories. After a Mismatched destination entry has been deleted, the corresponding source entry is then treated as a Lonely file or directory, and processed accordingly.

Where /PURGE results in the deletion of an Extra or Mismatched destination directory, the entire directory tree, including all subordinate files and subdirectories, will be deleted.

You should use /PURGE with extreme caution. If you specify /PURGE along with an incorrect (but existing) destination directory, Robocopy WILL DELETE lots of data from the destination very quickly. You use the /PURGE option at your own risk.

Note that the /XX switch excludes Extra files from further processing, so /PURGE will have no effect if /XX is also used.


Scheduling Robocopy

You can use the Windows NT AT command, or the Resource Kit SOON command, with the

Windows NT Schedule Service to create Robocopy jobs that run regularly in the background,

to automatically maintain local mirrors of remote directory trees.

By default the Schedule Service logs on as the System Account for the local system, which

has no network access. Scheduled jobs run in the same context as the Schedule Service. So,

in order to successfully schedule a Robocopy job, some extra configuration is required. There

are basically two options :

Option 1) Leave the Schedule Service running in the context of the local System Account,

and schedule batch files of the following form :

NET USE \\remoteserver\IPC$ /USER:userid password ROBOCOPY \\remoteserver\sourcepath \\localserver\destpath ... NET USE \\remoteserver\IPC$ /DEL

Within each such job, credentials with remote servers are established by connecting to the

IPC$ (Inter Process Communication) share on remote machines using an appropriate user

account, rather than as the local System account. The disadvantage of this approach is that

user passwords are stored in the batch files, but they can be protected by storing the batch

files on an NTFS partition, and applying appropriate NTFS file security to the batch files.

Option 2) In Control Panel/Services/Schedule Service/Startup configure the Schedule

Service to use a "real" user account that you have created in User Manager, by specifying an

appropriate User Id and Password in the "Log On As" section. Then you should Stop and

Start the Schedule Service to get it running in the new user context. Once the nominated

user has been granted appropriate access to source and destination servers, you can now

schedule Robocopy jobs to copy files between them.

Finally, as drive mappings can be changed by users, it is generally best to use UNC names

for source and destination directories in scheduled Robocopy jobs, as these explicity specify

file locations, and are more reliable. I.e. rather than scheduling a command of the form :

ROBOCOPY X:\source Y:\dest ...

for increased reliability, you should use commands of the form :

ROBOCOPY \\server1\share1\source \\server2\share2\dest ...

AT and the Schedule Service are documented in the Windows NT Commands on-line help.

SOON is documented in the Windows NT Resource Kit on-line documentation.


THE OUTPUT LOG

Robocopy outputs a log of files and directories processed to its console window. This output can be redirected to a disk file if required.

Each log line starts with a brief text tag, which is formatted according to the following rules :

*CAPITALSindicate an anomaly that should be investigated.

Leading Capsindicate a file that was selected for copying.

lowercaseindicates a file that was skipped.

(lowercase tags will only be seen if /V is used).

Tags that indicate copying are left-aligned, tags that indicate skipping are right-aligned, tags that indicate anomalies are placed further to the left than other tags, and error messages always start in column 1. This arrangement simplifies the task of scanning through even a verbose listing, and makes it easier to spot new downloads, anomalies, and network errors.

If few files are copied, the left margin of the output log will be mostly blank. Copied files and anomalies are easily-spotted non-blank entries in the left margin of the output log.

Disregarding error reporting and retries, at most one line of output is produced per source file or directory. Lines for directories show the number of files matching the Include Filespecs in the directory (where known), and the full pathname of the directory. Lines for files indicate what was done with the file, the size of the file, and its name.

One line is also output for each Mismatched file and directory, and also for each Extra file and directory in the destination. These resemble lines for normal directories and file, except that lines for Extra files include the file's full pathname, as an aid to rapid housekeeping.

By default, only Extra files that match the Include Filespecs on the command line will be reported. The rationale for this is that you are probably not interested in spurious *.TXT files in the destination when you are refreshing *.CPP files. However, if you really do need a list of all extra files in the destination, irrespective of their type, you can obtain one by using /X.

By default, no output is produced for skipped files. To obtain a verbose listing which shows all source files matching the Include Filespecs, including skipped files, use the /V switch.

By default, Robocopy will output copy progress information, in the form of a display of the percentage of the file copied so far (% copied). You can use the /NP switch to suppress the display of %copied progress information - useful when output is redirected to a disk file.

To see the start time of each file copy, and the estimated time that the copy should complete (based on the observed throughput of previous copies), use the /ETA switch. These times are displayed after the file name in the format "hh:mm -> hh:mm" (start time -> ETA).

Finally, to obtain a list the files that would be copied, without committing to the overhead of actually doing the copying, you can use the /L switch.


The following tags apply to files :

File TagMeaning

*MISMATCH The source file corresponds to a destination directory of the same name.

The source file is skipped as it cannot be copied.

Housekeeping of the destination tree is recommended.

*EXTRA File The file exists in the destination but not the source (an Extra file).

Some housekeeping of the destination tree may be required.

New File The file exists in the source but not in the destination (a Lonely file).

The file is copied because /XL was not used. To skip this file, use /XL.

lonely The file exists in the source but not in the destination (a Lonely file).

The file is skipped because /XL was used. To copy this file, omit /XL.

Newer The source file has a later timestamp than the destination file.

The file is copied because /XN was not used. To skip this file use /XN.

newer The source file has a later timestamp than the destination file.

The file is skipped because /XN was used. To copy this file, omit /XN.

Older The source file has an earlier timestamp than the destination file.

The file is copied because /XO was not used. To skip this file, use /XO.

older The source file has an earlier timestamp than the destination file.

The file is skipped because /XO was used. To copy this file, omit /XO.

Changed The source and destination files have identical timestamps, different sizes.

The file is copied because /XC was not used. To skip this file use /XC.

changed The source and destination files have identical timestamps, different sizes.

The file is skipped because /XC was used. To copy this file, omit /XC.

Same The source and destination files have identical timestamps and sizes.

The file is copied because /IS was used. To skip this file, omit /IS.

same The source and destination files have identical timestamps and sizes.

The file is skipped because /IS was not used. To copy this file, use /IS.

attrib At least one source file attribute matches the attributes specified by /XA.

The file is skipped because of this. To copy this file, modify or omit /XA.

named The file is skipped because it was named in the Exclude Filespecs. To process this file, amend the Exclude Filespecs following /XF.


The following tags apply to directories :

Directory TagMeaning

(blank)A normal directory.

*MISMATCH This source directory corresponds to a destination file of the same name.

It cannot be processed. Housekeeping of the destination is recommended.

*EXTRA Dir The directory exists in the destination but not the source (an Extra dir).

Some housekeeping of the destination tree may be required.

lonely The directory exists in the source but not the destination (a Lonely dir).

The directory is skipped because /XL was used. To process this, omit /XL.

named The directory is skipped because it was named in the Exclude Dirspecs. To process this directory, amend the Exclude Dirspecs following /XD.

THE RUN SUMMARY

Just before Robocopy terminates, it outputs a summary of its activities during the run to its console window (or disk file if redirected) in the following format:

Total Copied Skipped Mismatch FAILED Extras Dirs : 75 0 75 0 0 0 Files : 960 13 947 0 0 1 Bytes : 19.8 m 190.0 k 19.6 m 0 0 12.5 k Times : 0:16.914 0:03.504 0:00.000 0:13.410

This summarises the volume of data processed. The first column shows the total number of files and directories processed and the total size of files matching the Include Filespecs in the source. The other columns provide a breakdown of these grand totals as follows:

Copied:subtotals for directories created and files actually copied.

Skipped:subtotals for directories walked but not created, and files skipped.

Mismatch:subtotals for Mismatched files and directories.

FAILED:subtotals for items not processed successfully within the retry limit.

Extras:subtotals for items present in the destination but not the source.

The second section of the summary provides timing information for the run. Total time should be self-explanatory. This is broken down as follows:

Copied:time spent actually copying files, but excluding retry wait times.

FAILED:time spent waiting between retries for failed operations.

Extra:time spent scanning directories, and doing everything else.

Large times in the FAILED column usually indicate that network problems were experienced.

-----oooooo-----


Troubleshooting PPTP on a Windows NT-based PPTP Client

This section describes a few monitoring tools to help you diagnose connection problems that can occur with Windows NT-based PPTP clients. It also outlines some general troubleshooting steps you can take and describes some common connection problems.

This section does not describe installation and connection problems that can occur with Windows NT-based PPTP servers. For information about such problems, refer to the resources listed in Table 1.

Table 1 PPTP Server Troubleshooting Resources

Knowledge Base Article | Title
Q164052 | “PPTP and Interoperability with Other Local Machine Services”
Q154674 | “PPTP Registry Entries”
Q117304 | “RAS Event ID (Error Code) Information”
Q158387 | “RAS Server Cannot use DHCP”
Q162847 | “Troubleshooting PPTP Connectivity Issues in Windows NT”


Using TCP/IP Utilities to Troubleshoot

Windows NT provides several TCP/IP utilities to help you diagnose connection problems. The following utilities may help you diagnose problems you have connecting to PPTP servers. For more information about these utilities, see Chapter 12, “Troubleshooting Tools and Strategies,” in the Windows NT Server Networking Guide.


Ping

Ping is a command-line utility that tests to see if hosts on TCP/IP networks are reachable. You can use ping to test network connectivity and connectivity to a host.

To use ping

At the command prompt, type:

ping IP_address

The ping utility attempts to reach the host at the IP address you specified. It gives one of several responses:

· If ping responds with a reply, the host is reachable and you are properly connected to the Internet.

· If ping responds with the message "Request Timed Out," the host is not reachable at this time.

· If ping responds with the message "Destination Net Unreachable," you might not be properly connected to the Internet.

· If ping responds with the message "Bad IP address," you might not be properly connected to a DNS server.

Note You might not be able to ping the PPTP server. The administrator of the PPTP server might have set up PPTP filtering, which ensures that the PPTP server will only accept PPTP packets. If so, the PPTP server will not accept ping requests.


Net View

The net view utility helps you determine if destinations on TCP/IP networks are reachable using WINS (Windows Internet Name Service).

To use net view

At the command prompt, type:

net view \\servername

If net view returns with information about the server, that server can be reached using WINS. If not, you might not be connected to a WINS server, or the server you specified might not be available.


Wntipcfg

Wntipcfg is a graphical tool that gives you information about your IP configuration.

To use wntipcfg

1. At the command prompt, type:

wntipcfg

2. The resulting screen identifies your IP address and the IP address of your default gateway.

Note When you make a PPTP connection, Dial-Up Networking changes your default gateway to be the IP address of the PPTP server.

3. Click More info.

4. The resulting screen identifies your IP address, subnet mask, and default gateway for each of your network interfaces, including the interface for your network adapter, your Dial-Up Networking interface, and your PPTP interface.


Route

Your computer maintains a routing table, which includes information about where to send outgoing packets in order to reach certain subnets. In some cases, you need to view or modify your routing table.

You can use the route utility to add, change, or delete routes. Route has the following options:

· route displays help about the utility.

· route print displays a list of all routes your workstation recognizes.

· route add enables you to add routes.

· route delete enables you to delete routes.

· route change enables you to modify routes.

For more information about the route utility, see Chapter 12, “Troubleshooting Tools and Strategies,” in the Windows NT Server Networking Guide.


Verifying Your Configuration

If you are having problems connecting to a PPTP server, make sure you have correctly configured your PPTP client. This section provides a list of steps you should take to make sure you have correctly configured your PPTP client. If you still cannot connect to a PPTP server, see the section “Troubleshooting Your PPTP Connection.”

Verify the following:

· Make sure that your workstation and its applications support the protocols native to the target network (the network you will be tunneling to).

· If you are tunneling through the Internet, make sure your Internet connection is working properly.

· In Network in Control Panel, make sure that you have added the PPTP protocol.

· In Network in Control Panel, make sure that you have configured at least one VPN port.

· Check the phone book entry for the PPTP server to make sure it is for a VPN device, not a modem.

· Make sure you have a valid account on the PPTP server.

· Check the phone book entry for the PPTP server to make sure it includes the IP address or host name of the PPTP server.

· Check the phone book entry for the PPTP server to make sure it includes all the protocols used on the target network.

· If the target network uses TCP/IP, check the phone book entry for the PPTP server to make sure the TCP/IP settings are correctly configured for the target network.

· If you are making two connections, make sure that the second connection is a VPN connection.


Troubleshooting Your PPTP Connection

This section describes common PPTP problems and explains how to correct them. Before using this section to diagnose your connection problems, follow the steps outlined in “Verifying Your Configuration” to make sure you have correctly configured your PPTP client.


Cannot Connect to a PPTP Server

If you cannot connect to a PPTP server, verify the following items.

Verify That You Are Properly Connected To The Internet

To check that your connection to the Internet is working properly:

1.Ping www.microsoft.com.

2.If ping does not reach www.microsoft.com, type:

ping 207.68.156.16

1.If ping succeeds, you are properly connected to the Internet but you are not properly connected to your DNS server.

2.If ping fails, you might not be connected to the Internet. Contact your ISP.

Ping the PPTP Server

Ping the IP address of the PPTP server.

If you receive a response, you are properly connected to the PPTP server, and you might have entered an incorrect user name or password.

If you do not receive a response, the administrator of the PPTP server might have turned on PPTP filtering. This prevents you from pinging the PPTP server. Contact the administrator of the PPTP server.

Check for a Firewall

Firewalls sometimes filter out PPTP packets. Contact your ISP and the administrator of your corporate server and ask if they are using a firewall. If so, ask them to pass TCP port 1723 and IP protocol 47.

Note IP protocol 47 is the Generic Routing Encapsulation (GRE) protocol.

Make Sure Your ISP Isn’t Filtering Out PPTP

Contact your ISP and ask if it filters out GRE packets. If so, request that it pass IP protocol 47.

Check for a Proxy Server

It is not possible to create a PPTP tunnel that passes through a proxy server such as a computer running Microsoft Proxy Server. Therefore, if your internal network’s proxy server handles all Internet traffic, including PPTP traffic, you will not be able to create a PPTP tunnel to access resources on the internal network.

However, it is possible to configure a proxy server as a PPTP server in order to securely access resources on the proxy server. It is also possible to set up a secure PPTP connection on a separate computer instead of sending your packets through a proxy server. For more information, contact the administrator of the PPTP server.

Increase the Number of Retransmissions

If you receive an error message stating that the server has not responded, you might want to increase the number of attempts PPTP makes to transmit data. You can do so by changing the PPTPTcpMaxDataRetransmissions Registry entry, in the following Registry path:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

By default, this value is 9h. You can increase the value to 18h. You should not increase it beyond 25h.


PPTP Connection is Slow

If your PPTP connection is slow, follow the procedures outlined below:

Check the Connection to Other Internet Sites

To check the speed of your Internet connection, ping Internet sites such as www.microsoft.com and www.yahoo.com. If ping shows a response time of more than five seconds, you have a slow Internet connection. Contact your ISP.

Check the Connection to Your PPTP Server

If you do not have problems with your Internet connection, but the connection to your PPTP server is still slow, the PPTP server might be overloaded. Contact the administrator of the PPTP server.

Connect Directly to Network Resources

If you have a slow connection, you might want to connect directly to network resources. To do so, at the command prompt, type:

net use \\server\share

Note You can type either the IP address or the name of the server to which you are connecting. Typing the IP address may enable you to connect to the server more quickly.


Cannot See Servers on Your Local Network

After you make a PPTP connection to a PPTP tunnel server, you might lose connectivity to some of the servers on your network. This is because of the way TCP/IP networks work. Clients on TCP/IP networks can send packets directly to hosts on their immediate network segment. However, to reach other network segments and other networks, they send their packets instead to a default gateway. That default gateway then decides where to send the packets. Thus, clients can send packets to servers anywhere in a very large, complex network without having to know how to reach each server. Figure 1 shows how TCP/IP clients use default gateways.

Figure 1 - Before creating PPTP Tunnel

TCP/IP clients can be configured with several different default gateways. If one default gateway fails, the clients automatically switch to another default gateway. However, TCP/IP clients cannot use more than one default gateway at a time.

Figure 2 shows what happens when you use PPTP to connect to a TCP/IP network. Dial-Up Networking assigns a second default gateway when you make a PPTP connection. Because your client can only use one default gateway, it sends all network traffic through the second gateway. You can no longer access some of the servers you were able to before connecting to your PPTP tunnel server.

Figure 2 - After connecting to a PPTP server

You can solve this problem by manually adding routes to destinations on your local network. Use the route command to manually add a route to the gateway, IP subnet, or IP network you want to reach. For more information about adding routes, see Chapter 12, “Troubleshooting Tools and Strategies,” in the Windows NT Server Networking Guide.

For more information about solving this problem, see the Release Notes included with the Dial-Up Networking upgrade.


Lose Internet Connectivity or Cannot Use Browser

When you connect to a tunnel server, you might lose connectivity to the Internet. This is because the PPTP tunnel server becomes your default gateway, and your computer no longer uses the default gateway to the Internet. For more information about the default gateway problem and its solution, see the section “Cannot see servers on your network.”

You can solve this problem in one of two ways.

· You can disable the default gateway to the PPTP tunnel server

To disable the default gateway to the PPTP tunnel server

1. In the Dial-Up Networking folder, right-click the PPTP server connection icon.

2. Click the Server Types tab.

3. Click TCP/IP Settings.

4. Clear the Use Default Gateway on Remote Networks check box.

5. You may need to configure routes to servers on the remote network.

· You can configure your Web browser’s proxy server settings

Many networks allow access to the Internet through a proxy server. To access Web pages on the Internet, you must configure your Web browser’s proxy server settings as if you were physically connected to the target network. For example, if you are using Internet Explorer, follow the procedure below.

To configure proxy server settings in Internet Explorer

1. Right-click the Internet Explorer icon.

2. Click Properties.

3. Click the Connection tab.

4. In the Proxy server box, select Connect through a proxy server.

5. In the Proxy server box, add the proxy servers you use on your corporate network. If you do not know these settings, contact your network administrator.


Cannot Connect After Disconnecting From a LAN

You might not be able to connect to some of your network’s hosts after disconnecting a mobile computer such as a laptop from your corporate network, then making a PPTP connection to your corporate network. This happens because your computer is still forwarding all its network traffic to the network adapter instead of over the PPTP connection.

If you experience connectivity problems with a laptop, you can create a hardware profile that does not use the network adapter. For more information, see Chapter 36, “General Troubleshooting,” in the Windows NT Workstation Resource Kit.

You can also use route add or route change to create static routes to gateways, IP subnets, and IP networks.


Troubleshooting PPTP on a Windows 95-based PPTP Client

This section describes a few monitoring tools to help you diagnose connection problems that can occur with Windows 95-based PPTP clients. It also outlines some general troubleshooting steps you can take and describes some common connection problems.

Caution If you have serious problems with your PPTP client, you might want to remove PPTP and reinstall it. If so, follow the steps outlined in the procedure “To remove Dial-Up Networking” in the section “PPTP doesn’t work after ISDN installation.” Never remove PPTP components by using Network in Control Panel.


Using TCP/IP Utilities to Troubleshoot

Windows 95 provides several TCP/IP utilities to help you diagnose connection problems. The following utilities may help you diagnose problems you have connecting to PPTP servers. For more information about these tools, see Chapter 12, “Troubleshooting Tools and Strategies,” in the Windows NT Server Networking Guide.


Net View

The net view utility helps you determine if destinations on TCP/IP networks are reachable using WINS (Windows Internet Name Service.)

To use net view

At the command prompt, type:

net view \\servername

If net view returns with information about the server, that server can be reached using WINS. If not, you might not be connected to a WINS server, or the server you specified might not be available.


Winipcfg

Winipcfg is a graphical tool that gives you information about your IP configuration.

To use winipcfg

1. At the command prompt, type:

winipcfg

2. The resulting screen identifies your IP address and the IP address of your default gateway.

Note When you make a PPTP connection, Dial-Up Networking changes your default gateway to the IP address of the PPTP server.

3. Click More info.

4. The resulting screen tells you your IP address, subnet mask, and default gateway for each of your network interfaces, including the interface for your network adapter, your Dial-Up Networking interface, and your PPTP interface.


Route

Your computer maintains a routing table, which tells it where to send outgoing packets in order to reach certain subnets. In some cases, you need to view or modify your routing table.

You can use the route utility to add, change, or delete routes. Route has the following options:

· route displays help about the utility.

· route print displays a list of all routes your workstation recognizes.

· route add enables you to add routes.

· route delete enables you to delete routes.

· route change enables you to modify routes.

For more information about the route utility, see Chapter 12, “Troubleshooting Tools and Strategies,” in the Windows NT Server Networking Guide.


Verifying Your Configuration

If you have problems connecting to a PPTP server, make sure that you have correctly configured your PPTP client.

This section provides a list of steps you should take to make sure you have correctly configured your PPTP client. If you still cannot connect to a PPTP server, see the section “Troubleshooting Your PPTP Connection.”

Verify the following:

· Make sure your workstation and its applications support the protocols native to the target network (the network you will be tunneling to).

· If you are tunneling through the Internet, make sure your Internet connection is working properly.

· In Dial-Up Networking, make sure that you have configured at least one VPN connection to a PPTP server.

· In Dial-Up Networking, check your VPN connection to make sure that you have selected Microsoft VPN Adapter.

· Make sure you have a valid account on the PPTP server.

· In Dial-Up Networking, check your VPN connection to make sure that you have entered either the host name or IP address of your PPTP server.

· In Dial-Up Networking, check your VPN connection to make sure it includes all the protocols used on the target network.

· If the target network uses TCP/IP, check your VPN connection to make sure the TCP/IP settings are correctly configured for the target network.

· If you are making two connections, make sure the second connection is a VPN connection.


PPTP Doesn’t Work After ISDN Installation

If you install an ISDN card after installing PPTP, the ISDN installation procedure might overwrite some of the files from your Dial-Up Networking upgrade. If this happens, you will no longer be able to use PPTP. You will need to remove all Dial-Up Networking components and reinstall your Dial-Up Networking upgrade.

To remove Dial-Up Networking

1. In Control Panel, click Add/Remove Programs.

2. Remove all Dial-Up Networking components.

3. Restart your computer.

To reinstall the Dial-Up Networking upgrade, follow the procedures outlined in “Installing PPTP on a Windows 95-based Client” in the chapter “Installing, Configuring, and Using PPTP with Microsoft Clients and Servers.”

Caution Never remove PPTP components using Network in Control Panel.


Two Dial-Up Networking Adapters Appear in Network in Control Panel

This is by design. Do not attempt to remove Dial-Up Networking components using Network in Control Panel. If you need to remove PPTP, follow the procedures outlined in the procedure “To remove Dial-Up Networking,” in the “PPTP doesn't work after ISDN installation” section.


Cannot Connect To a PPTP Server

If you cannot connect to a PPTP server, check the following items.

Verify That You Are Properly Connected To The Internet

To check that your connection to the Internet is working properly

1. Ping www.microsoft.com.

2. If ping does not reach www.microsoft.com, type:

ping 207.68.156.16

3. If ping succeeds, you are properly connected to the Internet but you are not properly connected to your DNS server.

4. If ping fails, you might not be connected to the Internet. Contact your ISP.

Ping The PPTP Server

Ping the IP address of the PPTP server.

If you receive a response, you are properly connected to the PPTP server, and you might have entered an incorrect user name or password.

If you do not receive a response, the administrator of the PPTP server might have turned on PPTP filtering. This prevents you from pinging the PPTP server. Contact the administrator of the PPTP server.

Check For A Firewall

Firewalls sometimes filter out PPTP packets. Contact your ISP and the administrator of your corporate server and ask if they are using a firewall. If they are, request that they pass TCP port 1723 and IP protocol 47.

Note IP protocol 47 is the Generic Routing Encapsulation (GRE) protocol.

Because PPTP is a secure protocol, adding TCP port 1723 and IP protocol 47 will not affect the security of the firewall.

Make Sure Your ISP Isn’t Filtering Out PPTP

Contact your ISP and ask if it filters out GRE packets. If so, request that it pass GRE protocol 47.

Check For A Proxy Server

It is not possible to create a PPTP tunnel that passes through a proxy server such as a computer running Microsoft Proxy Server. Therefore, if your internal network’s proxy server handles all Internet traffic, including PPTP traffic, you will not be able to create a PPTP tunnel to access resources on the internal network.

However, it is possible to configure a proxy server as a PPTP server in order to securely access resources on the proxy server. It is also possible to set up a secure PPTP connection on a separate computer instead of sending your packets through a proxy server. For more information, contact the administrator of the PPTP server.


Cannot Log On To Target Network

If you can connect to the PPTP tunnel server, but you cannot perform a domain logon to the target network, verify that you have configured the connection to your PPTP server to enable you to perform a domain logon to the target network.

To Verify Your PPTP Configuration

1.In the Dial-Up Networking folder, right-click the icon for your PPTP server connection.

2.Click Properties.

3.Click the Server Types tab.

4.In the Advanced options box, make sure the Log on to the network check box is selected.


PPTP Connection Is Slow

If your PPTP connection is slow, follow the procedures outlined below.

Check Your ISP Connection

You might be able to improve your performance by changing settings in your ISP connection. Follow the steps outlined in the procedure “To verify or edit your ISP connection” in the chapter “Installing, Configuring and Using PPTP with Microsoft Clients and Servers.”

Check The Connection To Other Internet Sites

To check the speed of your Internet connection, ping Internet sites such as www.microsoft.com and www.yahoo.com. If ping shows a response time of more than five seconds, you have a slow Internet connection. Contact your ISP.

Check The Connection To Your PPTP Server

If you do not have problems with your Internet connection, but the connection to your PPTP server is still slow, the PPTP server might be overloaded. Contact the administrator of the PPTP server.

Connect Directly To Network Resources

If you have a slow connection, you might want to connect directly to network resources. To do so, at the command prompt, type:

net use \\server\share

Note You can type either the IP address or the name of the server to which you are connecting. Typing the IP address may enable you to connect to the server more quickly.


Cannot Resolve Names Using DNS

The PPTP Dial-Up Networking upgrade also includes a WinSock upgrade. If you did not upgrade WinSock before upgrading Dial-Up Networking, you might have problems reaching DNS servers. You will need to perform the WinSock upgrade.

To Perform A Winsock Upgrade

1. In Windows Explorer, go to the Windows\Msdun directory.

2. Double-click Wsockupd.exe to start the upgrade program.

Note After you have upgraded WinSock, you may need to reinstall any applications that made modifications to your older version of WinSock.


Cannot See Servers On Your Network

After you make a PPTP connection to a PPTP tunnel server, you might lose connectivity to some of the servers on your network. This is because of the way TCP/IP networks work. Clients on TCP/IP networks can send packets directly to hosts on their immediate network segment. However, to reach other network segments and other networks, they send their packets to a default gateway instead. That default gateway then determines where to send the packets. Thus, clients can send packets to servers anywhere in a very large, complex network without having to know how to reach each server. Figure 3 shows how TCP/IP clients use default gateways.

Figure 3 - Before creating PPTP Tunnel

TCP/IP clients can be configured with several different default gateways. If one default gateway fails, the clients automatically switch to another default gateway. However, TCP/IP clients cannot use more than one default gateway at a time.

Figure 4 shows what happens when you use PPTP to connect to a TCP/IP network. Dial-Up Networking assigns a second default gateway when you make a PPTP connection. Because your client can only use one default gateway, it sends all network traffic through the second gateway. You can no longer access some of the servers that you were able to access before connecting to your PPTP tunnel server.

Figure 4 - After connecting to a PPTP server

You can solve this problem by manually adding routes to destinations on your local network.

Use the route command to manually add a route to the gateway, IP subnet, or IP network you want to reach. For more information about adding routes, see Chapter 12, “Troubleshooting Tools and Strategies,” in the Windows NT Server Networking Guide.

For more information about solving this problem, see the Release Notes included with the Dial-Up Networking upgrade.


Lose Internet Connectivity Or Cannot Use Browser

When you connect to a tunnel server, you might lose connectivity to the Internet. This is because the PPTP tunnel server becomes your default gateway, and your computer no longer uses the default gateway to the Internet. For more information about the default gateway problem and its solution, see the section “Cannot see servers on your network.”

You can solve this problem in one of two ways:

· You can disable the default gateway to the PPTP tunnel server

To Disable The Default Gateway To The PPTP Tunnel Server

1. In the Dial-Up Networking folder, right-click the PPTP server connection icon.

2. Click the Server Types tab.

3. Click TCP/IP Settings.

4. Clear the Use Default Gateway on Remote Networks check box.

5. You may need to configure routes to servers on the remote network.

· You can configure your Web browser’s proxy server settings

Many networks allow access to the Internet through a proxy server. To access Web pages on the Internet, you must configure your Web browser’s proxy server settings as if you were physically connected to the target network. For example, if you are using Internet Explorer, follow the procedure below.

To Configure Internet Explorer Proxy Server Settings

1. Right click the Internet Explorer icon.

2. Click Properties.

3. Click the Connection tab.

4. In the Proxy server box, select Connect through proxy server.

5. In the Proxy server box, click Settings.

6. In the Servers box, add the proxy servers you use on your corporate network. If you do not know these settings, contact your network administrator.


Cannot Connect After Disconnecting From A LAN

You might not be able to connect to some of your network’s hosts after disconnecting a mobile computer such as a laptop from your corporate network, then making a PPTP connection to your corporate network. This happens because your computer is still forwarding all its network traffic to the network adapter instead of over the PPTP connection. To force your computer to forward its network traffic over the PPTP connection, disable your network adapter using the following procedure.

To Disable Your Network Adapter

1. In Control Panel, click System.

2. Click the Device Manager tab.

3. Click Network adapters.

4. Select your network adapter.

5. Click Properties.

6. In the Device usage box, select the Disable in this hardware profile check box.


Introduction

Point-to-Point Tunneling Protocol (PPTP) is a network protocol that enables the secure transfer of data from a remote client to a private enterprise server by creating a virtual private network (VPN) across TCP/IP-based data networks. PPTP supports on-demand, multi-protocol, virtual private networking over public networks such as the Internet.

The networking technology of PPTP is an extension of the remote access Point-to-Point protocol defined in the document by the Internet Engineering Task Force (IETF) titled “The Point-to-Point Protocol for the Transmission of Multi-Protocol Datagrams over Point-to-Point Links,” referred to as RFC 1171. PPTP is a network protocol that encapsulates PPP packets into IP datagrams for transmission over the Internet or other public TCP/IP-based networks. PPTP can also be used in private LAN-to-LAN networking.

The PPTP extension of PPP is explained in the document titled “Point-to-Point Tunneling Protocol ,” PPTP draft-ietf - ppext - pptp - 00.txt. A draft of this document was submitted to the IETF in June, 1996 by the companies of the PPTP Forum, which include Microsoft Corporation, Ascend Communications, 3Com/Primary Access, ECI Telematics, and US Robotics.

Note Internet draft documents should be considered as a “works in progress.” See www.ietf.org for copies of Internet drafts and RFCs mentioned in this document. For more information about PPTP, visit our Web site at http:\\www.microsoft.com\ntserver. See the topic “Network Communications” under “All About...”

This document is for network administrators, support personnel, and developers who need to understand how PPTP can be used to provide low-cost remote access solutions and includes the following topics:

·PPTP and secure, virtual private networking (VPN)

·architecture of PPTP

·PPTP security features


PPTP and Virtual Private Networking

The PPTP protocol is included with the Windows NT® Server version 4.0 and Windows NT Workstation version 4.0 operating systems, and a beta version is available as an add-on for the Windows® 95 operating system. Computers running these operating systems can use the PPTP protocol to securely connect to a private network as a remote access client by using a public data network such as the Internet. In other words, PPTP enables on-demand, virtual private networks over the Internet or other public TCP/IP-based data networks. PPTP can also be used by computers connected to a LAN to create a virtual private network across the LAN.

An important feature in the use of PPTP is its support for virtual private networking through public-switched telephone networks (PSTNs). PPTP simplifies and reduces the cost of deploying an enterprise-wide, remote access solution for remote or mobile users because it provides secure and encrypted communications over public telephone lines and the Internet. PPTP eliminates the need for expensive, leased-line or private enterprise-dedicated communication servers because you can use PPTP over PSTN lines.

Generally, there are three computers involved in every PPTP deployment:

·a PPTP client

·a network access server

·a PPTP server

However, if you are creating a PPTP tunnel between a PPTP client and a PPTP server that are both connected to the same LAN, you do not need a network access server.

The following section describes a typical PPTP scenario using these computers and explains how they relate to each other, It also fully defines each of these components.


Typical PPTP Scenario

A typical deployment of PPTP starts with a remote or mobile PPTP client that uses a local Internet Service Provider (ISP) to access a private enterprise LAN. This PPTP client can be running either Windows NT Server version 4.0, Windows NT Workstation version 4.0, or Windows 95 operating systems.

A PPTP client must make two connections to establish a PPTP tunnel. Figure 1 shows these connections. The client first uses Dial-Up Networking and the remote access protocol, PPP, to connect to a network access server (NAS) at an ISP facility. Once connected, the client can send and receive packets over the Internet. The network access server uses the TCP/IP protocol for all traffic to the Internet.

Note Network access servers are also referred to as front-end processors (FEPs), dial-in servers or point-of-presence (POP) servers.

The client then uses Dial-Up Networking to make a second logical connection over the existing PPP connection. Data sent using this second connection is in the form of IP datagrams that contain PPP packets, referred to as encapsulated PPP packets.

The second connection creates the virtual private networking (VPN) connection to a PPTP server on the private enterprise LAN (a computer running Windows NT Server version 4.0 and configured as a PPTP server). This connection is referred to as a tunnel.

Figure 1 - Creating a PPTP tunnel

Tunneling is the process of sending packets to a computer on a private network by routing them over some other network, such as the Internet. The other network’s routers cannot access computers on the private network. However, tunneling enables the routing network to transmit the packet to an intermediary computer, a PPTP server that is connected to the both the routing network and the private network. Both the PPTP client and the PPTP server use tunneling to securely route packets to a computer on the private network by using routers that only know the address of the private network intermediary server.

When the PPTP server receives the packet from the routing network, it sends it across the private network to the destination computer. The PPTP server does this by processing the PPTP packet to obtain the private network computer name or address information in the encapsulated PPP packet. Note that the encapsulated PPP packet can contain multi-protocol data such as IP, IPX, or NetBEUI protocols. Because the PPTP server is configured to communicate across the private network by using private network protocols, it is able to read multi-protocol packets.

The following figure illustrates the multi-protocol support built into PPTP. A packet sent from the PPTP client to the PPTP server passes through the PPTP tunnel to a destination computer on the private network.

Figure 2 - Connecting a Dial-Up Networking PPTP client to the private network

PPTP encapsulates the encrypted and compressed PPP packets into IP datagrams for transmission over the Internet. The IP datagrams are created using a modified version of the Internet Generic Routing Encapsulation (GRE) protocol. (GRE is defined in RFCs 1701 and 1702).These IP datagrams are routed over the Internet until they reach the PPTP server that is connected to both the Internet and the private network. The PPTP server disassembles the IP datagram into a PPP packet and then decrypts the PPP packet using the network protocol of the private network. As mentioned earlier, the network protocols on the private network that are supported by PPTP are IPX, NetBEUI, and TCP/IP.


PPTP Clients

A computer, such as a Microsoft client, that supports the PPTP network protocol can connect to a PPTP server in two ways:

·by establishing a dial-up IP connection to an ISP’s network access server

·by an IP-enabled LAN connection

PPTP clients that use an ISP’s network access server must be configured with a modem, a PPTP driver, and a VPN device to make the separate connections to the ISP and the PPTP server. The first connection is a dial-up connection using the PPP protocol over the modem to an Internet service provider. The second connection is a VPN connection using PPTP, over the modem and the ISP connection, to tunnel across the Internet to a VPN device on the PPTP server. The second connection requires the first connection because the tunnel between the VPN devices is established by using the modem and PPP connection to the Internet.

In contrast to PPTP clients that use an ISP’s network access server, clients that use an IP-enabled LAN connection need only be configured with a PPTP driver and a VPN device. Because they are already connected to the LAN, they only need to make one connection: they must use a VPN device to create a connection to a PPTP server on a LAN.


PPTP-enabled Network Access Servers at an ISP

The previous section describes how a PPTP-enabled dial-up client establishes a PPTP tunnel with a PPTP server. Dial-up clients that are not PPTP-enabled can also take advantage of PPTP by connecting to a PPTP-enabled network access server. The network access server then establishes the PPTP connection to a PPTP server.

In this scenario, the dial-up client can be a Windows 95-based, Windows NT-based, Apple Macintosh, or UNIX client. The architecture described in this document is fundamentally the same; however, all PPTP communication occurs between the network access server and the PPTP server.

PPTP-enabled ISP network access servers are designed and built to accommodate a high number of dial-in clients. Such network access servers are built by companies such as 3Com, Ascend Communications, ECI Telematics, and U.S. Robotics, all members of the PPTP Forum.

Contact your ISP to see if they provide a PPTP service and how you need to configure PPP and Dial-Up Networking to access the ISP server that supports PPTP.


PPTP Servers on the Private LAN

PPTP servers are servers with routing capabilities that are connected to a private network and to the Internet. In this document, a PPTP server is defined as a computer running Windows NT Server version 4.0 and RAS. PPTP is installed as a network protocol. During installation, PPTP is configured by adding virtual devices referred to as virtual private networks (VPNs) to RAS and Dial-Up Networking configurations. For more information about PPTP server installation requirements, see the document “Installing, Configuring, and Using PPTP with Microsoft Clients and Servers.”


PPTP Architecture

This section provides information about the architecture of PPTP under Windows NT Server version 4.0, Windows NT Workstation version 4.0, or Windows 95. PPTP is designed to provide a secure method for reaching private networks over the Internet.

This section describes:

·the PPP protocol

·PPTP control connection

·PPTP data tunneling


PPTP Architecture Overview

The secure communication created using the PPTP protocol typically involves three processes, each of which requires successful completion of the previous process. This document explains these three processes and how they work:

PPP Connection and Communication. A PPTP client uses PPP to connect to an ISP by using a standard telephone line or ISDN line. This connection uses the PPP protocol to establish the connection and encrypt data packets.

PPTP Control Connection. Using the connection to the Internet established by the PPP protocol, the PPTP protocol creates a control connection from the PPTP client to a PPTP server on the Internet. This connection uses TCP to establish the connection and is a called a PPTP tunnel.

PPTP Data Tunneling. Finally, the PPTP protocol creates IP datagrams containing encrypted PPP packets which are then sent through the PPTP tunnel to the PPTP server. The PPTP server disassembles the IP datagrams and decrypts the PPP packets, and then routes the decrypted packets to the private network..


PPP Protocol

PPP is a remote access protocol used by PPTP to send multi-protocol data across TCP/IP-based networks. PPP encapsulates IP, IPX, and NetBEUI packets between PPP frames and sends the encapsulated packets by creating a point-to-point link between the sending and receiving computers.

Most PPTP sessions are started by a client dialing up an ISP network access server. The PPP protocol is used to create the dial-up connection between the client and network access server and performs the following three functions:

·Establishes, maintains, and ends the physical connection. The PPP protocol uses a sequence defined in RFC 1661 to establish, maintain, and end connections between remote computers.

·Authenticates users. PPTP clients are authenticated by using the PPP protocol. Clear text, encrypted, or Microsoft encrypted authentication can be used by the PPP protocol.

·Creates PPP datagrams that contain encrypted IPX, NetBEUI, or IP packets. PPP creates datagrams which contain one or more encrypted IP, IPX, or NetBEUI data packets. Because the network packets are encrypted, all traffic between a PPP client and a network access server is secure.

This entire process is illustrated in the following figure.

Figure 3 - Creating a Dial-Up Networking PPP connection to an ISP


PPTP Control Connection

The PPTP protocol specifies a series of control messages sent between the PPTP-enabled client and the PPTP server. The control messages establish, maintain and end the PPTP tunnel. The following list presents the primary control messages used to establish and maintain the PPTP tunnel.

Message Type

Purpose
PPTP_START_SESSION_REQUEST | Starts session
PPTP_START_SESSION_REPLY | Replies to start session request
PPTP_ECHO_REQUEST | Maintains session
PPTP_ECHO_REPLY | Replies to maintain session request
PPTP_WAN_ERROR_NOTIFY | Reports an error on the PPP connection
PPTP_SET_LINK_INFO | Configures the connection between client and PPTP server
PPTP_STOP_SESSION_REQUEST | Ends session
PPTP_STOP_SESSION_REPLY | Replies to end session request

Table 1 - PPTP Control Message Types

Control messages are transmitted in control packets in a TCP datagram. One TCP connection is created between the PPTP client and the PPTP server. This connection is used to exchange control messages. A datagram contains an IP header, a TCP header, a PPTP control message, and appropriate trailers, similar to the following:

Figure 4 - PPTP TCP Datagram with Control Messages

The exchange of messages between the PPTP client and the PPTP server over the TCP connection are used to create and maintain a PPTP tunnel. This entire process is illustrated below:

Figure 5 - PPTP Control Connection to PPTP Server Over PPP Connection to ISP

Note that in this illustration, the control connection is for the scenario in which the remote access client is the PPTP client. In the scenario in which the remote access client is not PPTP-enabled and uses a PPTP-enabled ISP network access server, the PPTP control connection begins at the ISP server.


PPTP Data Transmission

After the PPTP tunnel has been established, user data is transmitted between the client and PPTP server. Data is transmitted in IP datagrams containing PPP packets. The IP datagrams are created using a modified version of the Internet GRE protocol. (GRE is defined in RFCs 1701 and 1702.) The IP datagram created by PPTP is similar to the illustration in the following figure.

Figure 6 - IP datagram containing encrypted PPP packet›

The IP delivery header provides the information necessary for the datagram to traverse the Internet. The GRE header is used to encapsulate the PPP packet within the IP datagram. The PPP packet was created by RAS. Note that the PPP packet is just one unintelligible block because it is encrypted. Even if the IP datagram were intercepted, it would be nearly impossible to decrypt the data.


Understanding PPTP Security

PPTP extends the strict authentication and encryption security available to computers running RAS under Windows NT Server version 4.0, Windows NT Workstation version 4.0, or Windows 95 to PPTP clients on the Internet. PPTP also can protect the PPTP server and private network by ignoring all but PPTP traffic. Despite the strict security, it is very simple to use PPTP with existing firewalls. This section will help you understand and plan the following:

·authentication

·access control

·data encryption

·PPTP packet filtering

·using third-party firewalls


Authentication

Initial dial-in authentication may be required by an ISP network access server. If this authentication is required, it is strictly to log on to the ISP network access server; it is not related to Windows NT-based authentication. Check with your ISP for their authentication requirements. You apply these requirements in the Dial-Up Networking configurationfor that ISP.

On the other hand, the PPTP tunnel server controls all access to your private network. That is, the PPTP server is a gateway to your private network. The PPTP server requires a standard Windows NT-based logon. All PPTP clients must supply a user name and password. Therefore, remote access logon using a computer running Windows NT Server version 4.0, Windows NT Workstation version 4.0, or Windows 95 is as secure as logging on from a Windows-based computer connected to the local LAN.

Authentication of remote PPTP clients is done by using the same PPP authentication methods used for any RAS client dialing directly to a RAS server. Microsoft’s implementation of RAS supports the Challenge Handshake Authentication Protocol (CHAP), the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and the Password Authentication Protocol (PAP) authentication schemes.

Note MS-CHAP authentication supports the MD4 hash as well as the earlier authentication scheme used in Microsoft LAN Manager.

As with all user accounts, the user accounts of remote users reside in the Windows NT Server version 4.0 directory and are administered through User Manager for Domains. This provides centralized administration that is integrated with the private network’s existing user accounts. Only accounts that have been granted specific access to the network through a trusted domain are permitted. Careful management of user accounts is necessary to reduce security risks.

Having a secure password model in place is critical to successful deployment of PPTP because Internet connections are more susceptible to speed or “demon dialer” programs, which can literally crunch through thousands of password and username combinations.

The only way to minimize this type of attack is to implement secure password policies. Passwords should be difficult to guess. For example, you can require that passwords contain uppercase letters, lowercase letters, numbers, and special characters. It is recommended that you require at least three different types of characters to ensure password uniqueness.


Access Control

After authentication, all access to a private LAN continues to use the Windows NT-based security model. Access to resources on NTFS drives, or to other network resources requires the proper permissions. It is recommended that the NTFS file system is used for file resources that are accessed by PPTP clients.

For more information about using security on NTFS drives or other network resources, see your product documentation or the Windows NT Workstation version 4.0, Windows NT Server version 4.0, or Windows 95 Resource Kits.


Data Encryption

For data encryption, PPTP uses the Remote Access Server (RAS) “shared-secret” encryption process. It is referred to as a shared-secret encryption process because both ends of the connection share the encryption key. Under the Microsoft implementation of RAS, the shared secret is the user password. (Other encryption methods base the encryption on some key available in public; this second method of encryption is known as public key encryption.)

PPTP uses the PPP encryption and PPP compression schemes. The Compression Control Protocol (CCP) used by PPP is used to negotiate encryption.

The user name and password of the PPTP client is available to the PPTP server and supplied by the PPTP client. An encryption key is derived from the hashed password stored on both the client and server. The RSA RC4 standard is used to create this 40-bit session key based on the client password. This key is used to encrypt all data that is passed over the Internet, keeping the remote connection private and secure.

The data in PPP packets is encrypted. The PPP packet containing a block of encrypted data is then encapsulated into a larger IP datagram for routing over the Internet to the PPTP server. If an Internet hacker intercepted your IP datagram, he or she would find only media headers, IP headers, and then the PPP packet containing a block of encrypted data. It would be indecipherable.

Note Users in the United States and Canada can obtain a 128-bit session key through a cryptography pack for use inside the US. Contact your Microsoft reseller for more information.


PPTP Packet Filtering

Network security from malicious activity can be enhanced by enabling PPTP filtering on the PPTP server. When PPTP filtering is enabled, the PPTP server on the private network accepts and routes only PPTP packets from authenticated users. This prevents all other packets from entering the PPTP server and private network. In conjunction with PPP encryption, this ensures that only authorized encrypted data enters or leaves the private LAN.

PPTP filtering is enabled on the PPTP server using the Protocols tab in the Network option of Control Panel. For step-by-step instruction on enabling PPTP filtering, see the white paper titled “Installing, Configuring, and Using PPTP with Microsoft Clients and Servers.”


Using PPTP with Firewalls and Routers

PPTP traffic uses TCP port 1723, and IP protocol uses ID 47, as assigned by the Internet Assigned Numbers Authority (IANA). PPTP can be used with most firewalls and routers by enabling traffic destined for TCP port 1723 and protocol 47 to be routed through the firewall or router.

Firewalls ensure corporate network security by strictly regulating data that comes into the private network from the Internet. An organization can deploy a PPTP server running Windows NT Server version 4.0 behind its firewall. The PPTP server accepts PPTP packets passed to the private network from the firewall and extracts the PPP packet from the IP datagram, decrypts the packet, and forwards the packet to the computer on the private network.


Web Capacity Analysis Tool

User Guide

Microsoft® Web Capacity
Analysis Tool

Version 3.1

Windows NT® Operating System

Microsoft Corporation

Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation.

© 1985-1997 Microsoft Corporation. All rights reserved.

Microsoft, the Microsoft logo, Microsoft Press, the Microsoft Press logo, Windows, the Windows logo, and Windows NT are registered trademarks of Microsoft Corporation in the USA and other countries.

Microsoft may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft.

Document No.xxxx
12345-6

Printed in the United States of America.


Introduction

This guide provides the information you need to install, configure, and run the Microsoft® Web Capacity Analysis Tool (WCAT). The Microsoft Web Capacity Analysis Tool is included on the Microsoft Windows NT® Server Resource Kit Version 4 Supplement 1 CD-ROM.

The Microsoft Web Capacity Analysis Tool User Guide includes the following sections:

  • “WCAT: A Tool to Test IIS Server and Client Capacity”

  • “Components of a WCAT Test”

  • “WCAT Prepared Tests”

  • “Before Installing WCAT”

  • “Installing WCAT”

  • “Verifying the WCAT Installation”

  • “Running WCAT”

  • “Using Performance Monitor Counters in a WCAT Test”

  • “Analyzing the WCAT Log”

  • “Designing Custom Tests”

The Microsoft Web Capacity Analysis Tool (WCAT) and the Microsoft Web Capacity Analysis Tool User Guide are provided “as is” without warranty of any kind. For details, see “Resource Kit Support Policy” in the introduction to the Supplement 1 book.


WCAT: A Tool to Test IIS Server and Client Capacity

The Microsoft Web Capacity Analysis Tool (WCAT) runs simulated workloads on client-server configurations. Using WCAT, you can test how your Internet Information Server and network configuration respond to a variety of different client requests for content, data, or Hypertext Markup Language (HTML) pages. The results of these tests can be used to determine the optimal server and network configuration for your computer running Microsoft Windows NT Server version 4.0 with Microsoft Internet Information Server (IIS) version 2.0 or 3.0. WCAT is specially designed to evaluate how Internet servers running Windows NT Server and Internet Information Server respond to various client workload simulations.

You can test different server and network configurations by using the prepared WCAT content and workload simulations. When you change your hardware and software configuration and repeat the prepared tests, you can identify how the new configuration affects server response to the simulated client workload. You can use WCAT to test servers with single or multiple processors and to test servers that are connected to multiple networks.

The Web Capacity Analysis Tool provides the following features:

  • Prepared, ready-to-run workload simulations to test the most common aspects of server performance. These simulations provide World Wide Web content files of varying sizes to test your server’s response to different workloads.

  • Prepared workload simulations to test the response of your server to Internet Server Application Programming Interface (ISAPI) extensions and Common Gateway Interface (CGI) applications. You can run these simulations even if your server does not currently run any ISAPI extensions or CGI applications.

  • Prepared workload simulations to test the response of your server to Secure Sockets Layer (SSL) version 2.0 encryption.

  • Prepared workload simulations to test the response of your Hypertext Transport Protocol (HTTP) service to HTTP keep-alives. HTTP keep-alives are an optimizing feature of servers and browsers; an HTTP keep-alive maintains a client connection after the initial request is satisfied. HTTP keep-alives are part of the HTTP version 1.1 specification.

  • The ability to create and run your own client-server workload simulations.

  • The ability to use cookies, a technology supported by some Web sites. Cookies are a means by which, under the HTTP protocol, a server or script can maintain state information on the client workstation. Cookies are usually used to provide Web site customization features.

  • The ability to test servers connected to more than one network.


Components of a WCAT Test

WCAT tests monitor the response of an Internet or intranet server to the demands of its clients in a controlled experimental setting. WCAT tests simulate the activity of a Internet Information Server and its many client Web browsers communicating across one or more networks.

A WCAT test includes four primary components: a server, a client, a controller, and the network. During a WCAT test, each of these components runs a different WCAT program. This section describes these components and the programs they run.

Figure 1 shows the components of a single-network WCAT test.

Figure 1 The components of a single-network WCAT test


Components of a WCAT Test

The WCAT Server

The WCAT server is a computer configured with Windows NT Server and Internet Information Server. The WCAT server uses prepared sample content files that simulate those that a server might provide its clients. The prepared content files simulate Web pages of varying lengths. A particular set of prepared content files is associated with a particular WCAT test.

You can investigate server performance by subjecting the server to a wide variety of client demands by varying which prepared test is run. Alternatively, you can test the effectiveness of changes to server hardware and software by repeatedly running the same prepared test after hardware and software changes.

In a WCAT test, the server:

  • Responds to requests for connections.

  • Establishes, manages, and terminates connections.

  • Receives requests for Web content.

  • Processes client requests and sends responses.


The WCAT Client

The WCAT client consists of one or more computers running the WCAT client application. The prepared tests provided with WCAT are configured to run with one client computer. If you want to run more than one client computer, see “Changing Client Workloads,” later in this guide.

The WCAT client application runs in a single, multithreaded process. Each thread in the process represents a virtual client. Each virtual client simulates one connection and page request to the WCAT server. This design enables each client computer to simulate more than one client. WCAT can support up to 200 virtual clients in each WCAT test.

Note

Many Web browsers can start multiple simultaneous connections. Therefore, the number of threads used by a WCAT client application does not necessarily bear a direct correlation to the number of client Web browsers connected.

In a WCAT test, you specify what level of client demand the server is subject to, including:

· The number of client browsers in the test.

· The size and type of pages the clients request.

· The rate at which clients send requests.

· The relative frequency at which different specific pages are requested.

· The duration of the test.


The WCAT Controller

The WCAT controller is a computer running the WCAT controller application. The controller is provided to minimize the effect of test administration on test results; it does so by separating the computer administering the test from the computers being tested. The controller hardware and software are not monitored as part of a WCAT test.

The WCAT controller application initiates and monitors a WCAT test by using three input files, described following. When the test is over, the controller application collects the test results and writes output files showing these test results.

Controller Input Files

The input files provide complete instructions for a WCAT test and are stored on and interpreted by the controller computer. You can either run WCAT with the controller input files provided with WCAT or design your own tests by creating new or modified input files.

You can use any word processor or text editor to view or edit the input files. There are three standard input files for each WCAT test:

· A configuration file, which specifies test conditions, such as the duration of the test, the number of client computers, and the number of virtual clients for each client computer active during the test. A configuration file has the filename testname.cfg, where testname is the name of the test connected with that configuration file.

· A script file, which specifies the Web pages clients request from the server during the test and the Web files that make up those pages. In a script file, the Web pages are organized into classes by type. For example, static pages are in a different class than pages generated by CGI applications or ISAPI extensions. During a test, the virtual clients choose from among the pages in a class; allowing the clients to choose pages better simulates actual request patterns than assigning pages to clients does. For more information on classes, see “Class Statistics Section,” later in this guide. A script files has the filename testname.scr, where testname is the name of the test connected with that script file.

· A distribution file, which specifies the frequency at which the pages in the script file are requested from the server. The controller uses the distribution file to develop its instructions to the clients. For more information on distribution files, see “Modifying the Distribution File,” later in this guide. A distribution file has the filename testname.dst, where testname is the name of the test connected with that distribution file.

· A performance counter file, an optional file that specifies any Performance Monitor counters and objects on the server that the controller should monitor during the test. For more information on using Performance Monitor during a WCAT test, see “Using Performance Monitor Counters in a WCAT Test,” later in this guide. A performance counter file has a filename testname.pfc, where testname is the name of the test connected with that performance counter file.

For a description of the test parameters defined in the input files, see “Modifying the Controller Input Files,” later in this guide.

Controller Output Files

During a test, WCAT collects statistics on the activity of the clients and the response of the server and produces detailed reports for later analysis. The statistics are collected by the WCAT controller in the output files.

The controller writes the output files based on data gathered by the controller and clients. WCAT produces two types of output files:

· A log file, which includes reports and analysis of the statistical data gathered during the test. The log file is a comma-separated, variable-length file designed for use as input for a spreadsheet or data processing program. You can also use any text editor or word processor to view and edit the log file. For a full description of log files, see “Analyzing the WCAT Log,” later in this guide. A log file has the filename testname.log, where testname is the name of the test connected with that log file.

· A performance results file, which presents the data collected from Performance Monitor counters on the server computer during the test. WCAT produces a performance results file only if you run WCAT with the performance counter option (-p). For a description of the performance results file, see “Interpreting a Performance Results File,” later in this guide. A performance results file has the filename testname.prf, where testname is the name of the test connected with that performance results file.


The WCAT Controller

The Network

In this guide, the network refers to the communications links between the client computers, the controller computer, and the server computer during a WCAT test. You can choose to test the performance of the network as part of a WCAT test. Alternatively, you can provide ideal network conditions so changes in network bandwidth or traffic do not affect test results and so you can focus on testing server and client conditions.


WCAT Prepared Tests

WCAT includes more than 30 prepared, ready-to-run tests you can run to simulate different workloads on your client-server configuration. You can also design and run your own WCAT tests. For information on designing WCAT tests, see “Designing Custom Tests,” later in this guide.

You specify the test you have chosen by typing its name after the WCAT run command at the command line on the WCAT controller. For more information on using the run command, see the procedure “To start a WCAT controller” and the section “Using Command Line Options,” later in this guide.

Files for the WCAT tests are placed the \Scripts directory on the WCAT controller when you install WCAT. You can use any word processing program or text editor, such as Wordpad, to examine these files. You can run the tests as they are or edit the test files to customize the tests.

There are four types of WCAT tests:

· Basic tests. These tests monitor the response of servers performing different tasks involving static Web pages. Table 1, in the following section, lists and describes the basic tests included with WCAT.

· CGI and ISAPI tests. These tests monitor the response of the server when it is generating Web pages dynamically by using CGI applications or ISAPI extensions. Table 2, later in this guide, lists and describes the CGI and ISAPI tests.

· HTTP keep-alive tests. These tests are modified versions of the basic tests and CGI and ISAPI tests. In the HTTP keep-alive version of each test, the clients request that the HTTP keep-alive feature be activated for the connection.

· SSL tests. SSL tests are modified versions of the basic tests and CGI and ISAPI tests. In the SSL version of each test, the client and server use the Secure Socket Layer (SSL) encryption protocol.

Note

WCAT does not support HTTP keep-alives and SSL in the same test.

The following sections describe these tests.


Basic Tests

Table 1 lists and describes the basic tests provided with WCAT.

Table 1 Basic WCAT Tests

Name of test | Description
1K | Tests the response of the server to repeated requests for the same 1 kilobyte (K) file. This test can be used to monitor how the server uses the Internet Information Server (IIS) Object Cache and the file system cache.
Clntload Tests the response of the server to an increasing number of clients.

The test begins with the minimum number of client computers requesting a single 1K file. As the test progresses, more client computers are added, each requesting the same 1K file, until the maximum number of client computers is reached. The minimum and maximum numbers of client computers and the number of client computers added in each increment of this test are specified in the Clntload test’s configuration file, Clntload.cfg.

By default, Clntload begins with 4 client computers and increases the number of clients by 4 in each successive run until the maximum of 24 clients is reached. Each client computer runs five virtual clients.
1ktest01 | Tests the response of the server to a typical workload. In this test, clients request 12 files ranging in size from 256 bytes to 256K. The average page size for this test is about 10K, which is commonly observed on most servers on the Internet. The size of the test files and the pattern and frequency of requests for them (that is, their distribution) were chosen by surveying actual client workloads on proxy servers.
1ktest01.50m Tests the response of the server to a typical moderately large workload. In this test, clients request 14 files residing in multiple directories and ranging in size from 256 bytes to 1 megabyte (MB). The total workload is approximately 50 MB. The size of the test files and frequency of requests for them were chosen by surveying actual workloads on proxy servers.

If the file system cache on the server computer cannot contain all the files in this workload, the server spends more time reading the files from disk. Increase the server memory or adjust your performance expectations accordingly. For more information on analyzing Internet Information Server performance, see Chapters 5 through 9 of the Microsoft Windows NT Server Resource Kit Version 4 Supplement 1 book.

Table 1 Basic WCAT Tests (Continued)

Name of test | Description
1ktest01.200m | Tests the response of the server to a typical very large workload. In this test, clients request 14 files from 200 different directories. The files range in size from 256 bytes to 1 MB. The total workload is approximately 200 MB. The size of the files and frequency of requests for them were chosen by surveying actual workloads on proxy servers. If the file system cache on the server computer cannot contain all the files in this workload, the server will be occupied with reading files from disk. Increase the server memory or adjust your performance expectations accordingly.
Sample | Tests the response of the server to a variety of different tasks. The workload consists of a set of files that are retrieved by using different types of requests, including standard GET requests, HTTP keep-alive connections, and SSL encryption requests.
WebStone | Tests the response of the server to the workload used in the WebStone version 1.1 benchmark test. In this test, clients request 18 files ranging in size from 1K to 200K. WebStone is an open benchmark developed by Silicon Graphics, Inc., to measure Web server performance. For more information about WebStone, see: http://www.sgi.com/Products/WebFORCE/WebStone/


Table 2 CGI and ISAPI Tests

Name of test | Description
CGI25 | Tests the response of the server to a CGI application. In this test, 25 percent of client requests are for files that require processing by a CGI application. The remaining 75 percent of client requests are taken from the 1ktest01 test, described in Table 1.
CGI50 | Tests the response of the server to a CGI application. In this test, 50 percent of client requests are for files that require processing by a CGI application. The remaining 50 percent of client requests are taken from the 1ktest01 test.
CGI75 | Tests the response of the server to a CGI application. In this test, 75 percent of client requests are for files that require processing by a CGI application. The remaining 25 percent of client requests are taken from the 1ktest01 test.
ISAPI25 | Tests the response of the server to an ISAPI extension. In this test, 25 percent of client requests are for files that require processing by an ISAPI extension. The remaining 75 percent of client requests are taken from the 1ktest01 test.
ISAPI50 | Tests the response of the server to an ISAPI extension. In this test, 50 percent of client requests are for files that require processing by an ISAPI extension. The remaining 50 percent of client requests are taken from the 1ktest01 test.
ISAPI75 | Tests the response of the server to an ISAPI extension. In this test, 75 percent of client requests are for files that require processing by an ISAPI extension. The remaining 25 percent of client requests are taken from the 1ktest01 test.


HTTP Keep-Alive Tests

HTTP keep-alive tests are modified versions of the basic, CGI, and ISAPI WCAT tests. During HTTP keep-alive tests, clients request the same files at the same rates as in the standard versions of the tests but request their connections be maintained by using the HTTP keep-alive feature. HTTP keep-alive tests are used to measure the effect of HTTP keep-alives.

HTTP keep-alives are enabled by default in HTTP version 1.1. HTTP implements keep-alives to avoid the substantial cost of establishing and terminating connections. Both the WCAT client and server must support HTTP keep-alives.

The HTTP keep-alive versions of the WCAT tests are named Ka.testname, where testname represents the name of the standard version of the test. For example, the HTTP keep-alive version of the CGI25 test is called Ka.CGI25. HTTP keep-alive versions are provided for all WCAT tests except for 1K, 1ktest01.50m, and 1ktest01.200m.

SSL Tests

SSL tests are modified versions of the basic, CGI, and ISAPI WCAT tests. During SSL tests, clients request the same files at the same rates as in the standard versions of the tests but use Secure Sockets Layer (SSL) encryption protocol. SSL tests are provided to help you measure the effect of SSL encryption on server performance.

SSL versions of the WCAT tests are named Ssl.testname, where testname represents the name of the standard version of the test. For example, the SSL version of the Cgi25 test is called Ssl.cgi25. SSL versions are provided for all WCAT tests except for 1K, 1ktest01.50m, and 1ktest01.200m.


SSL Tests

SSL tests are modified versions of the basic, CGI, and ISAPI WCAT tests. During SSL tests, clients request the same files at the same rates as in the standard versions of the tests but use Secure Sockets Layer (SSL) encryption protocol. SSL tests are provided to help you measure the effect of SSL encryption on server performance.

SSL versions of the WCAT tests are named Ssl.testname, where testname represents the name of the standard version of the test. For example, the SSL version of the Cgi25 test is called Ssl.cgi25. SSL versions are provided for all WCAT tests except for 1K, 1ktest01.50m, and 1ktest01.200m.


Before Installing WCAT

WCAT is very flexible. You can run WCAT tests on a variety of client-server-network configurations. The following sections describe the minimum hardware and software requirements for a WCAT test. The sections also discuss recommended configurations.

WCAT requires different hardware and software for each component of a WCAT test. The following sections list the hardware and software requirements by test component.


Server Requirements

A WCAT server must consist of the following hardware and software:

· A computer running Windows NT Server 4.0.

· At least 220 MB of unused space on the computer’s hard disks. This disk space is required for the prepared WCAT server files. If you plan to use larger files in your WCAT test, allow more unused disk space.

· Transmission Control Protocol/Internet Protocol (TCP/IP) installed and bound to the adapter connected to the network on which the WCAT test is run. For more information on installing and binding TCP/IP, see the topic “TCP/IP Procedures” in Control Panel Help.


Client Requirements

A WCAT client must consist of the following hardware and software:

· A computer running Windows NT Server 4.0, Windows NT Workstation version 4.0, or Windows 95

· 8 MB of physical memory (RAM)

· 1 MB of unused space on the computer’s hard disks

· TCP/IP installed and bound to the adapter connected to the network on which the WCAT test is run


Controller Requirements

A WCAT controller must consist of the following hardware and software:

· A computer running Windows NT Server 4.0 or Windows NT Workstation 4.0

· 16 MB of physical memory (RAM)

· 10 MB of unused space on the computer’s hard disks

· TCP/IP installed and bound to the adapter connected to the network on which the WCAT test is run


Network Requirements

A TCP/IP-based network with a minimum network bandwidth of 100 megabits per second is recommended for running WCAT. During a WCAT test, the controller and clients communicate by using Windows Sockets in conjunction with Transmission Control Protocol (TCP).

A small network bandwidth is likely to affect the results of the test. Also, before running a WCAT test verify that the network adapters on all participating computers are working properly and that they do not limit the performance of the computers’ connections to the network.


Recommended Configuration for WCAT Tests

This section discusses some issues that often arise when configuring a WCAT test environment. It also recommends hardware and software configurations that are likely to provide accurate, repeatable results from most WCAT tests. These include:

· The optimal amount of physical memory for the WCAT server.

· The best network configuration for a WCAT test.

· The recommended number of virtual clients for a WCAT test.

To determine the most appropriate configuration for your system, repeat several different WCAT tests under different conditions. Vary the speed and number of processors, the amount of physical memory, the available hard disk space and disk configuration, and network bandwidth and traffic. Also, vary the number and speed of the client computers and the number of virtual clients run on each client computer. Repeat the tests to eliminate any one-time performance limitations that are not specific to the WCAT tests.

Server Memory

The amount of physical memory in your server computer can limit the performance of your Internet Information Server and cause excessive disk operations. Unless you are testing how different amounts of memory affect the performance of your server, make sure that your system has sufficient memory for your configuration. It is recommended that the Internet Information Server should have enough physical memory to contain all static content pages involved in the test simultaneously.

For more information on the physical memory requirements of an Internet Information Server, see Supplement 1, Chapter 5, “Monitoring Virtual Memory.”

Network Conditions

A network with limited bandwidth or substantial traffic might limit the performance of your server. Depending on your goals for the WCAT tests, you can include a network with limited bandwidth or provide ideal network conditions so the network is not a factor in the test.

To provide ideal network conditions, dedicate a network to the WCAT tests.

If a limited bandwidth is part of your test, there is no single set of recommended bandwidth requirements for the WCAT tests. In this case, you might want to simulate a busy or limited network. To simulate different network conditions, you can use the IIS Bandwidth Throttler to change the bandwidth available to Internet Information Server. For more information about the Bandwidth Throttler, see “Limiting Bandwidth” in Supplement 1, Chapter 7, “Monitoring Bandwidth and Network Capacity.”

Number of Clients

You can use WCAT to simulate varying client conditions. You can vary the number of client computers in the test, the number of virtual clients running on each client computer, and the rate at which the clients send requests to the server.

To determine the maximum load the server can handle, it is recommended that you use four or more client machines, each running three or more virtual clients, in your WCAT tests. The processors in the client computers should be at least as fast as the processors in the server computer. If the client processors are not as fast as the server processors, more client computers should be associated with each server computer.


Expanding the WCAT Files

The Microsoft Web Capacity Analysis Tool is packaged as a single, self-extracting executable file called Wcat.exe. Wcat.exe contains all the files related to the Web Capacity Analysis Tool.

To expand Wcat.exe

1.On the server computer, click Start, select Programs, and click Command Prompt.

2.At the command prompt for drive C, type mkdir\websrvr to create a new directory called \Websrvr on drive C.

3.At the command prompt, type cd websrvr to go to the \Websrvr directory.

4.Copy Wcat.exe from the Microsoft Windows NT Server Resource Kit Version 4 Supplement 1 CD-ROM to \Websrvr.

5.At the command prompt, type wcat.

Wcat.exe expands to the following files:

· Server.exe

· Ctrler.exe

· Client.exe

These three files are also self-extracting files. In the course of installing WCAT, you access these files from different computers and extract more files from them.

Note

If after installing the WCAT files you want to remove the files, simply delete all associated files and directories. There is no Uninstall application for WCAT.


Installing WCAT on the Server Computer

The following procedures install the WCAT server application and files on the server computer. The WCAT server files include the prepared test content files the server sends in response to clients requests during standard WCAT tests.

There are two steps to installing the WCAT server application:

1.Determining where the Internet Information Server Home and Scripts directories are located on your server.

2.Installing the WCAT server files in the Home and Scripts directories.

Determining the Location of the Home and Scripts Directories

To install WCAT on the server computer, you need to install files to the directories designated as Home and Scripts in your installation of Internet Information Server. Therefore, the first step in installing the WCAT server application is to determine where the Home and Scripts directories for Internet Information Server are located on your server.

The following are the default Home and Scripts directories for Internet Information Server.

Default Home directory | C:\InetPub\Wwwroot
Default Scripts directory | C:\InetPub\Scripts

To determine the Home and Scripts directories for your server

1.On the server computer, start Internet Service Manager.

2.Open the WWW Service Properties dialog box.

  1. Click the Directories tab.

    The Home directory is identified by <Home> in the Alias column. The Scripts directory is identified by /Scripts in the Alias column. The following figure shows the Home and Scripts directories in the WWW Service Properties dialog box.

    Figure 2 Home and Scripts directories in the WWW Service Properties dialog box

Installing the WCAT Server Files

After you have determined where the Home and Scripts directories are located, you can install the WCAT server files to these directories.

To install WCAT on the server computer

1.Click Start, select Programs, and click Command Prompt.

2.At the command prompt for drive C, type cd websrvr to go to the C:\Websrvr directory.

3.At the command prompt, type server to extract the server program and prepared content files.

4.Type install HomeDirectory ScriptsDirectory where HomeDirectory is the full path to the Home directory for your server and ScriptsDirectory is the full path to the Scripts directory for your server.

This command extracts and installs approximately 211 MB of simulated content files into the specified directories.

5.Type net share websrvr=c:\websrvr.

This command shares the \Websrvr directory so the controller and client computers can connect to it.


Installing WCAT on the Controller Computer

The following procedure installs the WCAT controller application on the computer that will act as the controller in the WCAT tests. The WCAT controller application enables the controller computer to interpret input files used in the WCAT tests; to formulate and send instructions to client computers; and to collect, analyze, and report data about the WCAT tests.

To install WCAT on the controller computer

1.From the controller computer, use Windows Explorer to connect to the shared directory on the server computer where WCAT is installed.

2.On the controller computer, click Start, select Programs, and click Command Prompt.

3.At the command prompt for drive C, type mkdir\webctrl to create a new directory called \Webctrl.

4.At the command prompt, type cd webctrl to go to the \Webctrl directory.

5.Type x:ctrler where x represents the network drive on the controller computer that is mapped to the server computer. This command extracts the controller files from Ctrler.exe on the server computer and copies them to controller drive x.

6.Type install.

This command creates the \Scripts directory on the controller computer and installs the WCAT test files in the \Scripts directory.

7.Type config webserver, where webserver is the name of the computer running the WCAT server.

For the WCAT server name, you can enter a network basic input/output system (NetBIOS) computer name, a host name, a fully qualified Domain Name System (DNS) host name, or an Internet Protocol (IP) address as shown in the following examples:

config server12 config www.server.com config 111.111.111.

The config command records the name and IP address of the WCAT server computer in a file named Srvname.cmd for later use. If the config command is successful, the following message appears at the command prompt

Setting server name to “webserver.”

where webserver is the computer name you specified with the config command.

To change the server used in a WCAT test, repeat step 6 in the preceding procedure before starting the test. To change the server at run time, you can use the -a option with the WCAT run command. For more information on using command line options, see “Using Command Line Options,” later in this guide.


Installing WCAT on the Client Computers

The following procedure installs the WCAT client application on the computers that will act as clients in the WCAT tests. You must install the WCAT client application on each computer that will run virtual clients during WCAT tests.

To install WCAT on the client computer

1.From the client computer, use Windows Explorer to connect to the shared directory on the server where WCAT is installed.

2.On the client computer, click Start, select Programs, and click Command Prompt.

3.At the command prompt for drive C, type mkdir\webclient to create a new directory called \Webclient.

4.At the command prompt, type cd webclient to go to the \Webclient directory.

5.At the command prompt, type x:client where x represents the drive on the client computer that is mapped to the server directory. This command extracts the WCAT client files and copies them to client drive x.

6.Type config ControllerName ControllerIP where ControllerName is the name of the computer to run the WCAT controller software and ControllerIP is the IP address of the computer to run the WCAT controller software.

For the WCAT controller name, you can enter a NetBIOS computer name, a fully qualified DNS host name, or an IP address as shown in the following example:

config server12 111.111.111.111

The config command records the name and IP address of the controller computer in a batch file (Stcrler.bat) for later reference. If the config command is successful, the following message appears at the command prompt

Setting controller name to “ControllerName” Setting controller IP address to “ControllerIP”

where ControllerName is the computer name and ControllerIP is the IP address you specified with the config command.


Verifying the WCAT Installation

Perform the following steps to verify the WCAT applications are installed correctly on the server, controller, and client computers:

· Verify the connections between the computers.

· Verify the controller computer can monitor the server computer remotely by using Performance Monitor.


Verifying Connections

Before beginning a WCAT test, you need to verify the WCAT server, controller, and client computers can communicate with each other. Also, you need to verify the computer names and IP addresses have been entered correctly.

To do so, perform the following two procedures:

· Verify the client computers can communicate with the server computer and the controller computer.

· Verify the controller computer can communicate with the server computer and the client computers.

Verifying Connections to the Client Computers

Use the TCP/IP ping utility included in Windows NT Workstation, Windows NT Server, and Windows 95 to test the connection between the client computers and the server and controller computers. For information on how to use ping, see “TCP/IP Procedures” in Control Panel Help.

To test the connection between the clients and the server

1.On a client computer, click Start, select Programs, and click Command Prompt.

2.At the command prompt, type ping server where server is the computer name or IP address of the server computer.

If the ping command successfully connects to the server, the client-server connection is working. If the ping command cannot successfully connect to the controller, an error message appears at the command prompt. Perform the preceding procedure for each client computer.

To test the connection between the clients and the controller

1.On a client computer, click Start, select Programs, and click Command Prompt.

2.At the command prompt, type ping controller where controller is the computer name or IP address of the controller computer.

If the ping command cannot successfully connect to the controller, an error message appears at the command prompt.

3.If ping cannot successfully connect to the controller, start Notepad and open the file Stctrler.cmd. Verify the computer name that appears in Stctrler.cmd after the line set WC_CTRLERNAME= is the same as the computer name of the controller.

If the computer name is not the same, repeat step 6 of the procedure “To install WCAT on the client computer,” earlier in this guide.

4.From the client computer, ping the controller computer using the controller’s IP address. Make a note of the correct IP address of the controller.

5.View Stctrler.cmd using Notepad, and verify the IP address that appears in Stctrler.cmd after set WC_CTRLER= is the same as the IP address of the controller computer.

If the computer IP address is not the same, repeat step 6 of the procedure “To install WCAT on the client computer,” earlier in this guide.

Perform the preceding procedure for each client computer.

Verifying Connections to the Controller Computer

You also use the ping utility to test the connection between the controller computer and the server and client computers.

To test the connection between the controller and the clients

· From the controller computer, ping each client computer using the computer name or IP address of the client computer.

To test the connection between the controller and the server

1.From the controller computer, ping the server computer using the computer name of the server computer. Make a note of the correct computer name of the server.

2.Start Notepad, and open the file Srvname.cmd. Verify the computer name that appears in Svrname.cmd after the line set webserver= is the same as the computer name of the server computer.

If the computer name is not the same, repeat step 6 of the procedure “To install WCAT on the controller computer,” earlier in this guide.

3.From the controller computer, ping the server computer using the IP address of the server computer. Make a note of the correct IP address of the server computer.


Verifying Remote Performance Monitoring

WCAT can collect data on server performance from the counters in Performance Monitor. Performance Monitor is an administrative tool designed to measure hardware and software performance on computers running Windows NT Workstation and Windows NT Server.

You can direct WCAT to collect data from Performance Monitor counters on the server computer during any WCAT test. For more information on using Performance Monitor counters during a WCAT test, see “Using Performance Monitor Counters in a WCAT Test,” later in this guide. To use Performance Monitor with WCAT, verify the controller can monitor the server remotely.

To test remote Performance Monitor monitoring

1.Log on to the controller computer, and start Performance Monitor. For more information on using Performance Monitor, see Microsoft Windows NT Workstation Resource Kit Version 4.0, Chapter 10, “About Performance Monitor” and Performance Monitor Help.

2.On the Edit menu, click Add to Chart.

3.In the Computer box, delete the name of the local computer, type the name of the server computer, and click OK.

4.Click the names of the counters you want to monitor during the WCAT test, click Add to add the counters to the chart, and then click Done.

If the WCAT test is successful, Performance Monitor displays a graph of the counters you selected. This graph indicates the controller’s Performance Monitor has received data collected by and about the server computer. It also confirms the counters you want to monitor during the WCAT test are available on the server computer.

If you cannot connect to the server computer with Performance Monitor or you do not have the required permissions, the test does not succeed. If the test does not succeed, verify that the server computer is started and that the computer name is correct. If you do not have permission to monitor the server computer remotely with Performance Monitor, you must receive the required permission. For details on granting permission for remote monitoring, see “Remote Performance Monitoring” in Supplement 1, Appendix A, “Major Revisions to Existing Resource Kit Books.”

If some of the counters you want to monitor do not appear in the Add to Chart dialog box in Performance Monitor, make sure the service associated with the counters is installed on the server computer. Counters that are not installed with Windows NT by default (such as the HTTP Service, FTP Server, Gopher Service, and Internet Information Services Global counters) do not appear in the Add to Chart dialog box unless the associated service is running on the remote computer. For more information, see “Troubleshooting the Internet Information Services Counters” in Supplement 1, Chapter 5, “Monitoring Virtual Memory.”


Running WCAT

Running a WCAT test consists of the following steps:

1.Preparing the controller input files

2.Starting the WCAT clients

3.Starting the WCAT controller

4.Starting the WCAT, IIS, or Web server

5.The warmup period

6.The experimental period

7.The cooldown period

8.The reporting period

9.Preparing the output files

You begin a WCAT test by starting WCAT on the client computers and then starting WCAT on the controller computer. When you start WCAT on the controller, you specify the test you want to run and any special options for that test. You do not have to start WCAT on the server.

Preparing the Controller Input Files

A WCAT test actually begins before the first WCAT computer is started. The test begins with the design of the input files. The input files direct the test and specify the activities of the clients during the test. The input files are stored on and interpreted by the controller computer.

For a description of the WCAT input files, see “Controller Input Files,” earlier in this guide. For a description of how to design WCAT input files to test the configuration possibilities you want tested, see “Changing Client Workloads,” later in this guide.

In addition to the standard controller input files, you can prepare an optional performance counter input file on the WCAT controller. For more information on doing so, see “Using Performance Monitor Counters in a WCAT Test,” later in this guide.

Starting the WCAT Clients

The first step in a WCAT test run is to start the WCAT client program, Wcclient.exe, on the client computers. The client computers then attempt to connect to the controller computer. If the controller responds, the test proceeds; otherwise, the clients wait for 10 seconds and then try again to connect to the controller. This process is repeated until the clients connect to the controller or you stop the Wcclient.exe program.

You can start WCAT on as many clients as you want and leave them running for as long as you want. However, the WCAT controller accepts connections from only the number of clients specified in the configuration input file.

During the WCAT test, the WCAT clients simulate Web browsers by sending requests to the server. The clients keep in memory a log of statistics on the timing and frequency of requests sent to and received from the WCAT server. At the conclusion of the test, the clients send these statistics to the controller. The controller processes these statistics and records the information in the WCAT log file.

To start a WCAT client

1.On the client computer, click Start, select Programs, and click Command Prompt.

2.At the command prompt, type cd directory where directory is the directory in which the WCAT client software is installed. Doing so switches to that directory. By default, the files are installed in \WebClient.

3.At the command prompt, type client to start the WCAT client program.

The client then tries to connect to the controller computer. Until the client has connected to the WCAT controller, it displays the following message on-screen:

Connecting Connect Failed. Error = 10061 Failed to connect to server 111.11.11.1 Controller is either not running a test or the name or ip address incorrect Sleeping 10 seconds before trying to connect again....

This message indicates normal behavior of a WCAT client. It is not an error message.

To stop a WCAT client

1.On the client computer, click Start, select Programs, and click Command Prompt.

2.At the command prompt, type ctrl+c

Starting the WCAT Controller

After the clients are running, you start the WCAT controller program, Wcctl.exe, on the controller computer. The WCAT controller begins by locating and interpreting the controller input files. The controller uses the input files to send instructions to the clients. These instructions tell the clients which prepared test to run.

Optionally, the controller can also monitor server performance during the test. This option requires the optional testname.pfc input file, where testname is the name of the test you are running. If you use this option, the controller starts Performance Monitor on the server computer and prepares to monitor the counters you identify in testname.pfc.

The WCAT controller starts and monitors the WCAT test. When you start WCAT on the controller, you tell it which WCAT test to run. The controller begins the test by telling the WCAT clients which files to request, in which pattern and frequency.

WCAT can run both the tests provided with WCAT and tests that you create. The tests provided with WCAT are described in “WCAT Tests,” later in this guide. For information on creating WCAT tests, see “Designing Custom Tests,” later in this guide.

To start a WCAT controller

1.On the controller computer, click Start, select Programs, and click Command Prompt.

2.At the command prompt, type cd directory where directory is the directory in which the WCAT controller files are installed. Doing so switches to that directory. By default, the files are installed in \WebCtrl.

3.At the command prompt, type run testname [options] where testname is the name of the prepared WCAT test you are running and options is options for that test. The test name does not include the test’s filename extension. If you do not supply a test name, WCAT runs the 1ktest01 test. The possible test options you can use are described in “Using Command Line Options,” later in this guide.

Note

WCAT uses the name of a particular test to name that test’s output log file and optional performance results file. If you run a test more than once, WCAT overwrites any existing output files with the same test name. To preserve output files from a test before running the test again, use the -e option with the run command.

When the controller’s preparatory work is complete, it begins responding to client requests for connections to the controller. The controller allows the clients to connect to the controller one at a time, until the number of clients specified in the configuration input file for the test is reached. The status message “All clients started” appears in the controller’s command prompt window when the required number of clients have successfully connected to the controller.

If more than the required number of clients attempt to connect, the controller ignores the extra clients. If fewer than the required number of clients connect, the controller waits indefinitely for the others. You should start troubleshooting client status and connection to the network if the “All clients started” message does not display by the end of the warmup period.

When the required number of clients have connected, the controller sends test instructions to the clients. The client computers display on-screen messages reflecting the receipt of these instructions. By default, the controller monitors the test on TCP/IP port 7232.

Starting the WCAT, IIS, or Web Server

Next, start the Internet Information Server and HTTP Service on the WCAT server.

The Warmup Period

The warmup period begins after the clients have received their instructions from the controller. During the warmup period, the clients start sending requests for Web pages to the server. However, the data collected by the clients and controller during the warmup period is not included in the output files, because work done during this period does not properly represent the full workload imposed on the server.

Typically, servers respond more slowly during the warmup period than subsequently. This slow response comes from the fact the servers have not yet loaded frequently used pages into the file system cache, frequently used objects into the IIS Object Cache, or frequently used instructions into the processor cache.

The Experimental Period

The experimental period is the body of the test. The length of the experimental period is referred to as the duration of the test, in other words the total test time minus the warmup and cooldown periods. During the experimental period, the clients request Web pages from the server based upon the controller’s instructions. As the clients work, they gather statistics on their own behavior and on the response of the server.

The controller is also active during the experimental period. The controller keeps track of the elapsed time of the test. It also monitors the Performance Monitor counters on the server computer, if that option is selected.

During the experimental period, you might see one or more status messages displayed in the clients’ command prompt windows. These status messages provide information about the progress of the test.

The Cooldown Period

When the experimental period stops, the cooldown period begins.

During the cooldown period, the controller directs the clients to stop sending requests to the server. The clients complete requests in progress and continue to gather performance data. However, the data collected during the cooldown period is not included in the output files, because work done during this period does not properly represent the full workload imposed on the server.

The Reporting Period

The reporting period occurs after the test. During the reporting period, the clients send the controller the data they collected during the test. After the controller has received all data, the controller closes all client connections. The clients then return to their pretest state. They resume periodic attempts to reconnect to the controller until you stop WCAT.

At the end of the test, the results are computed and written to Scripts\testname.log, where testname is the name of the test run. A single line of information from the log file appears on each client’s screen. This single line contains the total number of pages read, the average number of pages read per second, and the actual number of pages read by each client.

Preparing the Output Files

During a WCAT test, the controller monitors the operation of the server and collects data on the response of the server to the test. The controller also collects data from the clients during the cooldown period.

When the controller has gathered data from the clients, it calculates information from and summarizes that data. The controller then displays a brief summary of the data in its command prompt window and writes all data to the output log file.

If the optional performance counter option is used with the run command, the controller adds a Performance Counters section to the log file and creates a performance results file from the data it has collected. For more information about the output files, see “Analyzing the WCAT Log” and “Interpreting a Performance Results File,” later in this guide.

After the controller writes the output files, the controller program stops and closes connections to the client computers. Then the specified test is complete. If you are running multiple tests by using a batch file, the next test is automatically started.

When the controller closes the client connections, each client attempts to reconnect to the controller until the client program (wcclient.exe) is stopped explicitly on each computer running that program.


Analyzing the WCAT Log

WCAT records and collects statistical data from the WCAT clients and server during a WCAT test. At the conclusion of the test, WCAT summarizes the data and writes it to an output log file. Data collected during the warmup and cooldown periods of the test are excluded from the log.

WCAT uses the name of the test as the name of the log file in the format testname.log. For example, the log of the Cgi25 test is named Cgi25.log.

The WCAT log is composed of five sections:

· File header

· Results

· Performance counters

· Files

· Class statistics

The performance counters section appears only if the WCAT test was run with the -p option. For more information running WCAT with the -p option, see “Using Performance Monitor Counters in a WCAT Test.”

Tip

Look at the sample WCAT log file included with WCAT for reference while you read the following sections. The sample log file, 1ktest01.log, appears on the Supplement 1 CD-ROM. You can use any text editor or word processor to view the 1ktest01.log file.


File Header

A WCAT log file begins with a file header that identifies the attributes of the test run, including the test date and time and the input and output files used. The following example shows the file header of the sample log file, 1ktest01.log:

WCAT Version | = 3.1
ConfigFile | = scripts\1ktest01.cfg
ScriptFile | = scripts\1ktest01.scr
DistribFile | = scripts\1ktest01.dst
PerfCounterFile | = scripts\server.pfc
LogFile | = scripts\1ktest01.log
Author | =
Creation Date | =
Test Run Date | = Mon Dec 02 14:11:00 1996
Comment | = Configuration For File Size Mix
Server [IpAddr:Port] | = webserver [webserver:80]
Clients | = 1
Threads | = 5
Buffer Size | = 131072 bytes
Duration | = 300 seconds (Warmup 30 seconds, Cooldown 30 seconds)

The following table lists and describes the fields in the log file header.

Table 3 Log File Header Fields

Field | Description
WCAT Version | The version number of the WCAT application used in the test.
ConfigFile | The path and filename of the configuration input file used in the test.
ScriptFile | The path and filename of the script input file used in the test.
DistribFile | The path and filename of the distribution input file used in the test.
PerfCounterFile | The path and filename of the performance counters input file used in the test, if any. If the -p option was not used in the test, no filename appears.
LogFile | The path and filename of this log file.
Author | The author of the test. This field is optional.
Creation Date | The creation date of the test. This field is optional.
Test Run Date | The date and time the test began. The test reads the date and time from the controller computer.
Comment | The text entered in the Comment field in the configuration file for the test.
Server [IpAddr:Port] Server is the name of the server computer used in the test.

IpAddr is the computer name or IP address of the server used in the test. The value of this field reflects the value used with the config command on the controller when WCAT was installed.

Port is the TCP port on the server computer that is used by Internet Information Server for the HTTP (WWW) Service. The default TCP port is 80. To view or change the TCP port, edit the TcpPort value entry in the Registry. For more information about TcpPort, see Regentry.hlp, a Help file about the Registry on the Supplement 1 CD-ROM.
Clients | The number of client computers used in the test. The Clients value reflects the entry in the NumClientMachines field of the configuration file, unless the value was overridden by using the -m option with the run command.
Threads | The number of virtual clients run on each client in the test. Each thread in the WCAT process represents one virtual client. The Threads value reflects the entry in the NumClientThreads field of the configuration input file, unless the value was overridden by using the -t option with the run command.

Table 3 Log File Header Fields (Continued)

Field | Description
Buffer Size | The size of the receive buffer of the memory cache used in the test, in bytes. You can enter a suggested maximum size for the receive buffer in the MaxRecvBuffer field of the configuration input file.
Duration | The total elapsed time of the test, in seconds, including the length of the warmup and cooldown periods of the test. The Duration value reflects the entries in the Duration, WarmupTime, and CooldownTime fields of the configuration input file. You can override the value of Duration by using the -u option with the run command.


Results Section

The results section of the log reports data collected by the WCAT clients during the test. The section consists of a table summarizing the data collected. Each row in this table represents a different measure of client activity or server response. The number of columns in the table varies with the number of clients used in the test. The following is an example of a results table:

Results: Data, Summary, Rate, 157.55.94.121, 157.55.94.121, Client Id, 0, 0.00, 1, 2, Duration, 180, 1.00, 180, 180, Pages Requested, 11602, 64.46, 5718, 5884, Pages Read, 11602, 64.46, 5718, 5884, Total Responses, 11602, 64.46, 5718, 5884, Avg Response Time, 155, 0.86, 157, 152, Min Response Time, 10, 0.06, 10, 10, Max Response Time, 1883, 10.46, 1883, 1873, StdDev Response Time, 194, 1.08, 200, 186, Total Connects, 11602, 64.46, 5718, 5884, Avg Connect Time, 40, 0.22, 40, 39, Min Connect Time, 0, 0.00, 0, 0, Max Connect Time, 390, 2.17, 390, 290, StdDev Connect Time, 20, 0.11, 22, 19, Connect Errors, 0, 0.00, 0, 0, Read Errors, 0, 0.00, 0, 0, Data Read, 186970624, 1038725.69, 94656000, 92314624, Header Bytes, 2344747, 13026.37, 1155657, 1189090, Total Bytes, 189315371, 1051752.06, 95811657, 93503714, Avg Header per Page, 202, 1.12, 202, 202, Avg Bytes per Page, 16317, 90.65, 16756, 15891,

The following table lists and defines the columns of the results table.

Table 4 Results Table Columns

Column | Description
Data | The test criterion for which the data in the row was collected.
Summary | The sum of the value for that test criteria for all client computers in the test. What the Summary column signifies for a row depends on the row. If the test criteria is a total, the Summary value is the sum of the values for all client computers. If the test criteria is an average, the Summary value is an average of the values for all client computers.
Rate | The average value for that test criterion per second of the test. The value of the rate is calculated by dividing the Summary value by the total elapsed duration of the test, in seconds. For the purposes of the Rate column, the duration includes the warmup and cooldown periods of the test.
ClientIP | This column is named using the IP address identifying a particular client computer. If you are using multiple clients, the results table has multiple ClientIP columns.

There are multiple ClientIP columns; each represents one client. The ClientIP columns list the client computers in the order they connected to the controller. The values in each client column reflect values for all virtual clients running on that client process.

Note

If the test included a large number of clients, each row contains multiple client columns of comma-separated values. If this is the case, use a spreadsheet or data processing program to organize the rows and columns into a table.

The rows of the results table represent values for different test criteria recorded by the WCAT clients during the test. The following table lists and describes each test criterion by row.

Table 5 Results Table Rows

Test criterion (row) | Description
Client ID | WCAT identification numbers for the client computers. The Summary and Rate column values for the Client ID row are always zero.
Duration | The total elapsed time of the test, in seconds. The duration includes the warmup and cooldown periods.
Pages Requested | The total number of pages requested from the server by clients during the test. Each page can consist of one or more files.
Pages Read | The total number of pages received from the server by clients during the test. Each page can consist of one or more files.

Table 5 Results Table Rows (Continued)

Test criterion (row) | Description
Total Responses | The total number of instances in which the server responded to requests from clients. This value includes responses to requests for connections, as well as requests for pages.
Avg Response Time | The average response time recorded by clients. The response time is the elapsed time between the time a request was sent and the time the response was received, in seconds. In the ClientIP column, the average response time is calculated by summing the average response times recorded by each virtual client.
Min Response Time | The shortest response time recorded by a client computer during the test. In the ClientIP column, this value is the shortest response time recorded by any virtual client on the client computers.
Max Response Time | The longest response time recorded by a client computer during the test. In the ClientIP column, this value is the longest response time recorded by any virtual client on the clients.
StdDev Response Time | The standard deviation of the response times recorded by the clients. The standard deviation is a statistical measure of how much values vary from the average value.
Total Connects | The number of successful connections established between the virtual clients and the server during the test.
Avg Connect Time | The average length of time for a connection between a virtual client and the server during the test. The connect time is the time elapsed between the time the connection was established and the time it was closed, in seconds, as observed by the client.
Min Connect Time | The shortest connect time recorded by a client computer during the test. In the ClientIP column, this value is the shortest connect time recorded by any virtual client on the client computers.
Max Connect Time | The longest connect time recorded by a client computer during the test. In the ClientIP column, this value is the longest connect time recorded by any virtual client on the client computers.
StdDev Connect Time | The standard deviation of a connect time recorded by the client. The standard deviation is a statistical measure of how much values vary from the average value.

Table 5 Results Table Rows (Continued)

Test criterion (row) | Description
Connect Errors | The number of connection error messages the clients received during the test. The server closes a connection and sends a connection error message to the client if the connection request has formatting or protocol errors, if the server did not have the resources to support the connection, or if the maximum number of connection permitted for the HTTP (WWW) Service is exceeded. If you have more than 10 connection errors in a test, rerun the test using the Performance Monitor counters option to investigate processor and memory use on your server. Or reduce the number of virtual clients in the test. You can also use Internet Service Manager to increase the maximum number of possible connections to the HTTP service.
Read Errors | The number of read error messages the clients received during the test. The server closes a connection and sends a read error message to the client if the page the client requested was not found on the server. You should not have any read errors in a WCAT test if you have correctly followed the installation procedures and are using the prepared tests. To eliminate read errors, make sure the entries in the Uniform Resource Locator (URL) fields of the script input file correspond to files on the WCAT server’s Home directory.
Data Read | The amount of Web page content the virtual clients received from the server, in bytes. The Data Read column does not include the bytes associated with protocol headers. To determine the total number of bytes the clients received from the server, add the values of the Data Read and Header Bytes columns.
Header Bytes | The number of bytes the virtual clients received from the server that constitute protocol headers for data.
Avg Header per Page | The average size of the protocol header for each page, in bytes. The Avg Header per Page column is calculated by dividing header bytes by pages read.
Avg Bytes per Page | The average size of a test Web page, in bytes, excluding bytes that constitute protocol headers. The Avg Bytes per Page column is calculated by dividing data read by pages read.


Performance Counters Section

The performance counters section appears in a WCAT log when you run WCAT with the -p option. This log section displays data collected from the Performance Monitor counters on the server computer during the WCAT test. For more information on including performance counters in a WCAT test, see “Using Performance Monitor Counters in a WCAT Test,” later in this guide.

The performance counters section of the WCAT log consists of a table showing the average value of each counter collected during the test and the average value for that counter per page. WCAT calculates the values in the Avg per Page column by dividing the average value of a counter by the rate at which clients read pages. You can find this rate in the results section of the log file, in the Rate column of the Pages Read row.

The following example shows the first few rows of the performance counters section of a log file; in the example, the total processor utilization is 33 percent and the processor utilization per delivered page is 0.57 percent.

Counter name | Average | Avg per Page
System\% Total Processor Time | 33 | 0.57
Process(inetinfo)\% Processor Time | 14 | 0.24
Process(inetinfo)\% Privileged Time | 7 | 0.12


Files Section

The files section of the WCAT log is a two-row table that displays the number of files requested and received by clients during the WCAT test. The file table does not have its own column headings. Instead, it uses the same column headings as in the results table, described earlier in “Results Section.” The file table can be thought of as a continuation of the results table. The following table lists and describes the file table rows.

Table 6 File Requests and Reads

Test criterion (row) | Description
Files Requested | The number of files requested by the virtual clients during the test. You can compare the number of files requested to the number of files read to determine how many of the files requested were not received. You can also divide files requested by pages requested (found in the results section) to find the average number of files requested per page.
Files Read | The number of files received by the virtual clients in the test. You can compare files read to pages read (found in the results section) to find the average number of files read per page.

The following example shows a file table from a 1ktest01.log file. Column headings are added to the example for reference.

Test Criteria | Summary | Rate | Client 1
Files Requested | 17283 | 57.61 | 1567
Files Read | 17283 | 57.61 | 1567


Class Statistics Section

The class statistics section of the WCAT log displays retrieval rate data for pages retrieved by the clients. Data is separated into different tables by page class. You can use the data to compare the performance of the server for different classes of Web pages.

Class is the category WCAT uses to group together similar Web pages, such as static pages or CGI requests. The WCAT controller directs clients to request pages of a given class at a given relative frequency, but it lets the clients select which pages in a class to request. The script file for a WCAT test specifies the pages assigned to each class and gives the class an identifier number. It is useful to consult a test’s script file when interpreting the class statistics section of that test’s log.

The class statistics consist of a series of three-row tables. Each set of three rows constitutes the data for one class. The following table lists and describes the test criteria in the class table.

Table 7 Class Table Test Criteria

Test criterion (row) | Description
Fetched | The number of pages the clients received from the server. The Fetched row is the same as the Pages Read row in the results table.
Errored | The number of requests for pages that could not be satisfied because the server could not find the requested page. The Errored row is the same as the Read Errors row in the results table.
Distrib | The distribution percentage for the class. The number is expressed as 100 times the percentage. For example, 906 indicates that this class was requested 9.06 percent of the time.

There are no column headings in the class statistics table. The first column of the table displays the class identifier of the class measured; the remaining columns are identical to those for the results table.

The following example shows the first two tables in the class statistics section of 1ktest01.log. The tables shown are for classes 1 and 2. The column headings in the following example were added for reference.

Per Class Statistics:
Class ID | Test Criteria | Summary | Rate | Client 1
1 | Fetched | 1567 | 5.22 | 1567
1 | Errored | 0 | 0.00 | 0
1 | distrib | 906 | 3.02 | 906
2 | Fetched | 1408 | 4.69 | 1408
2 | Errored | 0 | 0.00 | 0
2 | distrib | 814 | 2.71 | 814


Using Performance Monitor Counters in a WCAT Test

You can use Performance Monitor counters to gather additional details about the response of your server to WCAT tests, including information about the processors, physical memory, disk subsystem, memory cache, and about the behavior of services such as Internet Information Server.

To collect data for Performance Monitor input, you start a Performance Monitor log on the controller computer and direct that log to gather data from the server computer. When the WCAT test is complete, you can use Performance Monitor to read the Performance Monitor log.

Performance Monitor collects and displays data from internal hardware counters and from counters implemented in drivers, services, and applications. The material in this section is designed for readers who are familiar with Performance Monitor, including such concepts as performance objects, performance counters, and instances. For more information about Performance Monitor, see Windows NT Workstation Resource Kit, Chapter 10, “About Performance Monitor” and Performance Monitor Help.

To use Performance Monitor counters in a WCAT test, you:

· Create a formatted input file listing the Performance Monitor counters you want WCAT to monitor. WCAT performance counter input files are identified by the name testname.pfc, where testname is the name of the test during which performance is monitored.

· Include the -p option and the name of the performance counter input file (including its .pfc extension) after the run command starting the WCAT controller.

If the -p option is specified, the WCAT controller remotely activates Performance Monitor on the server when the WCAT test begins. The controller then monitors the performance counters listed in the performance counter input file; the controller collects data from the counters every 10 seconds. As discussed earlier in “The Warmup Period” and “The Cooldown Period,” WCAT does not include data collected during the warmup and cooldown periods of the test in its summary calculations.

At the conclusion of the test, the controller summarizes the data it has collected from the performance counters and writes the results to an output file. The performance results output file is named in the format testname.prf. In addition, WCAT adds a short summary of the performance counter values to the test log file.

The following sections explain how to create a WCAT performance counter input file, how to submit the file to WCAT, and how to interpret a WCAT performance results file.


Creating a Performance Counter Input File

The performance counter input file is a formatted file that lists the Performance Monitor counters you want to monitor during a WCAT test. You can use a performance counter input file in any WCAT test, and you can use the same performance counter input file for many different WCAT tests.

The performance counter input file can have any name, but the name must be in the format testname.pfc. By installation default, the file is located in the \Scripts directory on the WCAT controller, along with the configuration file, script file, and distribution file.


Selecting Counters

The first step in creating a performance counter input file is to decide which counters you want to monitor during the WCAT test. Which counters you choose depend on your particular interests or concerns about server performance.

There are several resources available to help you select counters:

· Supplement 1, Part II, “Optimizing IIS Server Performance,” suggests counters for monitoring different performance aspects of a server running Internet Information Server.

· Windows NT Workstation Resource Kit, Part 3, “Optimizing Windows NT Workstation,” suggests counters for monitoring processors, memory, disks, and the file system cache on any computer. This Windows NT Workstation Resource Kit part also suggests counters for monitoring multiprocessor computers.

· Counters.hlp is a Help file that lists and describes the Performance Monitor counters that come with Windows NT Server and Windows NT Workstation. Counters.hlp has been updated to include the counters for Internet Information Server. The newest version of Counters.hlp appears on the Supplement 1 CD-ROM.

· Server.pfc is a sample performance counter input file included with WCAT. Server.pfc is installed in the \Scripts directory on the WCAT controller when you install WCAT. You can use Server.pfc in any WCAT test or as a model to create your own performance counter input files.

The counters you list in the performance counter input file must be configured on the server computer. Note that some Performance Monitor counters are always available; others are available only when the application or service they monitor is running on the server computer. To check which counters are available, use the procedure “To test remote Performance Monitor monitoring,” earlier in this guide.


Writing a Performance Counter Input File

You can use any word processor or text editor, such as Microsoft Word, Notepad, or Wordpad, to create or read a performance counter input file.

Tip

Look at the sample performance counter input file included with WCAT for reference while you are reading this section. The sample file, Server.pfc, appears on the Supplement 1 CD-ROM.

To monitor a particular counter, list it on a separate line in the input file. If you are monitoring more than one instance of a component, such as more than one process, processor, disk, or network adapter, list each instance on a separate line. You can list up to 50 performance counters in a file; the counters can be listed in any order.

The lines listing the performance counters should be left-aligned with no tabs or indentations. You can include comments in a performance counter input file; to indicate a comment, place a pound sign (#) at the beginning of the comment line.

Listing a Counter

The entry for each counter should include the name of the performance object you want to monitor, the name or number of the object instance to monitor, and the name of the counter. To find the object name, counter name, and instance name or number, check the Add to Chart dialog box in Performance Monitor. The figure following shows the counters for and instances of the Process object in the Add to Chart dialog box.

Figure 3 Counters for and instances of the Process object in the
Add to Chart dialog box

The format for a performance counter entry is as follows:

object(instance)\counter

where object represents the name of the performance object that includes the counter, instance represents the name or number of the object instance as it appears in Performance Monitor, and counter represents the name of the performance counter.

Object

In the object section of the entry, type the name of the performance object as it appears in the Add to Chart dialog box, including any spaces.

Instance

In the instance section of the entry, type the name or number of the instance. Some performance objects, such as System, do not have instances. But if an instance name or number appears in the Instance box in the Add to Chart dialog box, you must include that name or number in the performance counter entry.

Include the instance name or number even if there is only one instance of the performance object on the server. If the processor has one server, one instance of the Processor object, number 0, appears in the Instance box. If you are listing a counter for the Processor object, you must include this number 0 in the line.

If you want to monitor more than one instance of an object, list each instance on a separate line in the file. For example, to monitor PhysicalDisk: % Disk Time for two physical disks, 0 and 1, and for the _Total instance that represents both disks, include the following lines in the performance counter input file:

PhysicalDisk(0)\% Disk Time PhysicalDisk(1)\% Disk Time PhysicalDisk(_Total)\% Disk Time

Counter

In the counter section of the entry, type the name of the performance counter as it appears in the Add to Chart dialog box, including any spaces in the name.

Example

For example, to monitor the processor time used by the Internet Information Server process, Inetinfo, you monitor the Process: % Processor Time counter for Inetinfo. An entry for the Process: % Processor Time counter for the Inetinfo process reads as so:

Process(inetinfo)\% Processor Time

In this example, Process is the object, inetinfo is the instance and % Processor Time is the counter.

When you have listed all the counters you want to monitor, save the performance counter input file. You can use any name, but be sure to use the format testname.pfc. Place the file in the WebCtrlr\Scripts directory on the controller.


Running WCAT with Performance Monitor Counters

To monitor Performance Monitor counters on the server, include the -p option and the name of the performance counter input file with the run command on the controller command line.

To start WCAT with Performance Monitor counters

1.At the command prompt on each client computer, type client

2.At the command prompt on the controller, type

run testname [other options] -p filename.pfc

where testname is the name of the WCAT test, other options represents other valid WCAT test options, and filename represents the path and filename of the performance counter input file. The other options for WCAT are described in “Using Command Line Options,” later in this guide.

For example, to run the Clntload test with the counters listed in the Server.pfc file in the \Scripts directory, type:

run clntload -p scripts\server.pfc

During the WCAT test, the controller monitors the performance counters every 10 seconds. At the conclusion of the test, WCAT summarizes the results and records them in a performance results file. This results file has the same filename prefix as the performance counter input file but with the filename extension .prf. The next section explains how to interpret the performance results file.

WCAT also provides a performance counter section in the WCAT log file. This performance counter section displays the average values of the counters during the test. For information about the performance counter section of the WCAT log file, see “Analyzing the WCAT Log,” earlier in this guide.


Interpreting a Performance Results File

The WCAT performance results file displays the data collected from the performance counters on the server. The data is displayed in a comma-separated, variable-length format, so the file can be used as input for a data processing or spreadsheet application. The file cannot be used as input for Performance Monitor, however; Performance Monitor cannot display charts or reports from WCAT output files.

Tip

Look at the sample performance results file included with WCAT for reference while you are reading this section. The sample file, 1ktest01.prf, appears on the Supplement 1 CD-ROM. You can use any text editor or word processor to view the 1ktest01.prf file. You can also load the file into any data processing program or spreadsheet for viewing or analysis.

The performance results file is made up of three sections:

· A file header

· Column headings

· A table of performance data

File Header

The performance results file begins with a header identifying which test run the given output relates to and what information is included.

For example:

File = scripts\1ktest01.prf NumCounters = 10 MachineName = webserver Start Time = Mon Dec 02 14:10:53 1996

The fields in the header are as follows:

· File lists the path and filename of the performance counter input file.

· NumCounters displays the number of counters requested in the performance counter input file.

· MachineName displays the name of the server computer whose performance counters were monitored.

· Start Time displays the time WCAT started on the controller.

WCAT begins monitoring performance counters when the warmup period ends. The Start Time field does not display the time monitoring began, but you can determine the beginning of monitoring. At the conclusion of the warmup period WCAT displays the following message at the command prompt:

Starting to average the performance counters

This message signals the beginning of monitoring.

Column Headings

After the header, the next section of the file is a comma-separated stream of column headings for the table that follows. The column headings appear in the same order as the columns appear in the table. Use your spreadsheet program to associate each column heading with the column it names.

The following is an example of column headings:

TimeSlice, System\% Total Processor Time, Process(inetinfo)\% Processor Time, Process(inetinfo)\% Privileged Time, Process(inetinfo)\% User Time, Memory\Page Faults/sec, System\Context Switches/sec, System\System Calls/sec, Process(inetinfo)\Thread Count, Process(inetinfo)\Private Bytes, HTTP Service\Connection Attempts/sec, HTTP Service\Connection Attempts,

Performance Counter Table

The last section of the performance results file is a table displaying the data collected from the server performance counters. Each column of the table represents a performance counter, except for the first column, TimeSlice. The TimeSlice column indicates how often the Performance Monitor counters were monitored during the test, in seconds. WCAT tries to monitor the counters every 10 seconds, but attempts might be delayed if the processor is busy. Each row of the table represents one observation.

Each entry in the table represents the value of one counter when it was observed. The values are displayed in the units native to the counter. For example, in the table following the 9 in the first row of the second column represents 9 percent processor use, while the 9 in the second row of the sixth column represents nine page faults per second.

To interpret the table, associate each column with its column heading. The columns appear in the same order as the column headings.

10 | 9 | 0 | 0 | 0 | 42 | 67 | 260 | 25 | 1544192 | 0 | 433
10 | 36 | 16 | 9 | 6 | 9 | 418 | 466 | 25 | 1544192 | 61 | 1065
10 | 33 | 15 | 7 | 7 | 3 | 385 | 419 | 25 | 1544192 | 54 | 1635

For more information on interpreting the values of Performance Monitor counters, see the Help file Counters.hlp; Windows NT Workstation Resource Kit, Part 3, “Optimizing Windows NT Workstation”; and Supplement 1, Part II, “Optimizing IIS Server Performance.”


Designing Custom Tests

You can use WCAT to create and run tests that evaluate your unique Internet Information Server configuration and Web applications. In your custom tests, you can customize client workload, server content and programs, and network configurations. For example, you can use WCAT to evaluate a new Web application during development to understand how the server responds when running the application. You can also evaluate how your Internet Information Server responds to different production environments by varying client workloads and network bandwidth.

You can create and run custom WCAT tests to evaluate the following:

· How different programs and functions affect a server configured with Windows NT Server and Internet Information Server

· How the server responds to various client workload simulations

· How the server responds when supporting client access from multiple networks

The remaining sections in this guide describe how you can create custom tests by doing any of the following:

· Using command line options with the run command

· Changing the values of variables in the configuration, script, and distribution input files

· Substituting your own HTML, ISAPI, or CGI programs and content for the prepared tests provided with WCAT

· Changing the test environment from a dedicated single network to multiple networks

· Using multiple Internet Information Servers


Using Command Line Options

Using the WCAT command line options, you can make quick, temporary changes at run time without editing input files. The options apply only to the test being run.

To use these options, include them when entering the run command on the controller computer. You can include more than one option, and you can list options in any order. Unless specified otherwise in the following table, use a space to separate one test option from another on the command line. The following table lists and describes the WCAT command line options.

Table 8 Options for WCAT Tests

Option | Description
-a ServerIP | Specifies the IP address or addresses of the server or servers to test, where ServerIP is that address or addresses. The -a option overrides the data entered in the config command on the controller computer. Use commas to separate multiple IP addresses. See also -n, following.
-c ConfigFile | Specifies the configuration input file for this test. If the -c option is not entered, WCAT looks for a configuration input file with the same name as the test. ConfigFile represents the path and filename of the configuration input file for the test. Configuration input files can have any name, in the form testname.cfg.
-d DistribFile | Specifies the distribution file for this test. If the -d option is not entered, WCAT looks for a distribution input file with the same name as the test. DistribFile represents the path and filename of the distribution input file for the test. Distribution input files can have any name, in the form testname.dst.
-e PrefixName | Specifies the filename prefix for the configuration, script, and distribution input files and the performance results and log output files, where PrefixName is that prefix. If the -e option is not entered, WCAT uses the name of the test as the filename prefix. You can use the -e option to prevent WCAT from overwriting the files of a previous run of the test.
-l LogFile | Specifies the file to which WCAT writes the log. If the -l option is not entered, WCAT writes the log file to the directory from which WCAT was run. LogFile represents the full path to the alternate location.
-m ClientComputers | Specifies the number of client computers to be used in the WCAT test, where ClientComputers is that number. The value of the -m option overrides the value specified in the NumClientMachines entry in the configuration file for the test.


Modifying the Controller Input Files

The controller input files include the configuration, script, and distribution files and the optional performance counters file. (For information about creating and using the optional performance counters file, see “Writing a WCAT Performance Counter Input File,” earlier in this guide.)

To create a custom test, you can either edit one of the prepared tests or create new controller input files. The changes you make to the input files can change test conditions, the content pages that clients request, and the frequency at which pages are requested. The general procedure is as follows:

1.Edit a sample configuration file, or write a new configuration file, to change the variables that define the number of client computers, the number of threads per client, the duration of the test, or any combination of these conditions. (Keep in mind you can override any of these variables at test time by using run command-line options.)

2.Edit a prepared test script file, or write a new script file, to identify a new set of content pages for virtual clients to request from the server.

3.Edit a prepared test distribution file, or write a new file, to specify the frequency at which clients request the pages identified in the script file.

You can use any word processor or text editor to edit the controller input files.

Modifying the Configuration File

The configuration file is located on the controller. After the Wcctl.exe program is started, it reads the configuration file to determine how many clients are included in the test and what test instructions to send to the clients. The client instructions that you can change in the configuration file are described in the following table.

Table 9 Test Parameters in the Configuration File

Parameter name | Description | Action you can perform
Thinktime | Value that determines the time interval between client requests sent to the server. | Increase or decrease this value to change this time interval.
MaxRevBuffer | Size of the client buffer. The default value is 64K. The controller sends this information to the client computers. | Increase this value to increase the size of the client buffer. This value can be increased to a maximum number of 128K. (WCAT sets no limit. However, a large MaxRevBuffer value means more memory is consumed on the client; a small value means that the client might be slow.) Increasing the client buffer size is recommended when testing a server program that contains large amounts of data.
CooldownTime | End of test time interval, which is excluded from test results to eliminate the effects of processing completion from the test results. The controller sends this information to the client computers. | Increase or decrease this value to change the amount of time the client can use to complete all processing and data collection. Changing this variable increases or decreases the total test time.
WarmupTime | Start of test time interval, which is excluded from test results to minimize the effect of time spent starting the clients and server on test results. The controller sends this information to the client computers. | Increase or decrease this value to change the amount of time allowed for client and server startup. Changing this variable increases or decreases the total test time.

Table 9 Test Parameters in the Configuration File (Continued)

Parameter name | Description | Action you can perform
NumClientMachines | Number of client computers used in the test. The default value is 1. | Increase or decrease this number to change the number of clients the controller accepts as participants in the test.
NumClientThreads | Number of virtual client sessions run on a single client computer. The default value is 1. The controller sends this information to the client computers. | Increase or decrease this value to include multiple virtual clients. The maximum value is 100. The recommended value is as many clients as you can run on the client computer before it becomes CPU saturated; experiment and find the optimal value for your system.
Duration | Time value that describes how long the test should run, in seconds. The controller sends this information to the client computers. | Increase or decrease this value to change the test time period. Note that the cooldown time and warmup time are not included in this value. Thus, total test time equals the column values CooldownTime + Duration + WarmupTime.

Modifying the Script File

Each prepared test uses a script file that defines the client and server transactions performed during the experimental period. After the controller is started and connected to the test clients, the controller program reads the script file and sends instructions to each client. These instructions describe the content requests the clients are to send to the server during the experimental period.

Following is a sample script file.

# ###################################################################### # # Test script file for WCAT # # ###################################################################### # Format of Script Specification: # # ClassId Operation Files # Note: Operation Strings are case insensitive # # Reserved Ids # Class Ids 1-10 are reserved for fixed file size classes # Class Ids 101-110 are reserved for CGI scripts # Class Ids 201-210 are reserved for ISAPI scripts # Class Ids 301-310 are reserved for Post Operation # Class Id 0 is reserved for special purposes # # Class Id Range Recommended Usage # 1-100 File transfers # 101-200 CGI Requests # 201-300 ISAPI Requests # 301-400 Post Requests # # Plaza Welcome page => NEW TRANSACTION classId = 1 NEW REQUEST HTTP Verb = “GET” URL = “/scripts/welcome.py” # Click Repeat Shopper => Plaza Lobby NEW TRANSACTION classId = 2 NEW REQUEST HTTP Verb = “GET” URL = “/prd.i/pgen/plaza/JQ04Q9JF66SH2JS700Q79TREBNBGAU1M/plaza1.html” # Click AG => AG Lobby NEW TRANSACTION classId = 3 NEW REQUEST HTTP Verb = “GET” URL = “/prd.i/pgen/ag/JQ04Q9JF66SH2JS700Q79TREBNBGAU1M/lobby.html” # Click Big Picture NEW TRANSACTION classId = 4 NEW REQUEST HTTP Verb = “GET” URL = “/prd.i/pgen/ag/JQ04Q9JF66SH2JS700Q79TREBNBGAU1M/ag_bigpicture.html”

Note that the script file begins with comments that recommend a class numbering system for different types of client-server transactions. Following the comment lines are sample transactions. When you create your own script file, use the recommended class identification numbering to identify your transactions. The class identifiers are used to group together similar transactions in the class statistics section of the controller log file. For more information on this log file section, see “Class Statistics Section,” earlier in this guide.

There are four types of program statements you can use in a script file to define new transactions. These are:

· Global commands

· Transaction commands

· HTTP request commands

· ClearCookie request commands

These commands are described in the following sections.

Global Commands

The following global commands can be used anywhere in the script file.

set <default_variable> = <value> <default_variable> := ClassId | Server | Verb | URL | Cookie | Port | ResponseStatusCode |KeepAlive | Authentication <value> = <BOOLValue> | <DWORDValue> | <StringValue> | <WORDValue> <BOOLValue> = TRUE | FALSE <DWORDValue> = decimal number < 4,294,967,296 <FileOrStringValue> = <FileValue> | <StringValue> <FileValue> = FILE <StringValue> <StringValue> = quoted string. \r, \n, \t, and \\ are special escape sequences for carriage return, line feed, tab, and '\'. <WORDValue> = decimal number < 65,536 ClassId, ResponseStatusCode, and Authentication are DWORDValues. Server, Verb, URL, and Cookie are StringValues. Port is a WORDValue. KeepAlive is a BOOLValue. NEW TRANSACTION

Transaction Commands

These following commands are used to define a client-server transaction. The commands must be preceded by a NEW TRANSACTION statement, which signifies a new transaction. You must use the NEW TRANSACTION statement for each transaction you define.

Table 10 Transaction Commands

Command | Description
ClassId = DWORDValue | Required. ClassId is the class identifier for the transaction. It is used in the distribution file to specify the distribution (that is, the pattern and frequency of requests) for this transaction. The recommended value ranges for a ClassId are 1 through100 for file transfer transactions, 101 through 201 for CGI transactions, 201 through 300 for ISAPI transactions, and 301 through 400 for post transactions, a type of HTTP request.
Server = StringValue | Server is either the NetBIOS name, DNS host name, or IP address of the server included in the transaction. Note that you can run a WCAT test with multiple servers.
NEW REQUEST HTTP | This command starts a new HTTP request. For more information on HTTP requests, see the next section.
NEW REQUEST CLEAR_COOKIE | This command starts a new CLEAR_COOKIE request. For more information on ClearCookie requests, see the “ClearCookie Request Commands” section, following.

HTTP Request Commands

The following commands are used to define a HTTP request. These commands must be preceded by a NEW REQUEST HTTP statement, and you must use the NEW REQUEST HTTP statement for each HTTP request you define in the script file.

Table 11 HTTP Request Commands

Command | Description
Cookie = StringValue | Specifies the cookie name to use. Any cookie sent back to the client as a result of this request is stored in this name. This request includes the cookie to be stored in this name.
Verb = StringValue | Specifies the verb to use for this request. Common verbs are GET, POST, and HEAD.
URL = StringValue | Specifies the URL to use for this request, for example /perfsize/file1k.txt
KeepAlive = BOOLValue | Specifies the client should use the “Connection: keep-alive” protocol.Doing so keeps the TCP/IP connection open between the client and the server between requests. This option should not be used in conjunction with the SSL protocol.
SSL = BOOLValue | Specifies the client should use the SSL encryption protocol for this request.
ResponseStatusCode = DWORDValue | Specifies the expected response code for this request. For most requests, this code is 200.
Port = WORDValue | Specifies the port for the TCP/IP connection for this request. For most requests, the port is 80.
UserName = StringValue | Specifies the user name for basic authentication.
Password = StringValue | Specifies the password for basic authentication.
RequestHeader = StringValue | Request headers are cumulative over a request. In other words, if you have multiple RequestHeader statements in the same HTTP request, they are all sent.
ResponseHeader = StringValue | Response headers are cumulative over a request. In other words, if you have multiple ResponseHeader statements in the same HTTP request, WCAT looks for all these headers in the response. If you have multiple response headers in the same ResponseHeader statement, they must be returned in the given order to pass the response comparison test.

Table 11 HTTP Request Commands (Continued)

Command | Description
Authentication = <DWORDValue> | For Authentication, 0 means anonymous and is the default; 1 means basic authentication.
SaveResponseFile = StringValue | The server’s response to the current request is saved on the client under the filename given. This command is provided to make creating a ResponseData file easier. For more information on ResponseData, see the following.
ResponseData = FileOrStringValue | Specifies the data the server should return in response to the current request. This data can be specified either as a quoted string or as a filename. If the latter, the file is read and transmitted to the client for comparison. Use a file if the data is large or contains nonprinting characters.
RequestData = FileOrStringValue | Specifies data to send to the server with this request. This option is generally used for POST requests.

ClearCookie Request Commands

A ClearCookie request command deletes a cookie name. The old name for the cookie is wiped out. This command must be preceded by a NEW REQUEST CLEAR_COOKIE statement, and you must use the NEW REQUEST CLEAR_COOKIE statement for each ClearCookie request you define.

Command syntax is as follows

Cookie = StringValue

where StringValue is the cookie name to be deleted.

Modifying the Distribution File

Each modified or new script requires a modified or new distribution file. The distribution file is used by the controller and the client computers to assign a percentage of total test time to each transaction. The controller also uses this file to calculate test results and write them to the log file.

The distribution file lists each of the transactions in the script file by using the class identifier assigned to the transaction. Each listed transaction is assigned a distribution value. The distribution value identifies the portion (percentage) of the experimental period during which each transaction is performed.

A sample distribution file is illustrated following.

# ###################################################################### # # Test WCAT Distribution File # # This file specifies the distributions that # can be applied to the script file # ###################################################################### # # Format of Script Specification: # # ClassId Distribution Factor(0 to 100) # # Sum of all distribution factors should be strictly 100 and # each factor can have only a single digit after the decimal point. # #First column is class number. Second value is percentage of test time. 1 10.5 29.5 310 470

To create a custom distribution file, you must list each transaction using the class identifier and provide a corresponding distribution value.


Using Your Web Applications in Custom Tests

You can create a custom test by using programs running on your Internet Information Server instead of the prepared test programs provided with WCAT. In addition to testing existing Web applications, you can use WCAT to evaluate programs as they are developed or during preproduction testing.

By using your programs in a WCAT test, WCAT can help you determine what programs need to be optimized to run on under Internet Information Server. For example, you can use WCAT to compare the functionality of different programs that provide file transfer, Web content, or security functions.

You can test the functionality of the following types of programs:

· Basic file transfer programs

· Common Gateway Interface (CGI) applications

· ISAPI extensions

· Secure Sockets Layer (SSL) programs

To use your own CGI application or ISAPI extension in a WCAT test, model your test on a CGI or ISAPI test provided with WCAT. In the URL field of the test script file, replace the reference to Wscgi.exe or Wsisapi.dll with the name of your CGI application or ISAPI extension.

You can also create your own HTTP keep-alive tests by adding the KeepAlive = TRUE operation to each transaction in the test script file. When creating your own tests, note that WCAT does not support HTTP keep-alives and the SSL protocol in the same test.

To run a WCAT test using your own programs, create a new script file and create HTTP transactions with the appropriate Cookie, URL, SSL, RequestHeader, ResponseHeader, SaveResponseFile, ResponseData, and RequestData values.


Changing Client Workloads

A client workload consists of a set of pages, also referred to as a transaction. Each page consists of a set of HTTP requests. In a minimal case, the workload might consist of one transaction containing just one request.

The sample files included with WCAT test different client workloads by varying the number of clients and their queries. You can create custom workload simulations by editing a prepared configuration file or by creating a new configuration file. The data that you change in the configuration is described in “Modifying the Configuration File,” earlier in this guide.

Note that you can also use the -m option with the run command at run time to change the number of clients that connect to the controller and send transactions to the server. For information about this option, see “Using Command Line Options,” earlier in this guide.

The prepared test Clntload, provided with WCAT, shows an example of how you might vary the client workload. Clntload specifies a variable client workload by running its test multiple times. The controller starts the first test with 4 client computers. Each time the test is run, the number of clients is incremented by 4, up to a maximum of 24. A log file is produced for each test. The log files are named in the format logFilePrefix.numberOfMachines.log


Creating Tests of Multiple Networks

The sample test configurations provided with WCAT are designed for a test environment based on a single, dedicated TCP/IP network. However, WCAT can be run in a multiple-network environment, and you can create a WCAT test to evaluate the performance of an Internet Information Server connected to multiple networks. This feature means you can simulate real-world production environments and evaluate the effect of connecting your Internet Information Server to multiple subnets. The following figure illustrates a multiple network model.

Figure 4 Multiple-network test model

To create a custom test by using multiple networks, each network must be connected to the other networks, either directly or by an intermediary network. Each network must support TCP/IP.

Before starting a multiple network test, verify all computers used in the test can connect to each other. For more information on doing so, see “Verifying Connections,” earlier in this guide. Note that you can optimize routing of client requests and network responses by using IP addresses rather than computer names or DNS host names.


Microsoft Web Capacity Analysis Tool Technical Specification

Microsoft® Web Capacity Analysis Tool
Technical Specification

© 1997 Microsoft Corporation. All Rights Reserved. The software (including instructions for its use) is provided "as-is" without warranty of any kind. Microsoft further disclaims all implied warranties including without limitation any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the software and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the software be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the software or documentation, even if Microsoft has been advised of the possibility of such damages. Because some states/countries do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation might not apply to you.


Abstract and Introduction

ABSTRACT

The rapid growth in use of the World Wide Web requires deployment of powerful servers running Hyper Text Transfer Protocol (HTTP) for publishing information. The growing client base on the Internet will increase the load on Web servers. In addition, dynamic content generation and proxy accesses to database backend will increase the demands on Web servers. Performance evaluation of various implementations of the service is of great importance. It is essential to analyze and evaluate the capacity limits of various servers. This will help server administrators with capacity planning and deploying suitable servers to meet their needs. The Web Capacity Analysis Tool (WCAT) is a simple and extendible tool for Web server capacity analysis. The Web Capacity Analysis Tool provides a framework of tools consisting of a controller and client software which help in measuring the performance of Web servers in architecture and system-independent manner. This paper discusses the architecture of the Web Capacity Analysis Tool, its workload mix, evaluation configurations, methodology, and method of reporting results. The Web Capacity Analysis Tool has the flexibility to evolve with the evolution in Web servers and server add-on components.

Introduction

The Internet is comprised of a loosely connected web of computers, each with the ability to publish and receive information. HTTP provides a way to publish information in documents containing hypertext links. The richness of connections and content offered via HTTP spurs the growth of Internet traffic. The traffic on the Internet—and demands on servers—is increasing day by day. In the past, HTTP servers were used primarily in the education market. Currently, commercial organizations are installing servers both on the Internet and intranets. Appropriate choice of platforms for hardware and software depend on performance of various systems. A consistent and reliable set of tools for evaluating capacity of these servers is essential for both designers and administrators alike. A good set of tools for evaluating Web servers is required. The tool should be easy to deploy and should provide the means and flexibility to evaluate performance. Results from the tool could be used in evaluation, analysis, and development. Web Capacity Analysis Tool supports extendible workload configurations and evaluation criteria and immensely simplifies capacity analysis. In this paper, we present the requirements, architecture, workload mix, and methodology of the Web Capacity Analysis Tool.


Requirements for the Web Capacity Analysis Tool

The Web Capacity Analysis tool must have the following features:
  • It must be easy to run and automate.

  • It must display hardware and software configurations along with results, whenever possible to provide a comprehensive summary.

  • It must produces one comprehensive rating number if possible.

  • It must include at least one simple test that covers all functionality and runs in less than one hour.

  • It must cover all possible functionality, including basic file transfer, Common Gateway Interface (CGI), Internet Server API (ISAPI), and Secure Sockets Layer (SSL) / Private Communications Technology (PCT) protocols. It should be easily extendible.

  • The server tested must be an uncontrolled entity ("black box.")

  • The tool must run multithreaded clients in a single client process. Using threads instead of multiple processes makes client bottlenecks less likely and increases the load on the servers.


 Web Capacity Analysis Tool Architecture

This section discusses the architecture of the Web Capacity Analysis Tool.
Figure 1, below, depicts the components of the Web Capacity Analysis Tool architecture and their relationship to each other.

Figure 1. Web Capacity Analysis Tool architecture

The Web Capacity Analysis Tool consists of four components: a network, a server, a controller and n clients (n = 1 .. 200).


Network

The Web Capacity Analysis Tool assumes a dedicated network for running the performance tests. You can run with a busy network, but it will affect the results of your test.


Web Capacity Analysis Tool Server

The Web server is an uncontrolled entity (a "black box") consisting of all the documents requested by clients during a test.


Web Capacity Analysis Tool Controller

The controller is the central component of the Web Capacity Analysis Tool. It initiates and monitors the tests. At the end of a test it collects data from clients, summarizes them in a standard form and stores them in log files. The controller is responsible for monitoring the evaluation system. The user initiates a test by running the Web Capacity Analysis Tool controller program. The controller sends the workload and other configuration data to clients and asks them to execute. The controller summarizes the data to log files which can be post processed. The controller and clients communicate over sockets using TCP, with the controller listening at a well-advertised port (currently it is 7232). The controller gets input from the command line that specifies names of input files and other parameters. The input files include:
  • Configuration file (extension: .cfg),which specifies the configuration to use for a given run.

  • Script file (.scr), which defines the pages to be downloaded.

  • Distribution file (.dst), which specifies the weighted distribution of the script pages (split between various classes). The sum of the weighted distributions must be 100%.

  • Performance counter file (.pfc), an optional input file. The performance counter file specifies which performance counters to monitor while the server is running. This feature lets you examine the dynamic behavior of the server by using the performance counters that are visible over RPC.Figure 2, below, depicts the inputs to and outputs from the Web Capacity Analysis Tool controller program.

    Figure 2. Web Capacity Analysis Tool Controller


Controller Behavior

The actions of the Web Capacity Analysis Tool Controller during a test are summarized in the following list and then described in the paragraphs that follow. During a test, the Web Capacity Analysis Tool Controller performs the following actions, in the order presented:
  1. Parse command line input

  2. Parse configuration, script and distribution files

  3. Allow specified number of clients to connect

  4. Send the clients the parsed information

  5. Begin collecting performance counter information (if specified)

  6. Wait for specified duration

  7. Stop collecting performance counter information

  8. Collect client results

  9. Summarize client results and performance counter information into the log file.

The controller parses the configuration, script, and distribution files and constructs the messages for client. It then creates a listen socket and waits on the Web Capacity Analysis Tool controller port. Clients connect to the socket one after another. The controller sends messages to clients after all of the clients are connected. First, it sends the configuration message, then the script header message, followed by a list of script page messages, one for each page. Clients start the performance run when they receive the complete set of messages. Most tests include a warm-up and a cool-down period. The clients do not make any measurements during these periods, but attempt to bring the server to full load. Also, these periods blank out the time when there is some net traffic between controller and clients. During the steady state between the warm-up and cool-down periods, the clients run for the specified duration of the test and take measurements. At the end of the cool-down period, the clients summarize data from each individual thread and send a statistics message back to the controller. After all the clients have reported back the statistics, the controller sums all data and summarizes both individual and summed results to a log file (.log). Optionally, users can specify a list of performance counters to monitor on the server during the test. The controller samples the specified counters at 10-second intervals and writes the sampled values to a separate performance counter log file (.prf). After parsing command line arguments and input files, the controller starts the sampling thread. The controller stops sampling after receiving responses from all clients. The controller also averages the counters over the period between start of clients and before reception of any statistics and reports averaged value of each counter in the log file.


Web Capacity Analysis Tool Client

The Web Capacity Analysis Tool client is simple, extendible, and fast. The client program runs in a single, multithreaded process. The client program connects to the controller, receives the jobs to be executed, executes commands and returns results. At the end of the run, the clients submit the results of the run (statistics) to the controller. One common approach to Web server testing is to use one process per client. This approach is costly to control, monitor, and execute on client computers. To avoid this overhead, the Web Capacity Analysis Tool uses multiple threads in one client process per computer. This simplifies control because the controller has to talk to just one process on each client computer. In addition, being multithreaded increases speed of execution and eases summarization of results for each client machine. Figure 3, below, depicts the communication between the Web Capacity Analysis Tool Client and Controller programs.

Figure 3. Web Capacity Analysis Tool Client


Client Behavior

The actions of the Web Capacity Analysis Tool Client during a test are summarized in the following list and then described in the paragraphs that follow. During a test, the Web Capacity Analysis Tool Client performs the following actions, in the order presented:
  1. Parse Command Line

  2. Connect to Controller

  3. Receive parsed information from Controller

  4. Spawn specified number of threads

  5. Run for specified time

  6. Summarize statistics for all threads

  7. Send summary statistics to controller

The Web Capacity Analysis Tool client program runs with a single standard parameter which specifies the controller name and an optional parameter specifying the controller port offset. The client attempts to establish a connection to the controller. If the client fails to connect, it continues to retry after 10 seconds. The retry mechanism assures that you do not have to restart clients manually. If a test requires fewer computers than the number of available client computers, the extra clients that fail to connect loop while connected clients execute the test. You can adjust the controller to assure that the right number of clients are connected. After connecting to the controller, the client receives all messages sent by the controller. The controller sends messages to clients in the order in which the clients connected to the controller. When a client has received its messages, the client starts the specified number of threads to perform the raw communication job with the server specified. When the warm-up period ends, the main thread directs all client threads to start measuring performance. The main thread sleeps for the duration of the test, after which it signals client threads to enter the cool-down period. After the cool-down period, the main thread collects statistics from each individual thread and summarizes them. Finally, it sends the statistics message containing the summary to the controller. All client threads are identical. Each thread loops, generating a random number. This random number is used an index into an array listing the class IDs corresponding to the specified distribution. The thread selects a script page from a list of script pages corresponding to the class ID. Then, the thread requests the page from the server. Each page request can involve multiple file downloads or CGI or ISAPI script runs. During the request operation, the thread updates a thread-local copy of the statistics.


Web Capacity Analysis Tool Files

The Web Capacity Analysis Tool comes with many ready-to-run tests. In addition, you can create your own Web Capacity Analysis Tool tests by modifying the input files for existing tests or creating new files from scratch. This section of the paper describes the Web Capacity Analysis Tool input files and the parameters specified in them.


Configuration File

This file (extension: .cfg) specifies the configuration for running an test. It specifies following parameters:
  • Duration: Duration of the test, in seconds or minutes.

  • NumClientMachines: Number of client computers to use for the test. If more computers try to connect to the controller, the controller ignores the excess computers. If fewer computers try to connect, the controller waits for more computers.

  • ClientMachinesMin: Minimum number of client computers to use for the test. This value is useful for incremental-load tests. The controller starts the test using the minimum number of client computers (ClientMachinesMin) and increments in steps specified by ClientMachinesIncrement until the load reaches ClientMachinesMax. If present, these values override the value specified in NumClientMachines.

  • ClientMachinesMax: Maximum number of client computers to use for the test.

  • ClientMachinesIncrement: Specifies the increment to be used in incremental-load tests.

  • NumClientThreads: Number of client threads to run on each client computer. This number increases the parallelism possible within the client process and, hence, increases the load on the server.

  • WarmupTime: Length of warm-up mode, in seconds. No statistics information is collected during warm-up. The controller also does not average performance counters during this interval.

  • CooldownTime: Length of cool-down mode, in seconds. During this period, clients continue to make requests to the server, but do not include the results in the statistics sent back. This serves to smoothly bring the load down without an abrupt stop.

  • ThinkTime: Maximum duration to wait before requesting next page. In the real world, no one continuously downloads file, except software robots. Most users take a considerable time before they make the next request. The client generates a random-number between 0 and ThinkTime. Then the client sleeps for that duration before requesting the next page.

  • MaxRecvBuffer: Recommended size of the receive buffer in the client computer. The receive buffer is used when downloading pages from the server.

  • SockRecvBuffer: Recommended size of sockets receive buffer on the client computer. The size of the buffer can affect the way data is transferred in packet-based transports like TCP/IP. The default value is 0, which recommends using the client system’s default size.

  • Author: Text entered appears in the Author field in the log file.

  • Date: Text entered appears in the Creation Date field in the log file.

  • Comment: Text entered appears in the Comment field in the log file.


Script File

The script file (extension: .scr) specifies the HTTP transactions to be executed. Each transaction consists of one or more simple HTTP requests that are executed in sequence. The transactions are grouped into equivalence classes. Each class is assigned a number identifying the class. All of the HTTP transactions in a class are executed at the same relative frequency, as specified in the Distribution File. When a particular class is specified in the Script file, the WCAT client randomly chooses one of the transactions belonging to the class. Because many transactions are in same class, clients requesting a class of transactions do not request the same pattern of pages each time. HTTP transactions consist of one or more simple requests. Each request specifies the URL to request and the Verb to send. The request also can include other characteristics of the request. See the Appendix to this paper for a complete specification of the script file format. Distribution File The distribution file (extension: .dst) specifies the distribution pattern used for requesting classes of pages listed in the script file. The Web Capacity Analysis Tool divides the pages into classes and uses class IDs for each class. The distribution file specifies the distribution with weights for each class. Each line in the distribution file consists of two fields.
  • The first field specifies the class ID.

  • The second field specifies the weight for that class. The weights are decimal numbers with at most one digit after the decimal point. The sum of the weights must be 100 percent.When the controller parses the distribution file, it checks for uniqueness of the class IDs specified. It also verifies that there is at least one page in the specified scripts with same class ID. After parsing the distribution file, the controller eliminates unwanted script pages, to avoid sending them to clients. Because the Web Capacity Analysis Tool keeps the distribution pattern and the script-based class assignments in separate files, you can use the same script file with multiple distribution files. You can also perform per-class operations.


Performance Counters File

The performance counter file (extension: .pfc) specifies the counters to be monitored on the server while the test is running. Many system counters and user-level counters are exposed to the user locally and remotely. The Web Capacity Analysis Tool controller remotely samples the performance counters and averages them during the test. The data collected can help to identify and trace the dynamics of the system. All counters to be monitored are specified in the performance counter file. Each line in this file specifies one counter. The name of the counters should match the names visible when Performance Monitor is started. The controller samples the counters once every 10 seconds and writes data to file with same prefix used for the log file, but with the extension .prf.


Log File

The log file (extension: .log) contain results of the test in a standard format that spreadsheets applications can read them easily. The information in log files consists of the configuration data (given as input), summary statistics from each client, and a summary of all client statistics. It also includes the average values of any performance counters requested in the .pfc file. The Web Capacity Analysis tool creates a log file for each test. The log file can be processed off-line. This makes it possible to run the controller in a completely automated manner, and process logged data at a later date.


Recommended Workloads

Given the evolutionary nature of the Internet and Web servers, it is hard to determine the exact workload. There are some quantitative studies that evaluate the load and traffic on servers. It is hard to emulate exact scenarios of the workload, but you can use the Web Capacity Analysis Tool to emulate repetitious page fetches in random and distributed fashion. It is wise to model workloads on data from many different real-world Web servers, including HTTP proxy servers used by corporations. It is more logical to gather this information from access servers, because the information will represent the client end of access to HTTP servers. You should determine the workload mix based on your server’s anticipated use. The following is rough outline of a recommended workload:
  1. A series of page transfers of different file sizes ranging from 512 bytes through 1M.

  2. A weighted mix of page transfers with file sizes from 512 through 1M bytes, in single and multiple directories. The workload can vary in the amount of the data set present, ranging from 0.5MB to 200MB.

  3. A mix of pages with files and ISAPI transfers

  4. A mix of pages with files and CGI transfers

  5. A mix of pages with files, ISAPI, and CGI transfers.

  6. ISAPI with ODBC and database integration.

  7. SSL and Personal Communications Technology (PCT) encrypted data transfer using above combinations.

  8. Persistent connection (HTTP keep-alive) page transfers using above combinations.


Results

At the outset, we wanted to find a high throughput mark for any given hardware and software platform. In addition, we wanted to look at price/performance measure of various servers. The Web Capacity Analysis Tool reports data related to configuration, page downloads, bytes received (sent by server), connection throughput, average and maximum connect times, average and maximum response times. In addition to reporting results based on log files, you should note the configuration of the system, such as the processors, hard disk, network adapter, software tuning, and any additional uses besides running the server.


Testing the Web Capacity Analysis Tool

Network monitoring and performance testing have confirmed that the Web Capacity Analysis Tool is transmitting, receiving, and monitoring data as designed. We tested WCAT on many tasks, such as processing requests from ISAPI extension and CGI applications, using Secure Sockets Layers protocol and maintaining persistent connections. However, the Web Capacity Analysis Tool is offered "as is" in accordance with the disclaimer of warranty in the Windows NT Server Resource Guide Supplement 1.


Conclusion

The Web Capacity Analysis Tool is a tool for evaluating Web servers. It features an easy-to-use setup involving one controller, and a client application for use in a quiet network solely dedicated for performance evaluation. It also provides an extendible way of modifying the test parameters and pages transferred. Appendix: Script File Format This appendix describes the format of the Script file for a Web Capacity Analysis Tool test. The Script file is submitted to the Web Capacity Analysis Controller for execution. The Script file is identified by the filename extension .scr.


Transactions and Requests

Script files consist of a series of transactions. Each transaction describes a request. Both transactions and requests have fields that can be changed to specify the characteristics of the transaction or request. For example, transactions have a classId field and requests have a URL field. You can also designate some field entries as defaults so you do not need to specify the entry in each transaction or request.
  • Transactions begin with the line NEW TRANSACTION.

  • Requests begin with the line NEW REQUEST CLEAR_COOKIE or NEW REQUEST HTTP. CLEAR_COOKIE requests delete the value of the stored cookie. HTTP requests do browser requests to the given server.


Fields

Transactions and request have four types of fields. The field types are:
  • Strings which are quote-delimited character strings such as “test_server.”For example, URL = “/test.htm”
  • Files which are strings preceded by the word FILE. The content of a string usually refers to one or more files on the controller computer.For example, RequestData = FILE “request.dat”
  • Booleans which are the word TRUE or the word FALSE.For example, KeepAlive = TRUE
  • Numbers whch refer to decimal numbers.For example, ServerPort = 80


Transaction Fields

This section lists and describes the fields in a Script file transaction.

classId

This is the classId that the given transaction is a member. Default value is 1. This is a Number value.

Server

This is the server that the transaction refers to. This is a String value

HTTP Request Fields

This section lists and describes the fields in a Script file request.

Cookie

This is the name of the cookie file to use for this transaction. This is a String value. Note that no file is actually created, it is stored in memory on the client machine. Default value is no cookie.

Verb

This is the verb to use for the request. This is a String value. Default value is “GET”.

URL

This is the URL to use for the request. This is a String value. Default value is “/”.

KeepAlive

This is set to TRUE to enable keep-alives on the connections. This is a boolean Value. Default value is FALSE.

SSL

This is set to TRUE to enable SSL on the connection. This is a boolean value. Default value is FALSE. NOTE: Do not use KeepAlive and SSL together. There is bug in WebCat which causes that combination to fail.

ResponseStatusCode

This is the expected response status code from the server. This is a Number value. Default value is 200.

Port

This is the Tcp port to connect to. This is a Number value. Default value is 80.

UserName

This is the user name to use for authentication. This is a String value. No default value.

Password

This is the pass word to use for authentication. This is a String value. No default value.

RequestHeader

This is a header to pass along with the HTTP request. This is a String value. No default value.

ResponseHeader

This is a header that is expected to be returned by the server. This is a String value. No default value.

Authentication

This is the authentication method to use. This is a numeric value. Default value is 0. Valid values are, 0-anonymous, 1-basic.

SaveResponseFile

This is the name of a file to save the response data from a request into. This is used to save a response from a request so that it can be used with a ResponseData field to do data validation. The response file is stored on the Client machine. This is a String value. No default value.

ResponseData

This is the data that is expected to be returned by the server in the body of the response. This is a File or String value. No default value.

RequestData

This is data that is sent to the server during the HTTP request after the headers. It is used for POST and PUT requests. This is a File or String value. No default value.


Clear_Cookie Request Fields

Cookie

This is the name of the cookie file to clear. This is a String value. Note that no file is actually created, it is stored in memory on the client machine. No default value.


Topic Not Found

No matching topic was found. Some possible reasons and remedies are as follows:

  • The file (.chm) that contains the destination topic is not in the expected location.

    Remedy: Rerun the MSDN Library Setup.

  • The file (.chm) that contains the current topic or destination topic is out-of-date and the link is no longer valid.

    Remedy: Install the latest version of the MSDN Library.

  • The MSDN Library CD is not in the CD-ROM drive.

    Remedy: Insert the MSDN Library CD into the CD-ROM drive.