Copyright: Concepts and Planning Guide
Citation: Concepts and Planning Guide


Introduction to Windows NT Server
Chapter 1	1 of 4

Introduction to Windows NT Server

The Microsoft [image] Windows NT [image] Server operating system is designed for use on local area network (LAN) servers. It provides the power, ease of use, and scalability of Windows NT on a server platform, and features such as centralized security administration and powerful fault tolerance make it an ideal operating system for use on network servers.

Windows NT Server is both a personal computer operating system and a network operating system. By having networking built into the operating system, Windows NT Server networking is well-integrated with the base operating system, and network functions are easier for you to use and manage.

This chapter provides a brief overview of the features of Windows NT Server and explains how Windows NT Server works with other Microsoft networking software. It also discusses the purpose and use of this manual.


Overview of Windows NT Server
Introduction to Windows NT Server	2 of 4

Overview of Windows NT Server

Windows NT Server is a platform-independent, scalable server operating system. It runs on systems with Intel [image] x86, reduced instruction set computing (RISC), and DEC [image] Alpha processors, giving you more freedom in choosing your computer systems. It is scalable to symmetric multiprocessing systems, where you can add extra processors if you need higher performance.

Internally, it has a full 32-bit architecture. Its 32-bit flat memory model does away with 64K memory segments and the 640K barrier of MS-DOS [image]. It has multiple threads of execution, allowing applications to be more powerful, but memory protection assures stability by providing the operating system and applications with separate memory spaces to prevent data corruption. And its preemptive multitasking lets the operating system allocate processing time to each application efficiently.

Windows NT Server also includes the networking features briefly discussed in the following sections and explained thoroughly in later chapters of this manual.

Open Networking Architecture

Both the Network Driver Interface Specification (NDIS) and Transport Driver Interface (TDI) standards are supported. NDIS is an interface standard for communication between network adapter card drivers and network protocols. NDIS enables you to mix and match network cards and protocols without needing a different version of your network protocol for each type of network card you have. It also lets you use multiple protocols on a single network card. Four NDIS-compliant network protocols - Transmission Control Protocol/Internet Protocol (TCP/IP), Microsoft NWLink, NetBIOS extended user interface (NetBEUI), and Data Link Control - are shipped with Windows NT Server. The TDI interface works between the network protocol and the upper-level network software (such as the server and the redirector). With TDI, the redirector and server don't have to communicate directly with or know anything about your network protocols, and you can use alternate protocols or even alternate servers or redirectors with Windows NT Server. Remote procedure call (RPC) applications, network basic input/output system (NetBIOS) applications, and Windows Sockets applications are also supported.

Network Installation

You can install Windows NT on workstations over the network, instead of using floppy disks or a CD-ROM for each workstation. Installing over the network is easier because you don't have to move installation media from computer to computer.

Built-In Security

Windows NT Server builds security into the operating system. Discretionary access control enables you to assign permissions on individual files. The concept of user rights also gives you discretionary control over basic system functions, such as setting the computer's clock and shutting down the computer. Complete auditing capabilities are also provided.

Centralized Security Administration

You can set up domains and trust relationships to centralize your network's user account and other security information in one place, making the network easier to manage and easier to use. With centralized security administration, you have only one account to manage for each user, and that account gives the user access to all network resources.

Configuration Registry

Windows NT Server and Windows NT Workstation maintain a database called the Registry. This database contains information about the operating system, the computer, and the users who have logged on at this computer in the past. Applications aware of Windows NT can also store initialization information in the Registry.

The Registry replaces the need for separate configuration files such as CONFIG.SYS, AUTOEXEC.BAT, LANMAN.INI, WIN.INI, and PROTOCOL.INI. However, to support applications written to use CONFIG.SYS and AUTOEXEC.BAT, Windows NT automatically maintains and uses versions of these files containing only application information.

Management of User Workstations

The user profiles in Windows NT Server enable you to provide greater ease of use to users and, at the same time, restrict their abilities at their own workstations, if needed. To use profiles for greater user productivity, you can store at a server a profile containing all the user's preferences and settings, such as network connections, program groups, and even screen colors. This profile is used whenever the user logs on at any Windows NT computer, so that the user's preferred environment follows the user from workstation to workstation. To use profiles to restrict users' abilities, you add can add restrictions to the profile - such as preventing the user from changing the program groups and items you set up, and disabling parts of the Windows NT interface when the user is logged on.

Network Printing Management

Windows NT includes a powerful Print Manager interface, simplifying how administrators set up and manage printers, and also simplifying how users browse and connect to printers. Users of Windows NT computers who connect to printers shared by computers running Windows NT Server do not need to have printer drivers installed on their workstations. Windows NT Server also fully supports network-interface printers (such as the Hewlett-Packard [image] LaserJet [image] IIIsi), which have a built-in network adapter card and attach directly to network cable, rather than to a serial or parallel port on a server.

Tape Backup

Windows NT includes a tape backup utility, which supports centralized backup of the hard drives of network computers, including Microsoft LAN Manager 2.x servers, Windows NT Workstation computers, and Windows [image] for Workgroup computers, as well as servers running Windows NT Server.

Performance Monitoring

Windows NT Server includes a sophisticated performance-monitoring utility. You can use this tool to track, graph, and log hundreds of specific types of performance data statistics, in general categories such as network server traffic, disk performance, processor usage, and server and workstation statistics.

The performance monitor tool lets you monitor the performance of many remote computers at once, so that you can track and compare the performance and usage of many servers at once.

Network Activity Tracking

Windows NT Server provides many tools for network activity and usage tracking. You can view servers and see what resources they are sharing; view the users currently connected to any network server and see what files they have open; log and view security auditing entries; keep sophisticated error logs; and specify that alerts be sent to administrators when certain events occur. If your network uses the TCP/IP protocol, you can also configure Windows NT computers to provide information readable by a Simple Network Management Protocol (SNMP) management utility.

Remote Administration

Remote administration is supported for all network management functions, including server management, security management, printer administration, and performance monitoring. You can use one network computer to monitor the activities on any network server.


How Windows NT Server Works with Other Network Software
Introduction to Windows NT Server	3 of 4

How Windows NT Server Works with Other Network Software

Windows NT Server is designed for use on network servers on large networks. Windows NT Server works smoothly with several other Microsoft network operating systems.

Windows NT Workstation is the ideal operating system for high-powered clients on your network. Windows NT Workstation is intended for power users, software developers, and mission-critical applications. Windows NT Workstation brings many of the same security features found in Windows NT Server to the desktop. And like Windows NT Server, both security and networking are built into the operating system.

If you want built-in networking but don't need the power of Windows NT, Windows for Workgroups may be the answer. Windows for Workgroups runs on MS-DOS computers and builds in workgroup networking to the popular Windows 3.1 operating system. Like Windows NT Workstation and Windows NT Server, Windows for Workgroups includes mail and scheduling applications for workgroup productivity.

Windows NT Server also interoperates with Microsoft LAN Manager 2.x systems. MS-DOS, Windows 3.1, and OS/2 [image] computers running LAN Manager workstation software can access servers running Windows NT Server. LAN Manager 2.x servers (on both OS/2 and UNIX [image] computers) can also work with servers running Windows NT Server - even in the same domain.

This family of products lets you scale your network according to your needs. You can have anything from a large network with many servers running Windows NT Server along with hundreds of Windows NT workstations, down to a small network with a single Windows NT Server and MS-DOS client computers.


How to Use This Manual
Introduction to Windows NT Server	4 of 4

How to Use This Manual

This manual explains the concepts behind Windows NT Server. By reading this manual you can gain an understanding of how Windows NT Server works and how you can use it to enhance your LAN.

This manual does not provide step-by-step instructions for completing any tasks. For step-by-step instructions, see the Windows NT Server System Guide (for detailed procedures on all aspects of Windows NT Server) or the Windows NT Server Network Operations Quick Reference (for server-related procedures).


Choosing Network Drivers and Protocols
Chapter 2	1 of 12

Choosing Network Drivers and Protocols

When setting up Windows NT on your network, you must choose which types of network adapter card drivers and protocols to use. Because Windows NT has an open architecture, you have a lot of flexibility in this decision. Windows NT supports both the Network Driver Interface Specification (NDIS) and Transport Driver Interface (TDI) standards. These standards allow Windows NT to communicate with many other networking products and make it possible for you to choose from a variety of network adapter cards and protocols for your network.

Windows NT also supports a version of STREAMS, the protocol interface and environment originally developed on UNIX System V Release 4.0. The support of a STREAMS-compatible environment means that protocols originally developed for STREAMS on UNIX can easily be ported to Windows NT.

Before exploring the specific drivers and protocols supported by Windows NT, you should understand both the OSI Reference Model and the purpose of network card drivers and transport protocols. If you already understand these topics, you can skip ahead to "Advantages of NDIS," later in this chapter.


Understanding the OSI Reference Model
Choosing Network Drivers and Protocols	2 of 12

Understanding the OSI Reference Model

In 1978, the International Standards Organization (ISO) developed a model for computer networking called the Open Systems Interconnect (OSI) Reference Model. The model describes the flow of data in a network, from the physical connections of the network up to the applications used by the end user.

The OSI Reference Model includes seven layers, as shown in the following figure. The lowest layer, the Physical Layer, is where data bits are transferred to the physical cable. At the top, the Application Layer is where applications are presented to users.

The Physical Layer is responsible for getting bits from one computer to another, and it regulates the transmission of a stream of bits over a physical medium. This layer defines how the cable is attached to the network adapter card and what transmission technique is used to send data over the cable. It also defines bit synchronization and checking.

The Data Link Layer packages raw bits from the Physical Layer into frames. A frame is a logical, structured packet in which data can be placed. The Data Link Layer is responsible for transferring frames from one computer to another, without errors. After the Data Link Layer sends a frame, it waits for an acknowledgment from the receiving computer. Frames that are not acknowledged are resent.

The Network Layer addresses messages and translates logical addresses and names into physical addresses. It also determines the route along the network from the source to the destination computer, and manages traffic problems, such as switching, routing, and controlling the congestion of data packets.

The Transport Layer takes care of error recognition and recovery, ensuring reliable delivery of messages. It also repackages messages when necessary by dividing long messages into small packets for transmission, and at the receiving end, rebuilding the small packets into the original message. The receiving Transport Layer also sends an acknowledgment of receipt.

The Session Layer allows two applications on different computers to establish, use, and end a session. This layer establishes dialog control between the two computers in a session, regulating which side transmits, when, and for how long.

The Presentation Layer translates data from the Application Layer into an intermediary format. This layer also manages security issues by providing services such as data encryption, and compresses data so that fewer bits need to be transferred on the network.

The Application Layer is the level at which end-user applications can access network services.

When two computers communicate on a network, the software at each layer on one computer assumes it is communicating with the same layer on the other computer. For example, the Transport Layer of one computer communicates with the Transport Layer on the other computer. The Transport Layer on the first computer has no regard for how the communication actually passes through the lower layers of the first computer, passes across the physical media, and then up through the lower layers of the second computer.

The OSI Reference Model is an idealized version of networking, and few systems follow it exactly, but the model is used for the discussion and comparison of networks. The rest of this chapter discusses which components of Windows NT work at the various layers of the model.


What Network Card Drivers and Protocols Do
Choosing Network Drivers and Protocols	3 of 12

What Network Card Drivers and Protocols Do

A network adapter card (sometimes called network interface card or NIC) is a hardware card that is installed in a computer to enable the computer to function on a network. The network adapter card provides port(s) for the network cable to physically connect to, and the card physically transmits data from the computer onto the network cable and vice versa.

Every network computer must have a network adapter card driver, a software driver that controls the network card. Each network adapter card driver is specifically configured to run with a certain type of network card.

In addition to the network card and network card driver, a network computer must also have a protocol driver (sometimes called a transport protocol or just a protocol). The protocol driver works between the upper-level network software - such as the workstation and server - and the network adapter card. The protocol packages data that is to be sent on the network in a way that the computer on the receiving end can understand.

The process of associating a protocol driver with the network adapter card with which it will work, and establishing a communication channel between the two, is called binding.

In order for two computers to communicate on a network, they must use identical protocols. Sometimes, a computer is configured to use multiple protocols. In this case, two computers need only have one protocol in common to be able to communicate. For example, a server using both NetBEUI and TCP/IP can communicate with both workstations using only NetBEUI and with workstations using only TCP/IP.

With some networks, each computer's network adapter card driver and protocol are separate pieces of software. With other networks, a single piece of software called a monolithic protocol stack performs the functions of both the network adapter card driver and the protocol.

The following illustration shows how these types of drivers fit in with the OSI networking Reference Model.

Windows NT supports NDIS (version 3.0), which lets you use separate protocols and network adapter card drivers. All network card drivers and protocols shipped with Windows NT Server conform to NDIS.


Advantages of NDIS
Choosing Network Drivers and Protocols	4 of 12

Advantages of NDIS

NDIS provides a set of standards for protocols and network adapter card drivers to communicate. So, on any workstation, you can use any combination of any protocol driver(s) that conforms to NDIS along with any network adapter card driver that conforms to NDIS. (All of the network card drivers and protocol drivers provided with Windows NT conform to NDIS standards.)

It is probable that the computers on your network will have different types of network adapter cards and thus require different network adapter card drivers. Because of NDIS, you can use exactly the same protocol driver with each of these workstations and not be required to have a different version of your protocol for each type of network adapter card, as you would be required if you were using monolithic protocol stacks.

Also, NDIS allows multiple protocols to use a single network card. Usually, when you use a monolithic protocol with a network adapter card, the protocol monopolizes the network card, preventing you from using other protocols with that card.

When a computer has multiple protocols, the computer transmits data first using one protocol, then again using the next protocol, and so on. When you install multiple protocols on a computer, you designate the order in which the computer will use them. The first protocol in this series is sometimes called the primary protocol.

On a Windows NT computer, each binding of a protocol to a network adapter card has a LAN adapter number assigned to it. (For example, one protocol bound to two network cards requires two LAN adapter numbers; two protocols each bound to two cards requires four LAN adapter numbers.) When you install Windows NT on a computer (and when you install additional protocols or network adapter cards), Windows NT automatically assigns LAN adapter numbers to protocol/network adapter card bindings. You need to change these LAN adapter numbers only if you have a NetBIOS application that specifies that it must use a certain LAN adapter number. (For instructions on setting LAN adapter numbers, see the section about the Network option in the Control Panel chapter of the Windows NT Server System Guide.)


Choosing a Network Adapter Card
Choosing Network Drivers and Protocols	5 of 12

Choosing a Network Adapter Card

Usually, each specific model of network adapter card supported by Windows NT has one network adapter card driver supporting it. The driver is either provided with Windows NT or is supplied by the card manufacturer. So, the choice of a network adapter card driver is really a choice of a network adapter card.

When you choose network adapter cards, you first must be sure to choose cards that support your network's architecture (such as Ethernet or token-ring) and cabling media (such as Thinnet or twisted-pair). Beyond that, look at both performance and cost, and the trade-offs between the two.

Performance in network adapter cards depends mostly on bus width and onboard memory. The bus width of a network card is the number of pins used to connect the card to the computer bus. The best performance comes when the bus width of the card matches most closely the internal bus width of the computer. Onboard memory allows a card to buffer frames going to and from the network. A card with the most memory isn't always best, because after a point, diminishing returns and the maximum speed of other network components limit the performance gains of onboard memory.

Some cards also have onboard processors (these are often called smart cards). With Windows NT, however, smart cards are not much of an advantage, since Windows NT and its drivers perform most of the network processing.

When you consider the cost of network cards, you should factor in the cost of buying spare cards to replace those that fail. And be sure your network hardware budget leaves room for cable, hubs, repeaters, routers, and other hardware besides cards, as well as the labor it will cost to install them.

Before you invest in a type of network card, make sure that an NDIS-conforming driver exists for the card. Also, make sure the vendor has enough of a support infrastructure to meet your business needs. If you are dealing with a reseller, check that the reseller has a good communications path with the card's manufacturer.

With Windows NT, when you install a network card in a computer, installation of the appropriate driver is simple. You just use either the Setup program or the Networks option in the Control Panel, and choose the name of the network adapter card from the list. The network card driver is automatically bound to all NDIS protocols currently running on the computer, and if any protocols are added later, they will also automatically be bound to the network card driver.


Choosing a Protocol
Choosing Network Drivers and Protocols	6 of 12

Choosing a Protocol

Microsoft provides four protocols for use with Windows NT: TCP/IP, NWLink, NetBEUI, and Data Link Control. You must choose how to use one or more of these protocols on your network. The following sections discuss uses, advantages, and disadvantages of each.


How TCP/IP Works
Choosing Network Drivers and Protocols	7 of 12

Choosing a Protocol

How TCP/IP Works

TCP/IP stands for Transmission Control Protocol/Internet Protocol. It was developed in the late 1970s, resulting from a Defense Advanced Research Projects Agency (DARPA) research project on network interconnection. The major advantage and use of TCP/IP is that it is a standard, routable protocol, and is the most complete and accepted protocol available. It provides communication across interconnected networks with different operating systems and hardware architectures, such as UNIX and mainframes, as well as Windows NT.

TCP/IP also provides compatibility with the Internet, the collection of networks and gateways linking together many worldwide universities, corporations, government offices, and military installations. In addition, TCP/IP is required for use of SNMP network management. You can use SNMP to monitor any Windows NT computer that runs TCP/IP as either its primary or an additional protocol.

TCP/IP offers the Windows Sockets 1.1 interface, a cross-platform client-server framework which is ideal for developing client-server applications that can run with Windows Sockets-compliant stacks from other vendors. Windows Sockets applications can also take advantage of other networking protocols such as Microsoft NWLink.

Microsoft TCP/IP uses the NetBIOS interface, commonly known as Request For Comments (RFC) NetBIOS. Microsoft also ships several TCP/IP utilities for use with TCP/IP on Windows NT.

The following table summarizes the advantages and disadvantages of using TCP/IP. For complete information on TCP/IP in Windows NT, see Windows NT Server TCP/IP.

Advantages		Disadvantages
Most widely accepted protocol Provides connectivity across operating systems and hardware platforms Provides Internet connectivity Routing support Windows Sockets support SNMP support		Not as fast as NetBEUI on small LANs


How NWLink Works
Choosing Network Drivers and Protocols	8 of 12

Choosing a Protocol

How NWLink Works

Microsoft NWLink is an NDIS-compliant version of the Internetwork Packet Exchange (IPX/SPX) protocol, which is used on Novell® NetWare® networks.

NWLink is compatible with TDI, as well as NetBIOS and Windows Sockets, a Windows NT version of the Sockets interface originally developed for UNIX computers.

NWLink provides a protocol compatible with the Novell NetWare IPX/SPX protocol. To further enhance Windows NT compatibility with NetWare, Windows NT also provides Client Service for NetWare and Gateway Service for NetWare. For more information, see Windows NT Server Solutions for NetWare Networks.

Advantages		Disadvantages
Provides compatibility with Novell NetWare		Not as fast as NetBEUI on small LANs


How NetBEUI Works
Choosing Network Drivers and Protocols	9 of 12

Choosing a Protocol

How NetBEUI Works

NetBIOS extended user interface (NetBEUI) was first introduced by IBM in 1985. It is a small, efficient, and fast protocol.

When NetBEUI was developed in 1985, it was assumed that LANs would be segmented into workgroups of 20 to 200 computers and that gateways would be used to connect that LAN segment to other LAN segments or a mainframe.

NetBEUI is optimized for very high performance when used in departmental LANs or LAN segments. For traffic within a LAN segment, NetBEUI is the fastest of the protocols shipped with Windows NT.

The version of NetBEUI shipping with Windows NT is NetBEUI 3.0. NetBEUI 3.0 corrects some limitations in previous versions of NetBEUI, including the following:

NetBEUI 3.0, along with the TDI layer, eliminates the previous limitation of 254 sessions to a server on one network adapter card.

NetBEUI 3.0 is completely self-tuning.

NetBEUI 3.0 provides much better performance over slow links than did previous versions of NetBEUI.

Strictly speaking, NetBEUI 3.0 is not truly NetBEUI. Instead, it is a NetBIOS Frame (NBF) format protocol. NetBEUI uses the NetBIOS interface as its upper-level interface, but NBF conforms to the Transport Driver Interface (TDI) instead. (For more information on TDI, see "Understanding the TDI Layer," later in this chapter.) NBF is completely compatible and interoperable with the NetBEUI shipped with past Microsoft networking products, however, and is referred to as NetBEUI on Windows NT screens.

For an example of how to take advantage of NetBEUI's speed within a LAN segment but not be restricted by its routing and wide area network (WAN) limitations, see "Strategies for Using NetBEUI," next in this chapter.

The following table summarizes the advantages and disadvantages of NetBEUI.

Advantages		Disadvantages
Tuned for small LAN communication, and therefore is very fast Good error protection Small memory usage		Not routable Performance across WANs is poor
Strategies for Using NetBEUI

Because NetBEUI is very fast for small LAN communications but provides poorer performance for WAN communications, one recommended method for setting up a network is to use both NetBEUI and another protocol, such as TCP/IP, on each computer that may need to access computers across a router or on a WAN.

When you install both protocols on each computer and set NetBEUI as the first protocol to be used, Windows NT uses NetBEUI for the communication between Windows NT computers within each LAN segment and TCP/IP for communication across routers and to other parts of your WAN.


How Data Link Control Works
Choosing Network Drivers and Protocols	10 of 12

Choosing a Protocol

How Data Link Control Works

Unlike NetBEUI and TCP/IP, the Data Link Control protocol is not designed to be a primary protocol for use between PCs. Instead, you will use Data Link Control with Windows NT only for the following two reasons:

If you need Windows NT computers to access IBM® mainframe computers

If you are setting up a printer that attaches directly to network cable, instead of to a serial or parallel port on a print server

To use Data Link Control to enable Windows NT computers to communicate with mainframe computers, you simply add Data Link Control as an additional protocol on whatever computers will actually communicate with the mainframes. You don't need to install Data Link Control on all network computers.

To use Data Link Control with a network-attached printer, such as the Hewlett-Packard LaserJet IIIsi, you need to install Data Link Control only on the Windows NT Server computer that will act as the printer's print server. It is not necessary to install Data Link Control on computers that will send documents to the network-attached printer. For more information, see Chapter 6, "Sharing Printers."

Unlike the other Windows NT protocols NetBEUI and TCP/IP, the Data Link Control protocol does not function at the Network or Transport Layers of the OSI Reference Model. Instead, Data Link Control provides higher-level programs with a direct interface to the Data Link Layer.

The following table summarizes the advantages and disadvantages of using Data Link Control.

Advantages		Disadvantages
Enables Windows NT computers to run software that accesses mainframes Enables Windows NT computers to act as print servers for network-attached printers		Generally not used as a primary protocol for PC-to-PC communication


Understanding the TDI Layer
Choosing Network Drivers and Protocols	11 of 12

Understanding the TDI Layer

For communication between the Session and Transport Layers of the OSI Reference Model, Microsoft has developed and supports the Transport Driver Interface (TDI). On a Windows NT computer, the server and redirector processes communicate with transport protocols by using the TDI interface.

Like NDIS, TDI makes Windows NT networking more versatile by making it possible for different transport protocols and upper-level networking components (such as the server and redirector) to communicate using a common interface. Different protocols that conform to TDI can work with different upper-level components that also support TDI. When a redirector or server makes a call to a transport, it uses the TDI interface for the call and thus does not have to know anything about the transport protocols being used.

Windows NT support of TDI means that alternate protocols or even alternate redirectors or servers written by third parties to conform to TDI will work with Windows NT.

The use of TDI enables Windows NT to overcome limitations of past LAN Manager 2.x products. For example, TDI imposes no limit on the number of workstations that can connect to a server, while the LAN Manager 2.x was limited to 254 workstation connections for each of the server's network adapter cards.

Although TDI is now the interface for communication between transport protocols and upper-level software such as the redirector and server, NetBIOS is also supported. NetBIOS is provided as an additional driver and DLL, and enables Windows NT to be compatible with NetBIOS applications and to run software that specifically requires NetBIOS. The NetBIOS software is used only for these situations.

Similarly, a Windows Sockets library is also available for applications that require it. Windows Sockets is a Windows NT version of the Sockets interface originally developed for UNIX computers.


Configuring RPC
Choosing Network Drivers and Protocols	12 of 12

Configuring RPC

Windows NT supports the use of remote procedure call (RPC) distributed applications. Microsoft RPC consists of run-time libraries and services that enable a distributed application to run on Windows NT. A distributed application consists of multiple processes that cooperate to accomplish a task. These processes may run on one or more computers.

Microsoft RPC uses a name service provider to locate and register servers on the network. Microsoft RPC name service providers must adhere to the Microsoft RPC Name Service Interface (NSI). The NSI consists of API functions that allow you to access and manipulate entries in the name service database. A name service database is a database that consists of server entries, group entries, and profile entries. Microsoft RPC version 1.0 interoperates with two name service providers: the Microsoft Locator and the Distributed Computing Environment (DCE) Cell Directory Service (CDS).

When Windows NT is installed, the Microsoft Locator is automatically selected as the name service provider. The Microsoft Locator is the name service provider optimized for a Windows NT network. When a server registers its distributed application using a name service provider, other computers that want to operate with it must use the same name service provider. For example, when a Windows NT computer registers a distributed application using the Microsoft Locator, all other computers that want to use a name service provider to access the information about the distributed application must also use the Microsoft Locator. When a Windows NT client wants to operate with a DCE server, they both must use the DCE CDS name service provider.

For information about changing name service providers, see the Windows NT Server System Guide.


How Network Security Works
Chapter 3	1 of 41

How Network Security Works

Windows NT Server supports a variety of security methods. These methods provide you with many ways to control the actions of users, while still letting them access the resources they need. The central basis of Windows NT security is that all resources and actions are protected by discretionary access control, meaning you can allow some users to access a resource or perform an action while preventing other users from doing so. Security is very granular, as well - for example, you can set different permissions on different files in the same directory.

With Windows NT Server, security is built into the operating system from the beginning, rather than being an add-on component. This means you can keep files and other resources secure even from users working at the computer where the resource is located, as well as users accessing the resource over the network. With Windows NT Server, security is even provided on basic system functions, such as setting a computer's system clock.

Windows NT Server also provides a logical administrative model, so that you can efficiently manage a large network. Each user needs only a single centrally stored account. This single account can provide the user access to resources anywhere on your network. This way, Windows NT Server makes both account management easier for administrators and network use easier for users.


Understanding Domains and Trust Relationships
How Network Security Works	2 of 41

Understanding Domains and Trust Relationships

The basic unit of security and centralized administration in Windows NT Server is the domain. A domain is a group of servers running Windows NT Server that, in some ways, function as a single system. All the Windows NT Servers in a domain use the same set of user accounts, so you need to type the information for a user account only once for all the servers in the domain to recognize that account.

Trust relationships are links between domains, enabling pass-through authentication, in which a user has only one user account in one domain yet can access the entire network. If you plan domains and trust relationships well on your network, all your Windows NT computers will recognize every user account, and a user will need to log in and provide a password only once to access any server on the network.


Domains:The Basic Administrative Units
How Network Security Works	3 of 41

Understanding Domains and Trust Relationships

Domains: The Basic Administrative Units

Grouping computers into domains provides two main benefits to network administrators and users. Most importantly, the servers in a domain form a single administrative unit, sharing security and user account information. Each domain has one database containing user and group accounts and security policy settings. All servers in the domain functioning as the primary domain controller or as a backup domain controller keep a copy of this database. This means that administrators need to manage only one account for each user, and each user has to use (and remember the password of) only one account. By extending the administrative unit from a single computer to an entire domain, Windows NT Server saves administrators and users time and effort.

The second benefit of domains is for user convenience: When users browse the network for available resources, they see the network grouped into domains, rather than seeing all the servers and printers on the whole network at once. This benefit of domains is identical to the Microsoft Windows for Workgroups concept of a workgroup, and Windows NT Server domains are compatible with workgroups in Windows for Workgroups. For more information about Windows for Workgroups, see "Interactions with Windows for Workgroups Computers," later in this chapter.

Note

Do not confuse Windows NT Server domains with TCP/IP network protocol domains. A TCP/IP domain describes part of the TCP/IP Internet and is not related to Windows NT Server domains.


Trust Relationships:Links Between Domains
How Network Security Works	4 of 41

Understanding Domains and Trust Relationships

Trust Relationships: Links Between Domains

By establishing trust relationships between the domains on your network, you enable user accounts and global groups to be used in domains other than the domain where these accounts are located. (For more information about global groups, see "Why Groups Are Useful," later in this chapter.) This makes administration much easier, because you need to create each user account only once on your entire network, and it can be given access to any computer on your network - not just the computers in one domain.

When you establish a trust relationship between domains, one domain (the trusting domain) trusts the other (the trusted domain).

Thereafter, the trusting domain recognizes all users and global group accounts from the trusted domain. These accounts can be used any way in the trusting domain; they can log on at workstations in the trusting domain, be placed in local groups in the trusting domain, and can be given permissions and rights in the trusting domain.

A trust relationship can be one-way or two-way. A two-way trust relationship is simply a pair of one-way relationships, where each domain trusts the other. In the following illustration, the Finance and Shipping domains trust each other, and accounts in each domain can be used in the other domain. But because Production trusts Sales and Sales does not trust Production, accounts from Sales can be used in the Production domain, but accounts from Production cannot be used in Sales.

Trust between domains is not transitive. For example, if Sales trusts Production, and Production trusts Finance, Sales does not automatically trust Finance. If you want Sales to trust Finance (and thus be able to use Finance accounts in the Sales domain), you must set up an additional trust relationship directly between those domains.


What Makes Up a Domain?
How Network Security Works	5 of 41

Understanding Domains and Trust Relationships

What Makes Up a Domain?

The minimum requirement for a domain is one server running Windows NT Server, which serves as the primary domain controller, and stores the master copy of the domain's user and group database. Optionally, a domain can also include other servers running Windows NT Server serving as backup domain controllers, Windows NT Server computers serving as standard servers, LAN Manager 2.x servers, Windows NT Workstation clients, and other clients such as those running Windows for Workgroups and MS-DOS. The following sections discuss each of these domain components in more detail.

Primary Domain Controller

The primary domain controller of a Windows NT Server domain must be a server running Windows NT Server. All changes to a domain's user and group database must be performed on the database stored on the primary domain controller. However, you do not have to worry about remembering the computer name of the primary domain controller of each domain. When you use User Manager for Domains to change the user database, you select only the name of the domain where you want to make the changes, and the change is automatically made to the primary domain controller. User Manager for Domains prevents you from changing the user database directly on domain servers other than the primary domain controller.

Backup Domain Controllers

Backup domain controllers running Windows NT Server also store copies of the domain's account database. The domain's account database is replicated to all the backup domain controllers in the domain.

All backup domain controllers, in addition to the primary domain controller, can process logon requests from the domain's user accounts. When the domain receives a request to log on, either the primary domain controller or any of the backup domain controllers may authenticate the logon attempt.

It is a good idea to have one or more backup domain controllers in a domain, in addition to the primary domain controller. These additional servers provide a backup mechanism; if the primary domain controller becomes unavailable, a backup domain controller can be promoted to primary domain controller, and the domain will continue to function. Having multiple domain controllers also spreads the load of logon request processing; this is especially useful in domains with large numbers of user accounts.

If you have multiple servers running Windows NT Server in a domain, one will be the primary domain controller. You should configure at least one other server as a backup domain controller. If the domain has servers at different physical sites connected by a WAN link, each site should have at least one backup domain controller.

Servers

In addition to the primary and backup domain controllers, there is another kind of server running Windows NT Server. These are servers which are designated as "servers" rather than domain controllers during Windows NT setup. These servers can participate in a domain, although they don't have to.

A server that participates in a domain does not actually get a copy of the domain's user database. But the server still gets the benefits of the domain's user and group database. When you assign user rights and object permissions, or create local groups, you have available user accounts from the domain the server participates in, as well as all domains trusted by the domain the server participates in. These user accounts can access the server and use its resources, if you permit them to.

A server that does not participate in a domain has only its own database of users and processes logon requests by itself. It does not share account information with any other computer, and cannot use accounts from any domain. On a server running this way, only user accounts created at the server itself can be logged on to or given rights and permissions at the server. These servers have the same types of user and group accounts as Windows NT Workstation computers, rather than the types of accounts of Windows NT Server domains.

You may want to configure a computer as a server instead of a backup domain controller in the following situations:

If the server performs extremely time-critical tasks and you don't want it to spend time authorizing domain logon attempts or receiving a replicated copy of a domain's user database.

If you want the server to have different administrator or user accounts from the rest of the servers in a domain. For example, you may have a person dedicated to administering a SQL server database. If you make the SQL server a standard server, then you can make that person an administrator on the SQL server. This way, he or she can manage that server but not have any control over the domain's master user database or its other servers.

If the server may be moved to a different domain in the future. It is simpler to move a server from one domain to another than to move a backup domain controller from one domain to another.

LAN Manager 2.x Servers

LAN Manager 2.x servers can function in a domain that has a primary domain controller running Windows NT Server. LAN Manager 2.x servers cannot be primary domain controllers of a Windows NT Server domain, however, because LAN Manager 2.x does not support all the types of information contained in Windows NT Server accounts.

LAN Manager 2.x servers store a copy of the domain's security database. They can validate logon attempts by computers running Windows for Workgroups or LAN Manager 2.x workstation software but cannot validate logon attempts by Windows NT users. It is not recommended that you rely solely on LAN Manager 2.x servers as your only backups in a Windows NT Server domain, because they cannot authenticate logon requests from Windows NT Workstation computers, and they cannot be promoted to primary domain controller of a Windows NT Server domain.

For more information about using LAN Manager 2.x servers on your network, see "Interactions with Servers Running Other Network Systems," later in this chapter.

Windows NT Workstation Computers

For each Windows NT Workstation computer on your network, you can choose whether to have the workstation participate in a domain or participate in a workgroup. In most cases, you will want each workstation to participate in a domain - this is the only way for a user who has an account on a Windows NT Server domain to be able to log on to that account at a Windows NT Workstation computer.

A Windows NT Workstation computer that participates in a domain does not actually get a copy of the domain's user database. But the workstation still gets the benefits of the domain's user and group database. For more information, see "Interactions with Windows NT Workstation Computers," later in this chapter.

A Windows NT Workstation computer participating in a workgroup has its own database of users and processes logon requests by itself. No computers in a workgroup share account information. On this type of workstation, only user accounts created at the workstation itself can be logged on to or given rights and permissions at the workstation.

For more information on domains and workgroups, see "Interactions with Windows for Workgroups Computers," later in this chapter.

MS-DOS Workstations

MS-DOS computers cannot store user accounts, so there is no need for them to participate in domains the same way in which Windows NT computers can. Each MS-DOS computer usually has a default domain set for browsing. If an MS-DOS computer user has a domain account, you can set the browsing domain on the user's computer to be any domain; it doesn't have to be the domain containing the user's account.


Knowing the Domain Models
How Network Security Works	6 of 41

Understanding Domains and Trust Relationships

Knowing the Domain Models

How you plan and organize the domains on your network is critical. You can simplify network administration a great deal and ensure that all users can access the entire network if you set up your domains so that all user accounts and global groups are valid in all domains.

There are four models for the organization of your network to ensure this: the single domain model, the master domain model, the multiple master domain model, and the complete trust model. These four methods are outlined in the following sections. You may choose to follow one of these models exactly, to modify one, or to mix and match them among parts of your network.

The figures in the following sections refer to global groups and local groups; for more information, see "Why Groups Are Useful," later in this chapter.

Single Domain Model

If your network doesn't have too many users and doesn't need to be split for organizational reasons, you can use the simplest domain model, the single domain model. In this model, the network has only one domain. Naturally, you create all users and global groups in this domain. No trust relationships are needed, because there is only one domain on the network.

A network can use the single domain model if it has a small enough number of users and groups to ensure good performance. The exact number of users and groups depends on the number of servers in the domain and the hardware of the servers.

If your network has many servers sharing resources, or your organization has many departments, the single domain model may not be the best. With multiple domains, a user browsing the network first browses among domains, then chooses a domain and views the resources contained there. If your network has many shared resources, splitting it into domains may make browsing easier. Performance is degraded when users browse a single domain with many servers.

Having only a single domain also means that your network administrators can always administer all network servers, because the ability to administer servers comes at the domain level. Splitting a network into domains enables you to create administrators who can administer only some servers, such as those in their own department.

The following table summarizes the advantages and disadvantages of using a single domain model.

Advantages		Disadvantages
Best model for companies with few users and resources Centralized management of user accounts No management of trust relationships necessary Local groups need to be defined only once		Poor performance if the domain has too many users and groups No grouping of users into departments No grouping of resources Browsing is slow if domain has a large number of servers
Master Domain Model

For companies where the network does need to be split into domains for organizational purposes, but the network has a small enough number of users and groups, the master domain model may be the best choice. This model gives you both centralized administration and the organizational benefits of multiple domains.

With this model, there is one domain - the master domain - where you create all the users and global groups on the network. All other domains on the network trust this domain and thus can use the users and global groups defined there. If your company has an MIS department that manages your LAN, it is logical to have the MIS department administer the master domain.

You can think of the master domain as an account domain; its main purpose is to manage the network's user accounts. The other domains on the network are resource domains; they don't store or manage user accounts but do provide resources (such as shared files and printers) to the network.

With this model, only the primary and backup domain controllers in the master domain actually have copies of the network's user accounts. You should be sure to have at least one backup domain controller in the master domain, so that if the primary domain controller fails, the backup domain controller can take over, and the network can keep running.

The following table summarizes the advantages and disadvantages of using a master domain model.

Advantages		Disadvantages
Best choice for companies that don't have too many users and must have shared resources split into groups User accounts can be centrally managed Resources are grouped logically Department domains can have their own administrators, who manage the resources in the department Global groups need to be defined only once (in the master domain)		Poor performance if the domain has too many users and groups Local groups must be defined in each domain where they are to be used
A variation of this model could be used in companies with a few distinct divisions, each of which has its own MIS group. In this case, each division would have its own master domain containing the users that work in that division. Each departmental domain would probably trust only one master domain: the master domain for the division containing the department. However, if a departmental domain needs to, it can trust more than one master domain. The master domains would probably not have to trust each other.

Multiple Master Domain Model

For larger companies that want centralized administration, the multiple master domain model may prove to be the best choice, because it is the most scalable.

With this model, there is a small number of master domains. The master domains serve as account domains, and every network user account is created on one of these master domains. The company's MIS groups can manage the master domains. Beyond the master domains, there are many other domains - departmental domains, which provide resources. The departmental domains can be managed by people in those departments or by MIS.

Each master domain trusts all the other master domains. Every departmental domain trusts all the master domains, but the departmental domains do not need to trust each other.

Because every user account in the company exists in one of the master domains, and all domains in the company trust every master domain, every user account in the company will be usable in all domains.

Note that the use of global groups is a bit more difficult in this model. If a global group needs to contain users from two or more of your master domains, you'll actually have to create multiple global groups - one in each of the master domains - and use all these global groups in the situations where you would use only one global group in the other domain models.

To minimize the global group problem, you should distribute the users among your master domains by organization within your company, rather than alphabetically or by some other method. This way, the chance that you will need similar global groups from different master domains is reduced. (For an explanation of global groups, see "How Global Groups and Local Groups Differ," later in this chapter.)

The master domains may all be managed by your company's central MIS department.

The following table summarizes the advantages and disadvantages of using a multiple master domain model.

Advantages		Disadvantages
Best choice for companies with many users and a centralized MIS department Scalable to networks with any number of users Resources are grouped logically Department domains can have their own administrators, who manage the resources in the department		Both local and global groups may have to be defined multiple times More trust relationships to manage Not all user accounts located in one domain
Complete Trust Model

If you want the management of users and domains to be distributed among different departments, rather than centralized, you may want to use the complete trust model. With the complete trust model, every domain on the network trusts every other domain. This way, each department can manage its own domain and define its own users and global groups, and these users and global groups can still be used on all domains in the network.

Because of the number of trust relationships required for this model, it may not be practical for large companies. With the complete trust model, the number of trust relationships required for a company with n domains is n*(n-1). For example, 10 domains require 90 trust relationships, and 20 domains require 380 trust relationships. Adding a new domain to an existing network of 10 domains requires establishing 20 new trust relationships.

Despite these numbers, this model may be the best for companies that don't have centralized MIS departments, or for departments within companies that haven't settled on Windows NT Server as a corporate standard.

With this model, the term "trust" truly applies. Before you create a trust relationship with another domain, be sure that you trust the administrator of that domain, especially if you will be giving permissions to global groups from that domain. Once you give a permission to a global group from another domain (or place that global group in a local group in your domain), you are trusting the administrator of the other domain not to add any unauthorized or inappropriate users to that global group in the future. The following table summarizes the advantages and disadvantages of using a complete trust model.

Advantages		Disadvantages
Best for companies with no central MIS group Scalable to networks with any number of users Each department has full control over its user accounts and resources Both resources and user accounts are grouped into departmental units		Because there is no central management of users, this model is not practical for companies with central MIS departments Very large number of trust relationships to manage Each department must trust that other departments don't put inappropriate users into global groups


How Domains Are Identified Internally
How Network Security Works	7 of 41

Understanding Domains and Trust Relationships

How Domains Are Identified Internally

Administrators and users identify domains by domain names. But internally, Windows NT identifies each domain by its security identifier (SID), a unique number assigned to the domain.

You should be aware of what effects this has. For example, suppose you have a domain named Sales_Domain, with a primary domain controller named SALES1 and no other Windows NT Server computers. If SALES1 is not active for some reason and you install Windows NT Server on another computer, and configure the new computer (call it SALES2) to be the primary domain controller for Sales_Domain, Windows NT Server will generate a new SID for Sales_Domain. This will not match the SID for Sales_Domain on SALES1. If SALES1 is restarted when SALES2 is active, the Netlogon service will fail to start on SALES1, because Windows NT will detect two different domain SID numbers, each with the same domain name. To get both servers to work properly as two members of Sales_Domain, you will need to reinstall Windows NT Server on one of them, while the other is running, and configure the server you are reinstalling as a backup domain controller.

Because of this, if you have an existing domain and you want to install a new computer as a backup domain controller, you must be sure the new server can access the current primary domain controller, so that it can receive the correct domain SID during installation. You cannot install Windows NT Server on the new server while it is on a separate network, and then add it to the current network. (However, if you have an existing backup domain controller in a different domain, you can move it from that domain to another.)


How Logon Attempts Are Authenticated
How Network Security Works	8 of 41

How Logon Attempts Are Authenticated

This section explains how logon attempts from Windows NT Workstation computers, Windows 3.1 clients, and MS-DOS clients are authenticated.


Logging On from a Windows NT Workstation Computer
How Network Security Works	9 of 41

How Logon Attempts Are Authenticated

Logging On from a Windows NT Workstation Computer

Whenever a user logs on at a Windows NT Workstation computer, the logon screen prompts him or her for a user name, password, and domain:

The user name and password are straightforward. What the user selects in the From box depends on where the user's account is located. If the account is on a Windows NT Server domain, the user selects that domain. The workstation then sends the user name and password to the specified domain for authentication. A server in that domain checks the user name and password against that domain's database of users. If the user name and password match an account, the server notifies the workstation that the logon is to be approved. The server also downloads logon information about the user, such as the user's profile, home directory, and environment variables. For more information, see Chapter 4, "Managing User Environments."

If the user is logging on to an account stored locally at the workstation, the user selects the workstation name in the From box, rather than the name of a domain. Then the workstation checks its own user database for the user name and password specified by the user. If there is a match, the logon is approved, and the user's logon information is obtained from the account on the workstation.


Logging On at a Windows NT Server Computer
How Network Security Works	10 of 41

How Logon Attempts Are Authenticated

Logging On at a Windows NT Server Computer

The process of logging on at a Windows NT Server computer is identical to the process for logging on at a Windows NT Workstation computer, except that servers do not maintain local accounts separate from the accounts in the domain containing the server. So the user must log on to a domain account.

Note that, by default, not everyone with accounts in a domain is allowed to log on locally at the domain's servers. Only members of the Administrators, Server Operators, Print Operators, Account Operators, and Backup Operators are allowed to do so. For more information, see "What Different Types of Users Can Do," and "How You Can Control What Users Can Do," later in this chapter.


Logging On from an MSDOS Computer
How Network Security Works	11 of 41

How Logon Attempts Are Authenticated

Logging On from an MS-DOS Computer

MS-DOS computers are not secure - there is no way to prevent an unauthorized user from sending network requests from an MS-DOS computer. You can prevent an unauthorized MS-DOS user from accessing network resources by securing the resources themselves, so that the user's network requests will fail if he or she is unauthorized.

If a user with an account in a Windows NT Server domain has an MS-DOS computer, the user will not be checked at logon (even though he or she provides a user name and password to log on). However, the user name and password will be checked whenever the user first accesses a server running Windows NT Server. The server will check that the user name and password match an account in the server's domain (or in a domain trusted by the server's domain). This way, users of MS-DOS computers can still have domain accounts and be subject to account authorization.


Understanding Users and Groups
How Network Security Works	12 of 41

Understanding Users and Groups

Each person who will regularly use the network must have a user account on some domain in the network. The user account contains information about the user, including name, password, and restrictions on how he or she can use the network. You can also group users who have similar jobs or resource needs into both global groups and local groups; groups make granting rights and resource permissions easier, as you just need to take the one action of giving a right or permission to a group to give that right or permission to all the present and future members of that group.

User accounts are also subdivided into two types: global user accounts and local user accounts. Most or all user accounts you create will be global user accounts. For information about local user accounts, see "Understanding Local Accounts," later in this chapter.

User and group accounts are created and managed by User Manager. You use File Manager to give permissions for files and directories to users and groups, and you use Print Manager to give them access to printers. For more information on these topics, see Chapter 5, "Managing Network Files," and Chapter 6, "Sharing Printers."


Contents of a User Account
How Network Security Works	13 of 41

Understanding Users and Groups

Contents of a User Account

The following table shows the contents of each user account.

Account element	Comment

Username	The unique name the user types when logging on; often a combination of parts of the user's first and last names.

Password	The user's secret password.

Full name	The user's full name.

Logon hours	The hours during which the user is allowed to log on. This affects both being able to log on to the network and being able to access servers. Whether users are forced to log off when their logon hours expire is determined by a setting in the domain's security policy; for more information, see "Setting Password and Account Policy," later in this chapter.

Logon workstations	The computer names of the workstations that the user is allowed to work from. By default, the user can use any workstation, but you can limit this if you want.

Expiration date	A future date when the account automatically becomes disabled; it is useful to ensure that accounts for temporary employees or students are not unnecessarily kept active.

Home directory	A directory on the server that is private to the user; the user controls access to this directory.

Logon script 	A batch file or executable file that runs automatically when the user logs on.

Profile 	A file containing a record of the user's Desktop environment, such as program groups, network connections, and screen colors, and settings determining what aspects of the environment the user can change. For more information on user profiles, see Chapter 4, "Managing User Environments."

Account type	The account type is either global or local. Most accounts you create will be global accounts. For information on local accounts, see "Understanding Local Accounts," later in this chapter. This option is available only on Windows NT Server domains.

In addition, there are several conditions that are either true or untrue for each user account, as shown in the following table.

Account condition		Default	Comments
Change Password at Next Logon?		Yes	If yes, the user will be forced to change the password the next time he or she logs on. Then this value is set to No.
User Cannot Change Password		No	If yes, the user cannot change his or her own password. This is useful for shared accounts.
Password Never Expires		No	If yes, this user account ignores the password expiration policy set for the domain, and the password never expires. This is used for accounts that represent services, such as the Replicator service. It is also useful for accounts for which you want the password to never change, such as guest accounts.
Account Disabled		No	If yes, this account is disabled and cannot be logged on to. It is not removed from the database, but no one can log on to the account until you again enable it. This is useful for template accounts.
A user account also includes a security identifier (SID), a unique number that identifies the account. Every account ever created on your network will have a unique SID. Internal processes in Windows NT refer to an account's SID rather than the account's user name. So, if you create an account, delete it, then create an account with the same user name, the new account will not have any rights or permissions previously granted to the old account, because the accounts have different SID numbers.

On some Windows NT Server screens, such as in User Manager for Domains and File Manager, user names are sometimes preceded by the domain where the user account is located. This happens only when you view accounts located in domains other than the domain on which you are currently focused. This gives you more information about users you see and also serves to precisely identify users. For example, you may see the user JohnL from the Sales domain as Sales\JohnL - there could be different users named JohnL in two domains, but since Windows NT Server presents them as Sales\JohnL and Engineering\JohnL, you are not confused.

Note

User accounts can contain a lot of information. Typing that information for each user can take a lot of time on a large network, but with Windows NT Server there are ways you can make creating user accounts easier. You can create a new account by copying an existing account and just changing the user's name and initial password, and any other information that must be changed. With this feature, you could also create one or more template accounts, accounts that aren't used by real users but only serve as bases for real accounts you do create. For greater security, you can disable your template accounts to ensure that no user can log on using them.


Why Groups Are Useful
How Network Security Works	14 of 41

Understanding Users and Groups

Why Groups Are Useful

Putting users into groups makes it easier and faster to grant multiple users access to a resource. To give a permission or right to all the users in a group, you just give that permission or right to the group itself. Another advantage of groups is clear when new users join the network. For example, if a new accountant is hired, and you have a group Accountants that has permissions to all the network resources needed by accountants, just by adding the new user to Accountants you give that new user all the permissions he or she needs, in one step.

On a Windows NT Server domain or a Windows NT computer, local groups are also the means by which you can classify users and quickly give them predefined sets of rights and permissions; for example, to make an account a print operator in a domain, you add the account to the Print Operators local group in the domain. The account then has all rights and abilities of a print operator.

How Global Groups Work

A global group is a number of user accounts from one domain that are grouped together under one group name. A global group can contain only user accounts from a single domain - the domain where the global group is created. Once a global group is created, it is globally available. It can be granted permissions and rights in its own domain as well as any domain that trusts that domain. A global group can contain only user accounts; it cannot contain other global groups or local groups.

In several screens in Windows NT Server, you may see a global group name preceded by the domain name of the domain where the global group is located. For example, when you view file permissions on a server in the Sales domain, if the Managers global group in the Marketing domain has permissions, they are shown as Marketing\Managers. This way, you have absolute identification of a global group when it is referred to in any domain other than its own. (A global group viewed in its own domain has no domain name prefix; for example, when you view file permissions on a server in the Sales domain, global groups located in Sales itself are shown by their group name only.)

How Local Groups Work

A local group is a number of users and global groups from one or more domains that have been grouped together under one group name. Although a local group in a domain can contain users and global groups from that domain and any domain trusted by that domain, you can grant rights and permissions to a local group only for resources located in the domain where the local group is defined. The use of that group is local to the servers in that domain. A local group can contain users and global groups but cannot contain other local groups.

Local groups also exist on Windows NT Workstation computers and on servers that are not domain controllers. A local group on one of these computers can contain user accounts from the computer itself, and users and global groups from the computer's domain and the domains trusted by that domain.


How Global Groups and Local Groups Differ
How Network Security Works	15 of 41

Understanding Users and Groups

How Global Groups and Local Groups Differ

Although global and local groups serve similar functions, different rules apply to their creation and use.

A global group created in the Sales domain:

Can contain only users from the Sales domain.

Can be used in any domain that trusts the Sales domain.

A local group created in the Sales domain:

Can contain users and global groups from the Sales domain and any domain that the Sales domain trusts.

Can be used only on servers in the Sales domain.

Note that a domain's local groups cannot even be used on servers that are not domain controllers or on Windows NT Workstation computers participating in that domain - the domain's local groups are local to the primary domain controller and backup domain controllers in the domain.

The names global group and local group denote where the group can be given rights and permissions (the group's scope), not the contents of the group.

Local groups can contain global groups, but global groups cannot contain either local groups or other global groups.

In addition, the account database of a Windows NT Workstation computer can have only local groups - global groups do not exist on Windows NT Workstation computers. A Windows NT Workstation computer's local groups can be given rights and permissions only on that workstation - even if the workstation is part of a domain, the workstation's local groups are not usable on any other computer.


Strategies for Using Global Groups and Local Groups
How Network Security Works	16 of 41

Understanding Users and Groups

Strategies for Using Global Groups and Local Groups

To make your network simpler to administer and easy to maintain, you should be aware of some strategies for using global groups and local groups.

If your domains are divided so that each represents a division or department of your company, you can think of a global group as being a group of users, all from the same department. (Remember that, in File Manager and User Manager for Domains, when you view global groups from domains other than the domain on which you are focused, you see the global group name preceded by the name of the domain where the group and its members are located, such as Sales\Managers.)

This group of users can be assigned permissions and rights in other domains, so the global group is a means of exporting this group of users, as a single unit, to other domains (and to other Windows NT computers) in the company. When an administrator sees the group name preceded by the domain name, the administrator knows both the type of people that group represents (by the group name) and the origin or location of that group (by the domain name).

A local group is a group that can include users and global groups from other domains, so it is a way to import users and global groups from other domains into a single unit for use in the local domain.

As an example of this use, suppose that the domain Engineering has a server with a shared directory containing documents that explain new technologies the company is investigating. Managers in other departments (domains) in the company are interested in seeing these documents. Network administrators can provide for this by doing the following:

1.	Creating global groups in the other domains (such as Marketing\Managers and Sales\Managers).

2.	In the Engineering domain, creating a local group called All Managers.

3.	Putting the Marketing\Managers and Sales\Managers global groups in the All Managers local group.

4.	Granting All Managers permission to read the files in the directory.

In the example above, it is true that you could just give each of the Managers global groups from the other domains permission to read the files, and bypass the step of creating the local group. However, in many cases, creating the local group will save time later. For example, suppose that later on you add two new directories containing files interesting to managers. If you have not created the All Managers local group, you need to grant access for the new directories to all the Managers global groups, instead of just the single local group. This would be a large savings if the All Managers local group contains many global groups, rather than just the two in this example.

As this example shows, a local group is a way of assembling global groups and assigning them all permissions in one step. This way, if another global group later needs the same permissions as some existing global groups, you can just add the new global group to the appropriate local group, and it has all the permissions it needs.

Purpose of group		Use	Comments
Group users of this domain into a single unit for use in other domains		Global	The global group can be put into local groups, or given permissions and rights directly, in other domains.
Need permissions and rights only in one domain		Local	The local group can contain users and global groups from other domains.
Need permissions on Windows NT Workstation computers or on servers that are not domain controllers		Global	A domain's global groups can be given permissions on these computers, but a domain's local groups cannot.
Contain other groups		Local	The local group can contain only global groups (and users); however, no group can contain other local groups.
Include users from multiple domains		Local	The local group can be used in only the domain in which it is created. If you need to be able to grant this local group permissions in multiple domains, you will have to manually create the local group in every domain in which you need it.
Strategies for Using the Built-In Global and Local Groups

The general strategies discussed so far for using global groups and local groups also apply to the built-in global and local groups. The Administrators local group and Domain Admins global groups serve as an example.

Being a member of the Administrators local group is what actually makes an account an administrator on a Windows NT domain or computer. However, when you create an account on a domain, you have two ways of making that account an administrator: You can place it directly into the Administrators local group, or you can put it in the Domain Admins global group, which is in turn a member of Administrators.

It is strongly recommended that you always use the second method: Put the account in the Domain Admins global group. This way, you have a global group that represents all administrators in the domain. This global group can then be put in the Administrators local group of any other domain, or any Windows NT computer, that this domain's administrators will need to administer. (In fact, when you set up a Windows NT Workstation computer or a server that is not a domain controller to participate in a domain, that domain's Domain Admins global group is automatically added to the computer's Administrators local group. This enables the domain administrators to manage the computers in the domain.)

Every domain has a Domain Users global group, and all user accounts you create in the domain are placed in this group by default; you don't have to remember to add accounts to this group. The Domain Users global group is automatically a member of the Users local group in the same domain, and also is a member of the Users local group on all Windows NT workstations participating in the domain.

Every domain also has a Domain Guests global group, which is a member of the domain's Guests local group. The Domain Guests global group initially contains the Guest user account.

Domain Admins, Domain Users, and Domain Guests are the only built-in global groups that correspond to built-in local groups. You can create other global groups that correspond to local groups, if you want to use the same strategies for those types of users. For example, you may want to create a Domain BackupOps global group for the domain's backup operators. Then, if this domain's backup operators need to back up files on a Windows NT Workstation computer, or in another domain, the BackupOps global group can simply be added to the workstation's or domain's Backup Operators local group.


What Different Types of Users Can Do
How Network Security Works	17 of 41

Understanding Users and Groups

What Different Types of Users Can Do

Each user account is, most likely, a member of one or more built-in local groups. Being a member of one of the built-in local groups of a domain gives a user rights and abilities to perform various tasks on the domain controllers in the domain. Similarly, being a member of a built-in group on a server or workstation gives the user rights and abilities on that computer.

For each built-in local group, some of the abilities are inherent to the local group and cannot be changed by an administrator, while other powers (those granted to the local group via user rights) are changeable by the administrator. The tables in this section give an overview of the powers of all the built-in local groups, on both Windows NT Server domains and individual Windows NT computers. The sections following these tables provide more details about each local group.

You can add a user to more than one built-in group. In this case, the user has all the abilities granted to all the groups. For example, a user in both the Print Operators and Backup Operators groups has all the rights granted to print operators and all the rights granted to backup operators.

Note that not all of the built-in local groups exist on both Windows NT Server domains and individual Windows NT computers (Windows NT Workstation computers and servers that are not domain controllers). The following table shows which built-in local groups exist on domains and on individual computers.

Windows NT Server domains		Workstations and servers
Administrators		Administrators
Backup Operators		Backup Operators
Server Operators		Power Users
Account Operators		Users
Print Operators		Guests
Users		Replicator
Guests
Replicator
The following tables show which rights and built-in abilities are held by each built-in local group, on both Windows NT Server domains and on servers and workstations. Following that is a brief discussion of the purpose and abilities of each built-in local group.

Windows NT Server domains

Workstations and servers

Administrators

Accounts in a domain's or computer's Administrators local group have power to do almost anything on the domain or computer. This includes creating, deleting, and managing user accounts, global groups, and local groups, sharing directories and printers, granting resource permissions and rights to users, and installing operating system files and programs.

Note that unlike the security in LAN Manager 2.x, administrators do not automatically have access to every file on a server - if a file's permissions do not grant access to an administrator, the administrator cannot access the file. Every file on an NTFS volume has an owner, who can set permissions on the file. When a file is created, its creator becomes its owner. If needed, an administrator can take ownership of a file and thus have access to it. For more information about ownership of files and directories, see Chapter 5, "Managing Network Files."

By default, when a Windows NT Workstation computer or a Windows NT Server computer that is not a domain controller joins a domain, the domain's Domain Admins global group is added to the computer's Administrators local group, allowing the domain administrators to manage that computer. If you want to prevent domain administrators from administering the computer, you can simply remove the Domain Admins global group from the computer's Administrators local group.

Users

Accounts in the Users local group are typical users of the network: people using the network to get their jobs done. Most user accounts you create will be this type.

On the primary and backup domain controllers running Windows NT Server in a domain, users do not have the right to log on locally by default. Users can access these servers only over the network.

A member of the Users local group of a Windows NT Workstation computer:

Can log on at the workstation and use it to access the network.

Can lock and shut down the workstation.

Can keep a profile at the workstation. (For more information about profiles, see Chapter 4, "Managing User Environments.")

Can create and delete local groups on the workstation.

Can modify the membership of the local groups that he or she has created (but cannot modify built-in local groups or local groups created by anyone else).

Guests

On a domain controller running Windows NT Server, members of Guests have the same rights as members of Users; both groups have only the right to access the server over the network and cannot log on locally at the server.

Guests have fewer rights than Users while working at Windows NT Workstation computers; Users can keep a local profile on the workstation, lock the workstation, and create, delete, and modify local groups on the workstation, while Guests can do none of these things.

Server Operators

The Server Operators local group exists only on primary and backup domain controllers running Windows NT Server. The basic mission of server operators is to keep network servers running.

Accounts in the Server Operators local group have many of the same powers as administrators, except that they cannot manage security on the server. Specifically, server operators can share and stop sharing a server's files and printers, lock or override the lock of a server, and format the server's disks. They can also log on at servers, back up and restore servers' files, and shut down servers.

Account Operators

The Account Operators local group exists only on primary and backup domain controllers running Windows NT Server.

Accounts in the Account Operators local group on a server can manage the server's user and group accounts. An account operator can create, delete and modify almost all users, global groups, and local groups. The exceptions are that account operators cannot modify the user accounts of administrators, nor can they modify the Administrators, Server Operators, Account Operators, Print Operators, or Backup Operators local groups. They also cannot assign user rights.

Print Operators

The Print Operators local group exists only on primary and backup domain controllers running Windows NT Server.

Accounts in the Print Operators local group can share printers, stop sharing printers, and manage printers shared at servers running Windows NT Server. They can also log on locally at servers and shut them down.

If you want a domain's print operators to administer printers managed by servers in the domain, as well as printers managed by the domain controllers, perform the following steps:

1.	Create a Domain PrintOps global group in the domain. Make this global group a member of the domain's Print Operators local group.

2.	Add the user account of each print operator to the Domain PrintOps global group.

3.	On each server that manages printers, put the Domain PrintOps global group in the server's Power Users local group.

Backup Operators

Accounts in the Backup Operators local group on a Windows NT computer can back up and restore the computer's files.

Backup Operators can back up files, restore files, log on locally, and shut down the computer.

Power Users

The Power Users local group exists only on Windows NT Workstation computers and on servers that are not domain controllers.

A member of the Power Users local group can do everything that a member of Users can, plus he or she can also create user accounts; modify the user accounts he or she has created; put any user accounts on the computer into the Power Users, Users, and Guests built-in groups; and share and stop sharing files and printers located at the computer.

Because the Power Users group exists on Windows NT Workstation computers but not on domains, a common strategy for the use of the Power Users group is to put the domain account of each user into the Power Users group on his or her own workstation. For example, put the domain account PegEt in the Power Users group on her own workstation; on the servers in the domain, PegEt is automatically a member of the Users group. This way, PegEt has more control over her own workstation and can share its files with other users, but on the domain's servers, PegEt is a typical user.

In general, the account of every average user will automatically be in the Users group on the domain itself. On each user's workstation, you can decide whether to put the user's domain account in the Power Users group (for more workstation control) or Users group (for less control).

Note that because the Power Users group does not exist on Windows NT Server domain controllers, the concept of Power Users has no meaning for users who have MS-DOS computers.

Replicator

The last built-in group, Replicator, is used only in conjunction with the file replication service. If you are not going to use file replication, you will not need to administer the Replicator local group. For information on file replication, see Chapter 5, "Managing Network Files."


Built-In Accounts
How Network Security Works	18 of 41

Understanding Users and Groups

Built-In Accounts

When Windows NT is installed, several default user and group accounts are built into the computer's account database. The following sections explain each of these built-in accounts and how they will be useful to you.

Built-In User Accounts

Two default user accounts exist initially on every Windows NT computer:  Administrator and Guest.

Administrator is the account you can use when you first administer a new server or workstation, before you create an account for yourself. The Administrator account can never be deleted or disabled, ensuring that you will never lock yourself out of the computer by deleting or disabling all the administrative accounts.

Guest is an account used for guest logons, which are logons by people who do not have an account on the computer, in the computer's domain, or in any of the domains trusted by the computer's domain. The Guest account is disabled by default when Windows NT Server is installed, but you can enable it if you want to allow guest logons. For more information, see "Allowing Guest Access," later in this chapter.

Account	Can be deleted?	Can be disabled?	Can be renamed?
Administrator	No	No	Yes
Guest	No	Yes	Yes
Built-In Global Groups

On a domain's primary and backup domain controllers, three global groups are built in - Domain Admins, Domain Users, and Domain Guests. None of these groups can be deleted.

Domain Admins initially contains the Administrator account. When you create accounts for the administrators of your domain, you should add these accounts to the Domain Admins global group, rather than just putting them into the Administrators local group. For more information, see "Strategies for Using the Built-In Global and Local Groups," earlier in this chapter.

Domain Users initially contains the Administrator accounts. Every user account you subsequently add to this domain is automatically put in the Domain Users global group.

Domain Guests initially contains the Guest account.

Global group	Initial contents	Who can modify¹
Domain Admins	Administrator	Administrators
Domain Users	Administrator	Administrators, Account Operators
Domain Guests	Guest	Administrators, Account Operators
¹ None of the groups can be deleted.

Built-In Local Groups

When Windows NT is installed on any computer, several default local groups are created. Membership in these local groups gives a user certain powers; the powers of each local group are discussed in "What Different Types of Users Can Do," earlier in this chapter. None of these built-in local groups can be deleted.

In addition to these local groups, there is an identity called Everyone, which represents all people on the network, including administrators, all types of operators, users, users from other domains, and guests. You cannot change the membership of Everyone - it always automatically contains all users. Everyone is not actually a local group and does not appear in the User Manager list of groups, but you can assign file permissions to Everyone (in File Manager), and you can also assign rights to Everyone (in the Rights dialog box in User Manager for Domains).

The following table lists the built-in local groups on primary and backup domain controllers, and on workstations and servers.

Built-In Local Groups

Group	Initial contents		Who can modify?¹
Primary and backup domain controllers:
Administrators	Domain Admins (global group) Administrator (user account)		Administrators
Users	Domain Users (global group) Administrator (user account)		Administrators, Account Operators
Guests	Domain Guests (global group) Guest (user account)		Administrators, Account Operators
Server Operators	None		Administrators
Print Operators	None		Administrators
Backup Operators	None		Administrators
Account Operators	None		Administrators
Replicator	None		Administrators, Account Operators, Server Operators
Workstations and servers:
Administrators	Administrator (user account) ²		Administrators
Users	None		Administrators, Power Users
Power Users	Setup User ³		Administrators, Power Users
Guests	Guest (user account)		Administrators, Power Users
Backup Operators	None		Administrators
Replicator	None		Administrators
¹ None of the groups can be deleted.

² If the workstation is added to a domain, the domain's Domain Admins global group is automatically added to the workstation's Administrators local group.

³ The Setup User is the account with the user name specified during the installation of Windows NT by the person who installed Windows NT. This account exists only if the workstation was not added to a domain when Windows NT was installed on it.


How You Can Control What Users Can Do
How Network Security Works	19 of 41

How You Can Control What Users Can Do

You can control what users can and cannot do on their workstations and on the rest of the network in several ways. The most important method, and the one you will use most often, is by using the predefined local groups. Simply by adding a user to one of these groups, you give the user a large set of predefined rights and abilities. (For more information on what each predefined local group can do, see "What Different Types of Users Can Do," earlier in this chapter.)

Another way to restrict users' abilities is by making certain settings in their user accounts, such as limiting their logon hours and the network computers they are allowed to use.

Permissions on each file, directory, or printer shared on the network define who can and cannot access those resources. You can assign permissions to local groups, global groups, and directly to individual users, but it is recommended that you rarely, if ever, assign permissions to individual users, because this is hard to maintain.

You can monitor what users do by auditing actions and resources. Auditing an action or resource causes an entry to be written to the security event log whenever that action is performed or that resource is accessed, ensuring that users are accountable for the actions they take.

You can directly manipulate user rights (also called just rights), which specify what actions that local groups, global groups, and users can perform. However, it is recommended that you do this rarely, if ever. Instead, use the predefined local groups, and their predetermined sets of rights - these groups should serve most needs. If, however, you do want to grant rights to other groups or users, or to fine-tune which rights the predetermined groups have, you have the ability to do so.

Finally, you can also greatly affect a user's Windows NT desktop environment by assigning the user a profile. For more information on profiles, see Chapter 4, "Managing User Environments."


Permissions
How Network Security Works	20 of 41

How You Can Control What Users Can Do

Permissions

You can use File Manager to set permissions on files on NTFS partitions on Windows NT computers. These permissions then apply to both users working at that computer itself and to users accessing these files over the network (if they are shared). You can set file permissions to a fine degree of granularity - for example, you can set different permissions for each file in a directory, if you want. You can set many different types of permissions, as well - for example, you can let one user read the contents of a file and change it, let another user only read the file, and prevent all other users from any access to the file.

This type of access restriction is not available for files on file allocation table (FAT) or high-performance file system (HPFS) partitions on Windows NT computers. Files on these partitions are always readable and changeable by users working at the computer itself. However, you can protect shared directories on FAT or HPFS partitions by specifying one set of permissions that apply to users for all files and subdirectories of the shared directory. These are called share permissions.

For more information on file permissions and share permissions, see Chapter 5, "Managing Network Files."

Similar types of permissions can be set on shared printers managed by Windows NT Server computers. For more information, see Chapter 6, "Sharing Printers."

ClipBook Viewer Permissions

ClipBook Viewer enables you to share information among different applications and users, and dynamically link and embed that information into other files and documents on the same computer or on other Windows NT computers. For more information on ClipBook Viewer and object linking and embedding (OLE), see the Windows NT Server System Guide.

When a piece of information is transferred to ClipBook Viewer, it takes the format of a page. ClipBook Viewer can hold up to 127 pages, which can be shared with other users. The user who creates a page can set permissions on the page, which specify whether other users can use the page.

To create, share, stop sharing, and delete a ClipBook Viewer page, a user must be in one of the following groups on the computer:

Administrators

Server Operators

Power Users

Users

In addition, the special group Everyone can use ClipBook Viewer to see a list of pages shared on the computer.

When a user creates and shares a new ClipBook Viewer page, that user becomes the owner of the new page, and the following permissions are set by default on the page. The owner of the page can change these permissions if he or she wants.

Permissions for New ClipBook Viewer Page

User or group		Permissions
User name of creator/owner		Full Control
Everyone		Read and Link
The following list shows the types of permissions that can be set on ClipBook Viewer pages. You can grant different permissions to different users, thereby allowing some people access to the page while preventing access to others.

No Access

Read

Read and Link

Change

Full Control


Auditing
How Network Security Works	21 of 41

How You Can Control What Users Can Do

Auditing

You can specify that an audit entry is to be written to the security event log whenever certain actions are performed or files are accessed. The audit entry shows the action performed, the user who performed it, and the date and time of the action. You can audit both successful and failed attempts at actions, so the audit trail can show both who actually performed actions on the network and who tried to perform actions that are not permitted.

The following table lists the categories of events you can choose to audit and what events are covered by each category. For each of the categories listed below, you can choose whether to audit only successful actions in that category, failed attempts to perform actions in that category, both, or neither.

Category		Events
Logon and Logoff		Logon attempts, logoff attempts, and the creating and breaking of network connections to servers
File and Object Access		Accesses of a directory or a file that is set for auditing in File Manager; uses of a printer managed by the computer
Use Of User Rights		Successful uses of user rights, and failed attempts to use rights not assigned to users
User and Group Management		Creation, deletion, and modification of user and group accounts
Security Policy Changes		Granting of or revoking of user rights to users and groups, and the establishing and breaking of trust relationships with other domains
Restart, Shutdown, and System		Shutdowns and restarts of the computer, the filling up of the audit log, and the discarding of audit entries if the audit log is already full
Process Tracking		Starts and stops of processes on the computer
You specify what types of system events are audited through User Manager. You specify what files are audited and how (provided you have used User Manager to turn on the auditing of file accesses) through File Manager.

The following table shows the types of directory and file accesses you can audit.

Directory access		File access
Displaying names of files in the directory		Displaying the file's data
Displaying directory attributes		Displaying file attributes
Changing directory attributes		Displaying the file's owner and permissions
Creating subdirectories and files		Changing the file
Going to the directory's subdirectories		Changing file attributes
Displaying the directory's owner and permissions		Running the file
Deleting the directory		Deleting the file
Changing directory permissions		Changing the file's permissions
Changing directory ownership		Changing the file's ownership


User Rights
How Network Security Works	22 of 41

How You Can Control What Users Can Do

User Rights

User rights control who can perform many types of actions on Windows NT computers. The actions governed by rights include the ability to log on locally at the computer, shut it down, set its time, back up and restore the server's files, and perform other tasks.

On Windows NT Server domains, rights are granted and restricted on the domain level; if a group has a right in a domain, its members have that right on all primary and backup domain controllers in the domain. On each Windows NT Workstation computer, and on each Windows NT Server computer that is not a domain controller, rights granted apply only to that single computer.

				Granted to:
User rights		Comments		Domains		Workstations and servers
Manage auditing and security log		Specify what types of file and object access are to be audited. View and clear the security log.		Administrators		Administrators
Back up files and directories				Administrators, Server Operators, Backup Operators		Administrators, Backup Operators
Restore files and directories		Note that this right supersedes file permissions; a user with the Restore right can overwrite files for which he or she has no permissions, when performing a restore.		Administrators, Server Operators, Backup Operators		Administrators, Backup Operators
Change system time				Administrators, Server Operators		Administrators, Power Users
Access this computer from network		Access the computer from another workstation on the network.		Administrators, Everyone		Administrators, Power Users, Everyone
Log on locally		Ability to log on at the computer itself, on the computer's keyboard.		Administrators, Server Operators, Account Operators, Print Operators, Backup Operators		Administrators, Backup Operators, Power Users, Users, Guests
Shut down the system				Administrators, Server Operators, Account Operators, Print Operators, Backup Operators		Administrators, Backup Operators, Power Users, Users, Guests
Add workstations to domain		Allows a user who is not a member of the domain's Administrators group to add new Windows NT Workstation computers to the domain.		None1		N/A
Take ownership of files and other objects		Take ownership of files and directories on the computer.		Administrators		Administrators
Load and unload device drivers				Administrators		Administrators
Force shutdown from a remote system		This right gives a user no abilities in this version of Windows NT, but will be supported in future upgrades of the operating system.		Administrators, Server Operators		Administrators, Power Users
¹ Member of the domain's Administrators and Server Operators groups can always add workstations to a domain, whether or not they have this right assigned to them. This right is needed only to enable users who are not members of these groups to add workstations to the domain.

For tables showing the rights assigned to the built-in local groups, see "What Different Types of Users Can Do," earlier in this chapter.

You have the ability to grant or revoke rights to and from users and groups. Other abilities are not directly controllable by you - they are granted to some built-in local groups when Windows NT or Windows NT Server is installed. The only way for you to grant a user one of these built-in abilities is to make that user a member of the appropriate local group. For example, the only way to allow a person to create user accounts on a server is to make that person a member of either the Administrators or Account Operators local groups on the server.

Although you have the ability to grant and revoke rights to and from local groups, global groups, and individual users (using User Manager or User Manager for Domains), it is recommended that you do not do so, in most cases. Instead, to give a user the ability to perform actions, put the user into the appropriate predefined local group (such as Administrators, Print Operators, Power Users, and Users, for example). These groups represent carefully planned sets of rights that you should find useful. (One situation where you might want to modify how rights are set is explained in "Allowing Guest Access," later in this chapter.)

In addition to the user rights in the preceding table, there are also some advanced user rights, which you probably won't need to use so often. Many of these advanced rights are useful only to programmers writing applications to run on Windows NT and should not be granted to any local group or user. These rights are shown in the following list.

Act as part of the operating system

Create page file

Create token objects

Create permanent shared objects

Debug programs

Generate security audits

Increase quotas

Load and unload device drivers

Lock pages in memory

Modify firmware environment values

Profile system

Replace process level token

For more information on the use of these rights by programmers, see the Windows NT programming documentation. Other advanced rights are interesting to administrators. These rights are explained in the following table.

Advanced User Rights

Right	Definition		Initially granted to
Bypass traverse checking	Allows a user to change directories through a directory tree, even if the user has no permissions for those directories.		Everyone
Log on as a service	Allows a process to register with the system as a service. This right is useful when you set up the Replicator service. For more information, see Chapter 5, "Managing Network Files."		None


Setting Password and Account Policy
How Network Security Works	23 of 41

How You Can Control What Users Can Do

Setting Password and Account Policy

For each domain, you can specify all aspects of password policy: minimum password length (default is 6 characters), minimum and maximum password age (defaults are 14 and 30 days), and password uniqueness, which prevents a user from changing his or her password to a password that the user has used recently (the default is to prevent users from reusing their last three passwords).

Note

If you use password uniqueness as part of your password policy, be sure to set minimum password age high enough to prevent users from quickly cycling through several temporary passwords to get to their favorite password.

You can also specify these other aspects of account policy:

Whether account lockout occurs.

Whether users are forced to disconnect from the domain's servers when their logon hours expire.

Whether users must be able to log on to change their passwords.

When account lockout is enabled, if there are too many bad logon attempts on a user account, and no more than a specified length of time occurs between any two of the bad logon attempts, then the account is locked out. Accounts that are locked out cannot log on. If you enable account lockout, you can specify how many bad logon attempts cause lockout, the maximum amount of time that can occur between any two of the bad logon attempts to trigger lockout, and how long accounts are locked out.

If users are forced to disconnect from servers when their logon hours expire, they are given warnings just before the end of their specified logon hours. If they have not ended their connections by then, the server(s) to which they are connected will end the connection(s). Users are not forced to log off of their workstations, however.

If users are required to be able to log on to change their passwords, then they cannot change their passwords after they expire. If a user's password expires, the user must get help from an administrator to change the password and be able to log on again. If users aren't required to log on to change the password, the first time they log on after the password expires, they are prompted to change it, and do not need help from an administrator.


How Administrators Should Log On
How Network Security Works	24 of 41

How You Can Control What Users Can Do

How Administrators Should Log On

Most or all of the administrators on your network have a dual role: They are both administrators and users of the network. Although at times they will perform network administration tasks, at other times they will simply be network users, performing the same tasks as other users.

For this reason, it is a good idea for each administrator to actually have two user accounts. One of these accounts would be in the Administrators group and would be the account the administrator uses when performing network management tasks. The other account would be in the Users group in the domain and would be the account the administrator uses at all other times, when not performing network management.

If your administrators use two accounts in this manner, the network will be more secure. While logged on as a regular user, an administrator will be unable to accidentally change aspects of the network that only administrators can change, and if the administrator introduces a virus or Trojan horse, that program will not have the rights of an administrator and will be unable to modify operating system software.

Using this method means that usability will be lessened slightly for administrators, because they will have to log off and then log on again before they can administer the network.


Allowing Guest Access
How Network Security Works	25 of 41

How You Can Control What Users Can Do

Allowing Guest Access

By default, every domain and every Windows NT computer initially has a Guest account defined. The Guest account has no password and can be used for two types of guest logons: local guest logons and network guest logons. You can configure each domain and computer so that it allows both types of guest logon, only one type, or neither.

How Local Guest Logons Work

A local guest logon happens when a user working at a Windows NT computer specifies Guest as the user name in the logon dialog box when logging on. The guest user can then work at that computer (subject to the rights and permissions you have granted the Guest account) and use it to access the network.

How Network Guest Logons Work

A network guest logon occurs at a computer when a user from a domain that the computer does not trust tries to access the computer over the network. The computer allowing the network guest logon does not recognize the account trying to access it, because the computer does not trust that domain. In this case, the access is approved as a guest logon (as long as the Guest account of the target computer has no password). The guest user then has all rights, permissions, and group memberships on the computer that are granted to the Guest account, even though the guest user doesn't specify Guest as his or her user name.

Note that if you have set up your Windows NT Server network so that all user accounts are defined in Windows NT Server domains that are trusted by all other domains, network guest logons will rarely happen at servers, because a network guest logon can only happen when a user from an untrusted domain tries to access the computer. (Network guest logons may still happen with user accounts stored at Windows NT Workstation computers, or when a user of a MS-DOS computer logs on stand-alone and then accesses a Windows NT Server computer.)

Managing Guest Logons

If you do not want to allow either local guest logons or network guest logons on a Windows NT Server domain, you need not do anything; by default, the guest account is disabled. If you want to allow both local and remote guest logons, just use User Manager For Domains to enable the Guest account. To allow local guest logons but not network guest logons, enable the Guest account, but revoke its Access This Computer From Network right. And to allow network guest logons but not local guest logons, enable the Guest account, and revoke its Log On Locally right (but be sure Guest has the Access This Computer From Network right).

Managing guest logons on a Windows NT Workstation computers and on servers that are not domain controllers works the same way, except that the Guest account is enabled by default. So if you want to allow guest logons on the computer, you need not do anything. If you want to prevent guest logons, you must disable the Guest account.


How a Domain Interacts with Other Computers
How Network Security Works	26 of 41

How a Domain Interacts with Other Computers

The following sections describe how a domain and its servers interact with other computers that may be on your network.


Interactions with Windows NT Workstation Computers
How Network Security Works	27 of 41

How a Domain Interacts with Other Computers

Interactions with Windows NT Workstation Computers

A Windows NT Workstation computer can either participate in a domain and use user accounts and global groups from that domain and the domains it trusts, or it can be separate from all domains and use only its own users and groups.

A Windows NT Workstation computer that is separate from all domains has no interactions with domains at all. User accounts and local groups can be created on the workstation itself, but these are the only users and groups that can be used on the workstation. The workstation can use no user accounts or global groups from any domain. A user logged on using a local workstation account cannot access any server running Windows NT Server, except as a guest logon.

At a Windows NT Workstation computer participating in a domain, users can log on to user accounts located in the workstation domain (or in any domain the workstation domain trusts). For example, suppose a workstation is participating in the Sales domain, and Sales trusts the MIS domain. At the workstation, a user can log on to an account located in either the Sales domain or the MIS domain.

At a Windows NT Workstation computer participating in a domain, you can place users and global groups from the domain (and domains trusted by the workstation domain) in local groups on the workstation, and you can assign permissions and rights on the workstation to users and global groups from the domain (and domains trusted by the workstation domain).

Even though a workstation participating in a domain can use accounts located in that domain, user accounts can still be created at the workstation itself, as well. These accounts are local to that workstation and cannot be used on any other computer. One valid use of this might be for an employee to create an account for a spouse to allow the spouse to use the employee's word processor after hours, or so that the user can share files on the workstation with users who don't have a domain account.

However, you should not create a local workstation account for a user who also has a domain account. Instead, a user with a domain account should always log on to that account.

Note that even if a Windows NT Workstation computer participates in a domain, it cannot use local groups defined in the domain (it can use users and global groups defined in the domain, however).


Interactions with Servers Running Other Network Systems
How Network Security Works	28 of 41

How a Domain Interacts with Other Computers

Interactions with Servers Running Other Network Systems

With the exception of LAN Manager 2.x servers, servers running network operating systems other than Windows NT Server (such as Novell NetWare and IBM LAN Server) cannot participate in domains or share account information with Windows NT Server.

You can incorporate LAN Manager 2.x servers into your network in two ways:

As servers in a Windows NT Server domain (where the primary domain controller must be a Windows NT Server computer)

As parts of LAN Manager 2.x domains, where a LAN Manager 2.x server is the primary domain controller

Adding a LAN Manager 2.x server to a Windows NT Server domain presents a few problems, because the LAN Manager 2.x server is limited to LAN Manager 2.x abilities. Although the LAN Manager 2.x server receives a copy of the domain's user and group database, the LAN Manager 2.x server does not recognize local groups, so you will not be able to assign permissions for resources on LAN Manager 2.x servers to the domain's local groups.

Also, if the domain containing LAN Manager 2.x servers trusts other domains, you cannot assign permissions on the LAN Manager 2.x servers to users and global groups from the trusted domain. LAN Manager 2.x servers do not recognize trust relationships.

Domains made entirely of LAN Manager 2.x servers cannot have trust relationships with other domains, but resources on these domains can be accessed by Windows NT Workstation users. Because LAN Manager 2.x domains cannot trust other domains, they cannot use users and global groups defined on other domains. Therefore, for a Windows NT user to access a resource in a LAN Manager 2.x domain, that user must also have an account in the LAN Manager 2.x domain (or that domain must allow guest logons).

For information on providing access to Windows NT Server to users who don't have Windows NT Server accounts (but do have accounts on servers running other types of network software), see "Understanding Local Accounts," later in this chapter.


Interactions with Windows for Workgroups Computers
How Network Security Works	29 of 41

How a Domain Interacts with Other Computers

Interactions with Windows for Workgroups Computers

Computers running Windows for Workgroups interact with Windows NT and Windows NT Server computers just as Windows 3.1 or MS-DOS computers do.

Conversely, Windows NT Workstation users can access resources shared at Windows for Workgroups workstations in the same way other Windows for Workgroups users can.

Windows for Workgroups computers are organized into workgroups. Workgroups are similar to domains in terms of network browsing - when a user uses File Manager to browse the network, the user sees the network divided into domains and workgroups. If the user selects a domain or workgroup, the user can then browse the contents of that domain or workgroup.

Domains and workgroups can interoperate. If a Windows NT Workstation computer is not participating in a domain, you set it to participate in a workgroup, and the workstation can then be browsed as part of that workgroup. This workgroup can contain computers running Windows for Workgroups. Similarly, on a Windows for Workgroups computer, you can specify the name of a Windows NT Server domain as the computer's workgroup, and the Windows for Workgroups computer can then function as though contained in the domain.

Note that for a Windows for Workgroups computer to be able to browse a Windows NT Server domain, there must be at least one Windows for Workgroups computer in the domain to be browsed. If a Windows for Workgroups user must access a resource in a domain that has no Windows for Workgroups computers, the user must know the name of the computer where the resource is located.

Whenever a Windows for Workgroups computer starts, the user is logged on to the network, using a user name and password previously specified at the computer. If a Windows for Workgroups user has an account in a Windows NT Server domain, you can specify the user name and password of that account to Windows for Workgroups and set the workgroup name on the computer to be the name of the domain, and then the user will be logged on to his or her domain account automatically when Windows for Workgroups starts.


Understanding Local Accounts
How Network Security Works	30 of 41

How a Domain Interacts with Other Computers

Understanding Local Accounts

If your network currently has servers with network operating systems other than Windows NT, such as LAN Manager 2.x, Novell NetWare, or IBM LAN Server, you can use local user accounts (or just local accounts) to make the network access between users of these systems and users with Windows NT Server domain accounts a little easier.

A local account is a user account that behaves differently than regular user accounts do (also called global accounts). Local accounts cannot be used to log on interactively at a Windows NT computer, but in most other ways are just like other user accounts: They can access Windows NT computers over the network, can be placed in global and local groups, and can be assigned file permissions and rights. The one exception is that local accounts created in one domain cannot be used in domains that trust that domain - the use of each local account is limited to one domain.

When you use User Manager and File Manager, you see the icon at the left to represent local accounts, instead of the standard user account icon.

You would create and use local accounts in a domain in two types of situations: to allow users from other Windows NT Server domains access to LAN Manager 2.x servers in this domain, and to allow access to users whose home accounts are in untrusted domains, or domains not running Windows NT Server. These situations are discussed in more detail in the following sections.


Allowing Windows NT Users Access to LAN Manager 2.x Servers
How Network Security Works	31 of 41

How a Domain Interacts with Other Computers

Allowing Windows NT Users Access to LAN Manager 2.x Servers

The Windows NT Server system of pass-through authentication depends on the fact that trust relationships allow servers in one domain to recognize user accounts from other domains. However, even though LAN Manager 2.x servers can participate in Windows NT Server domains, and can recognize user accounts in their own domain, they will not be able to recognize user accounts from trusted domains - this is a limitation of LAN Manager 2.x.

For example, suppose that the Sales domain trusts the MIS domain. This lets you assign permissions on the servers running Windows NT Server in Sales to users from MIS. However, you cannot assign permissions for resources on the LAN Manager 2.x servers in Sales to users from MIS.

To solve this problem, you can create local accounts in the domain containing the LAN Manager 2.x servers. You should create a local account for each user from a trusted domain who needs to access those servers. You create a local account in the same way you create regular user accounts, except that while creating the account, you use User Manager for Domains to designate it as a local account.

You can then place the local account in global groups in your domain and assign those global groups the required permissions on LAN Manager 2.x servers (you must use global groups for this, because LAN Manager 2.x servers do not recognize local groups). Although you can give permissions directly to local accounts, it is not recommended - it would be difficult to maintain when you upgrade your LAN Manager 2.x servers to Windows NT and no longer require the use of local accounts.

If you upgrade all the servers in your domain to Windows NT Server, so that no LAN Manager 2.x servers remain, you can then remove all local accounts from the domain and begin referring to those users' actual Windows NT Server accounts instead. When it is time to remove local accounts from a domain, their different icons will help you do so accurately and quickly.


Allowing Users of Other Systems Access to Windows NT
How Network Security Works	32 of 41

How a Domain Interacts with Other Computers

Allowing Users of Other Systems Access to Windows NT

As you begin adding Windows NT to your network, you may have a situation where some users' accounts are on Windows NT Server domains, while other users' accounts are located on servers of other systems, such as LAN Manager 2.x, Novell NetWare, or IBM LAN Server.

To let users with accounts on other systems access Windows NT resources, you can create local accounts for those users in Windows NT Server domains containing those resources. You can then place those accounts in local or global groups in the domain and assign necessary permissions to those groups. Although you can give permissions directly to local accounts, it is not recommended - it would be difficult to maintain if you later upgrade those other systems to Windows NT Server and no longer require the use of local accounts.

If you do replace other systems with Windows NT after giving those users local accounts, you can then delete the local accounts and begin using those users' Windows NT Server accounts.

Local accounts are different from other user accounts in one important way - a local account in one domain cannot be used in domains that trust that domain. Therefore, if a user from another network operating system needs to access several Windows NT Server domains, you must create a local account for the user on each of those Windows NT domains.


Protecting Against Viruses and Trojan Horses
How Network Security Works	33 of 41

Protecting Against Viruses and Trojan Horses

In today's computing world, you must prevent intentional intrusions into your network that take the form of viruses and Trojan horses. Viruses are programs that attempt 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) on every computer they contact. Trojan horses are programs that masquerade as other common programs, in an attempt to capture information. An example of a Trojan horse is a program that masquerades as a system logon screen in an attempt to capture user names and password information, which the writers of the Trojan horse can use later to break into the system. You can go a long way in preventing intrusions by viruses and Trojan horses with a few simple steps.


How to Prevent Virus Outbreaks
How Network Security Works	34 of 41

Protecting Against Viruses and Trojan Horses

How to Prevent Virus Outbreaks

It is unlikely that any of your network users will write a virus program and introduce it to your system. It is much more probable that your users will unwittingly introduce a virus into your network when they obtain what they think is a useful, safe program from another source, such as an online bulletin board. Many network users don't realize that they can bring viruses into the network this way, so one of the best ways to keep your network safe from viruses is by educating your users about viruses.

You should also be sure to have at least one commercial virus-detection program and use it to regularly check your file servers for viruses. If possible, you should also make virus-detection software available to your users.

Other ways of protecting against viruses include the following:

Set file permissions to make all applications available on network servers and Windows NT workstations read and execute only, preventing them from being replaced by viruses. For information on this, see Chapter 5, "Managing Network Files."

Before putting a new application or file on the network, put it on a computer not attached to the network, and check it with your virus-detection software. You may want to also log on to this computer using an account with only guest access to the computer, so that the program being tested will have only guest permissions and be unable to modify any important files.

Regularly back up the files on your file servers (and workstations, if possible), so that damage is minimized if a virus attack does occur. For more information on backups, see Chapter 8, "Backing Up Network Files."


How to Prevent Trojan Horse Attacks
How Network Security Works	35 of 41

Protecting Against Viruses and Trojan Horses

How to Prevent Trojan Horse Attacks

Windows NT provides an important safeguard against Trojan horse programs: Before a user can log on at a Windows NT computer, the user must type the secure attention sequence, CTRL+ALT+DEL. This series of keystrokes always directly invokes the Windows NT operating system logon screen; Trojan horse programs will never be activated by it. This way, users are guaranteed to be providing their user name and password only to the operating system itself. To be sure that this is effective, you should educate your users to always type CTRL+ALT+DEL before logging on at a computer, even if the logon window already appears on the screen.

The secure attention sequence is also required before a user can unlock a locked workstation or change his or her password.

Another way to guard against Trojan horses is identical to a method for protecting against viruses; make your applications read and execute-only, so that they cannot be replaced with programs that masquerade as the original program and steal information.


Network Security Examples
How Network Security Works	36 of 41

Network Security Examples

This section includes examples showing how to apply the concepts discussed in this chapter.


Using the Master Domain Model
How Network Security Works	37 of 41

Network Security Examples

Using the Master Domain Model

A company of 3000 users, divided into 15 departments and a centralized MIS group, is setting up its Windows NT Server network. The company selects the master domain model for its Windows NT Server security model.

The MIS group creates a domain named MIS, which will serve as the master domain. This domain has a primary domain controller and two backup domain controllers; having three domain controllers ensures that the network will stay up if one of these servers fails.

All user accounts are created in the MIS domain. The MIS group also creates 15 global groups in the MIS domain. The name of each global group corresponds to one of the 15 departments in the company, and the members of each global group are the employees who work in that department. Initially, each employee is a member of exactly one of these global groups. No directories or printers are shared in the MIS domain; this domain serves only as an account-management domain.

Each of the 15 departments has its own Windows NT Server domain. Most of these department domains contain only one Windows NT Server computer, which is the domain's primary domain controller. All shared directories and printers in the network are shared in the department domains. Every one of the department domains trust the MIS domain, but none of the department domains need to trust each other.

The Administrators local group of each department domain contains the user account of at least one user working in that department, so that the user can share directories and create local groups in the domain and perform other necessary tasks. The MIS\Domain Admins group is also a member of the Administrators local group on every domain, so that the MIS group can perform software upgrades, back up network servers, and help out the departmental administrators with difficult problems. (If you want, you could have the departmental managers be only server operators in their own domains. They would still be able to share resources, but creating local groups and other administrative tasks would be left solely to the MIS group.)

When a local department administrator needs to create a new grouping of users for use only in that domain, he or she can create a local group in the domain. For example, suppose the administrator of the Sales domain needs to create a new group to contain the users CristalW, BillO, and PegEt, all of whom work in the Sales department. To do so, the administrator can create a local group, and put in it the accounts MIS\CristalW, MIS\BillO, and MIS\PegEt. These users work in the Sales domain, but like all other company employees, their accounts are located centrally in the MIS domain.

Suppose a new grouping of users is needed, and this group needs permissions in more than one domain. In this case, a local department administrator can send a message to the MIS group, who can create a global group in the MIS domain with the appropriate members. For example, if the MIS group creates a global group named Budget Planners in the MIS domain, this group could be granted permission to use resources in any domain.


Using the Multiple Master Domain Model
How Network Security Works	38 of 41

Network Security Examples

Using the Multiple Master Domain Model

A growing company of 20,000 users, divided into over 100 departments and a centralized MIS group, is setting up its Windows NT Server network. Because of the great number of users, the company selects the multiple master domain model, to ensure that performance in the master domains does not lag.

The company creates three master domains (MIS-Development, MIS-Sales, and MIS-Administrative), each with one primary domain controller and five backup domain controllers. The higher number of domain controllers in each domain provides greater performance in approving logon requests, as large numbers of employees will be logging on at about the same time each morning. The company chooses to use three master domains, rather than just two, so that the current model can serve the company as it grows.

All user accounts are created in one of the MIS domains. The master domain that contains a user's account depends on the job of the user; for example, the accounts of all users who work in product development are in MIS-Development.

Each of the individual departments has its own domain with its own administrator, who creates local groups, manages the sharing of the department resources, and keeps the department server(s) running.

Each of the three master domains trusts each other, and all department domains trust all the master domains. Department domains do not need to trust each other.

If a new global grouping of users is needed, it must be created by the MIS group. If the global group needs to contain users from two of the network's master domains, the MIS group actually needs to create two global groups: one in each master domain, containing the users whose accounts are in that domain. For example, a group containing users from both MIS-Sales and MIS-Administrative may be needed to check sales reports for the year. You could create groups named Sales Reports in each of these domains. Then, when you assign permissions, be sure to assign them to both MIS-Sales\Sales Reports and MIS-Administrative\Sales Reports.


Using the Complete Trust Model
How Network Security Works	39 of 41

Network Security Examples

Using the Complete Trust Model

A company of 1000 users with no centralized MIS group is setting up its Windows NT Server network. Because there is no centralized computer management, each department will need to administer its own server, so the best choice is the complete trust model.

Each department sets up its own domain and has its own domain administrator who is entirely responsible for both the user accounts and shared resources in the domain. Each domain administrator creates user accounts for all employees who work in the department corresponding to that domain.

Each department administrator also is responsible for creating global groups and local groups in the domain. When the department administrator creates a group containing only users from that department's domain, he or she can create a global group. When a group containing users from other domains is needed, a local group is necessary.

Each department administrator can establish two-way trust relationships with other Windows NT Server domains. Then users and global groups from one domain can be given rights and permissions, or placed in local groups, in the other.

In this case, department administrators have the responsibility to be sure that only appropriate people are added to global groups. For example, if the Shipping department trusts the Sales department, the Shipping administrator can give permissions to the Accountants global group from the Sales domain. If the Sales administrator subsequently adds more users to the Accountants global group, these new users will immediately have the permissions granted to Accountants in the Shipping domain. Therefore, the Shipping administrator must be careful to grant permissions only to appropriate global groups from domains with trusted administrators, and the Sales administrator has the responsibility to put only appropriate users into global groups.


Using the Operator Local Groups
How Network Security Works	40 of 41

Network Security Examples

Using the Operator Local Groups

Suppose a medium-sized group is trying to decide how to assign its technical staff to the various administrator and operator groups.

At least one person must be an administrator. There are several important abilities that only members of Administrators have, such as assigning user rights, taking ownership of files, and managing of auditing. Because of the unique abilities of the Administrators group, the members of this group are ultimately responsible for planning and maintaining network security for the department. You can also allow members of the domain's Administrators group to administer users' Windows NT Workstation computers, if you want.

If there is someone in the group responsible for hiring new or temporary employees, or even just someone responsible for helping newly hired people get started, it may make sense to make this person a member of Account Operators. This account operator can then create domain accounts for the new employees when preparing for them, and put these accounts in the appropriate groups.

If the domain's Administrators group has few members, you should probably assign at least one additional person to the Server Operators group. The basic mission of members of the Server Operators group is to keep the domain servers running. This mission is reflected in their ability to shut down servers, set the system time on servers, lock and override the lock of servers, share directories and printers on the server, and format its hard disks. If possible, you should be sure at least one member of either Administrators or Server Operators is present during all hours that people are using the network.

If the ability to print documents quickly is very important to your group, it may be useful to add several capable people to the Print Operators group, to ensure that printer problems can always be addressed quickly.


Setting Up a Universal Operators Group
How Network Security Works	41 of 41

Network Security Examples

Setting Up a Universal Operators Group

Suppose your network has multiple domains, each containing computers that need to be backed up. You have a single group of backup operators that you want to be able to back up computers in all domains.

You should use a combination of global groups and local groups to set this up. By doing so, you ensure that your backup operators group is easy to maintain as your network evolves and as backup operators come and go, new computers are added, and even as new domains are added.

1.	In each domain where accounts of backup operators are located, create a global group called Domain BackupOps, and make all backup operators in the domain members of this group.

2.	In each domain where backups are needed, put all the existing Domain BackupOps global groups into the local domain's Backup Operators local group. When you do so, don't forget to put each domain's Domain BackupOps global group into that domain's own Backup Operators local group, as well.

Once this is done, all backup operators will be able to back up the domain controllers in all domains.

If you also need to back up Windows NT Workstation computers or Windows NT Server computers that are not domain controllers, you'll need to go a step further. On each of these Windows NT computers that needs to be backed up, add all the Domain BackupOps global groups to the computer's Backup Operators local group.

Maintenance of this model is simple. If a backup operator leaves the company, or a new one joins, you simply remove the user's account from or add it to the Domain BackupOps global group in the domain where the user's account is located. If a new backup domain controller is added to an existing domain, all your backup operators will be able to back it up automatically. If you need backups at another workstation or server, you just add all the Domain BackupOps global groups to that computer's Backup Operators local group. And if a new domain is added to your network, you simply add all the Domain BackupOps global groups to the Backup Operators local group in that domain.

For example, suppose you are working with the following network setup, using the master domain model with MIS as the master domain.

Because MIS is the only master domain, all user accounts are located there. To create the universal backup operators group, just create the Domain BackupOps global group in the MIS domain, and put MIS\Domain BackupOps into the Backup Operators local group in all three domains. Now, just add the user accounts of each backup operator to the Domain BackupOps global group, and the setup is complete.

The next example uses the multiple master domain model. In this situation, create Domain BackupOps global groups in both MIS1 and MIS2, and put both MIS1\Domain BackupOps and MIS2\Domain BackupOps in the Backup Operators local group in every domain.


Managing User Environments
Chapter 4	1 of 19

Managing User Environments

On a Windows NT Server network, you have several ways to define and enhance users' workstation environments. You can define users' network connections, available applications, Windows program groups, and Windows desktop appearance. You can even prevent the users of Windows NT Workstation computers from changing the desktop configuration you create, if you want.

The most powerful method you have of managing user environments is through user profiles for users of Windows NT Workstation computers. A profile is a file that serves as a snapshot of a user's desktop environment, defining the Program Manager groups and program items in those groups, printer connections, window size and positioning, and screen colors. With profiles, you can also restrict users' ability to change these settings on their own workstations.

Another way you can enhance user environments is by assigning logon scripts to users. If a user has a logon script, that script is run whenever a user logs on at any type of workstation on the network. The script can be a batch file containing operating system commands (such as commands to make network connections or start applications) or an executable program.

You may also choose to give each user a home directory on a server or workstation. A user's home directory gives that user private storage space. Each user has control over the contents of and access to his or her home directory.

You can also set the environment variables on each workstation. Environment variables specify the workstation's search path, directory for temporary files, and other similar information.


How User Profiles Work
Managing User Environments	2 of 19

How User Profiles Work

User profiles contain the per-user settings of the Windows NT environment. The following table lists exactly what is saved in a profile.

User profiles are useful only for users working at Windows NT Workstation computers. They have no effect on users working at MS-DOS computers.

Windows NT Workstation computers implement some aspects of user profiles. On a network using Windows NT Server, you can expand the usefulness of profiles in many ways. But before you learn how, you should fully understand how profiles work on computers running Windows NT Workstation.

Settings Saved in a User Profile

Source		Parameters saved
Program Manager		All user-definable settings for Program Manager, including personal program groups and their properties, program items and their properties, and all settings saved by the Save Settings On Exit and Save Settings Now commands.
File Manager		All user-definable settings for File Manager, including network connections, and everything saved by the Save Settings On Exit command.
Command prompt		All user-definable settings for the command prompt, including fonts, colors, settings for the screen size buffer, and window position.
Print Manager		Network printer connections and all settings saved by the Save Settings On Exit command.
Control Panel options		All settings for the Color, Mouse, Desktop, Cursor, Keyboard, International, and Sound options. For the System option, only the entries in the User Environment Variables box. The other Control Panel options do not contain user-specific settings.
Accessories		All user-specific application settings affecting the user's Windows NT environment. These accessory applications include Calculator, Calendar, Cardfile, Clock, Notepad, Paintbrush, and Terminal.
Third-party Windows NT-based applications		Any application written specifically for Windows NT can be designed so that it tracks application settings on a per-user basis. If this information exists, it is saved in the user profile.
Online Help bookmarks		Any bookmarks placed in the Windows NT Help system.


Local Profiles on Windows NT Workstation
Managing User Environments	3 of 19

How User Profiles Work

Local Profiles on Windows NT Workstation

Local profiles are always created automatically by Windows NT; no work by administrators is necessary. Whenever a user (with the exception of those users who don't have the ability to keep local profiles) logs on and subsequently logs off at a Windows NT Workstation computer, Windows NT saves the settings made by the user in a local profile.

Note

Members of the Administrators, Power Users, Users, and Backup Operators local groups have the ability to keep local profiles on Windows NT Workstation computers. Members of the Guests local group do not have this right (unless they are also a member of one of the local groups that do have this ability).

These settings include network connections, program groups and items, window size and position, and screen appearance. When the user logs on again at this workstation, the workstation will recognize the user and load the profile created the last time the user logged off at this workstation.

Profiles ensure that each user always has his or her preferences available when logging on. On workstations that are used by different people, profiles allow each user to set up a unique environment. Each user's environment can be different from the environments used by the other users of that workstation, but each environment is preserved, and the appropriate one is loaded when a user logs on.

Local profiles are computer-dependent: Settings made by a user at one workstation are not available when the user logs on at a different workstation.


How Server-Based Profiles Are More Useful
Managing User Environments	4 of 19

How User Profiles Work

How Server-Based Profiles Are More Useful

On networks with servers running Windows NT Server, you can create profiles for users that have domain accounts and store these profiles on servers. This extends the usefulness of profiles in three ways:

Each user can have a single profile, with one configuration, which is loaded when the user logs on at any Windows NT Workstation computer.

You can use the profile to restrict the user's access to his or her workstation, preventing the user from changing certain aspects of its configuration.

If many users are using the same profile, you can give all of them access to a new application or server simply by editing that profile.

The first two of these benefits are provided by both types of server-based profiles: personal profiles and mandatory profiles. The third benefit is provided only by mandatory profiles. The following sections explain more about the differences between personal and mandatory profiles.

How Personal and Mandatory Profiles Are Different

Both personal and mandatory profiles are stored on servers. With each type of profile, you assign a profile to a user by specifying the location and filename of the profile in the user's account. Each user can have only one profile assigned.

The filename extensions of personal profiles must be .USR. The filename extensions of mandatory profiles must be .MAN.

Users of personal profiles can permanently change their profiles. A user doesn't consciously change the personal profile, but every time the user logs off from a workstation, any changes the user made to the per-user settings are saved. When the user subsequently logs on again, the environment that existed the last time the user logged off is restored.

Users of mandatory profiles cannot permanently change their profiles. Although a user with a mandatory profile may be able to change the per-user settings during one session, these changes are not uploaded to the user's profile when the user logs off. When the user logs on again, the profile's original settings, which don't include changes made by the user, are reestablished.

Why Personal Profiles Are Useful

The main use of personal profiles is to let each user's settings and preferences follow that user from workstation to workstation. This is obviously useful on networks where users often use different workstations. It can be useful in other situations as well. For example, when a user's computer is upgraded to a more powerful one, having a personal profile ensures that the user's preferences are immediately in place on the new computer.

If you want, you can also make settings in a profile that restrict the user's ability to change his or her desktop environment. For a list of those restrictions you can set, see "Using Profiles to Restrict Users' Abilities," later in this chapter.

With personal profiles, each user will have his or her own profile. It is recommended that the filename of each personal profile match exactly the user name of the profile's user; for example, the user BillO would have the profile BILLO.USR. This way, if you create a new user account by copying BillO's account, the new user will have his or her own user name set as the profile name. For example, if you create a new account JeffHo by copying BillO's account, if BILLO.USR is BillO's profile, JeffHo's profile will be set to JEFFHO.USR.

Why Mandatory Profiles Are Useful

Mandatory profiles make a user's single desktop environment available at every workstation, just as personal profiles do.

By using mandatory profiles, you also prevent users from being able to change their own profiles. Any environment changes made by a user during a session (if the user's profile allows them to make changes) are not saved to the user's mandatory profile. When the user logs off and logs on again, the original environment you specified in the profile is restored.

For this reason, mandatory profiles are more useful when you want to restrict users' abilities at their own workstations. (For a list of the restrictions you can make, see the following section of this chapter.)

Because a single mandatory profile is often assigned to many users, another benefit is the ability to easily update the environments of many users at once. For example, if you need to add a new program item for several users, you can just add it to their mandatory profile.

If you use personal profiles instead of mandatory profiles, giving users access to new servers by editing their profiles is not practical, because you would have to change every user's profile individually. If your network uses personal profiles and you want to be able to update what connections a user has, you should consider using logon scripts. For more information, see "How Logon Scripts Work," later in this chapter.

Using Profiles to Restrict Users' Abilities

In both personal and mandatory profiles, you can prevent the user from doing one or more of the following:

Creating program items

Creating program groups

Changing the contents of program groups

Changing program item properties (such as the application a program item starts)

Running programs from the File menu in Program Manager

Making connections to network printers (other than those printers the profile itself makes connections to)

Imposing some or all of these restrictions on users is very useful in a secure environment, such as a bank. In this environment, you would probably want to create a single mandatory profile for each type of job and then assign that profile to all users who fit the job description, for example, TELLERS.MAN for all bank tellers.


Understanding the Default Profile
Managing User Environments	5 of 19

How User Profiles Work

Understanding the Default Profile

Every Windows NT Workstation computer contains a default user profile file, which is loaded when a user logs on in one of the following situations:

When the user account does not have a profile assigned to it, and the user has never logged on to this Windows NT computer

When a user account's assigned personal profile cannot be accessed during logon (for example, if the server where the profile is stored is down), and the user has never logged on to this Windows NT computer

When a user logs on to the Guest account

When a user account does not have a user profile file assigned to it, the first time that user logs on to a particular Windows NT computer, the computer's default profile is used. Then (if the user has the ability to have a local profile) during logoff, the per-user settings are saved and become the user's local profile at the workstation. Whenever that user logs on again at the computer, Windows NT loads the saved copy of that locally cached profile from the last logon, instead of the computer's default profile.

When Windows NT is installed, the default profile does not place tight restrictions on users who log on using it. Therefore, on secure networks, you may want to modify computers' default profiles so that they allow no more access than the most restrictive of your other profiles.


How Profiles Are Loaded and Saved
Managing User Environments	6 of 19

How User Profiles Work

How Profiles Are Loaded and Saved

The following diagrams illustrate the process when a user logs on and logs off at a Windows NT computer. For more information on the locally cached versions of users' server-based profiles mentioned in the diagram, see the following section.

How Profiles Are Loaded

How Profiles Are Saved


Local Caching of Profiles
Managing User Environments	7 of 19

How User Profiles Work

Local Caching of Profiles

Most users have the right to keep a local profile on a Windows NT Workstation computer.

Whenever a user logs off a Windows NT Workstation computer, the per-user settings that existed when the user logged off are saved in a local profile. If the user has no server-based profile, this is the only profile that exists for the user. If the user also has a server-based personal profile, what is saved on the workstation is a locally cached version of the user's profile. The locally cached version of the profile is used whenever a user with a server-based profile logs on and the server containing the profile is unavailable.

If a user has a personal profile, the per-user settings are saved to both the user's personal profile and the locally cached version of the profile when the user logs off. The locally cached profile is identical to the updated personal profile.

If a user has a mandatory profile, changes made by the user during a session are not uploaded to the mandatory profile when the user logs off - the user can never change the mandatory profile. However, if the mandatory profile allows the user to make changes during a session, any changes made by the user are saved in the locally cached version of the mandatory profile. So, the next time the user logs on at this workstation, if the user's mandatory profile is unavailable, the locally cached profile is loaded, and the user will have the changes made during his or her last session.

If a user logs on and both the server-based profile and local version of the profile are unavailable, the user is logged on using the computer's default profile, if the user has a personal profile. If the user has a mandatory profile, the logon attempt is denied.


Personal and Common Program Groups in Profiles
Managing User Environments	8 of 19

How User Profiles Work

Personal and Common Program Groups in Profiles

With Windows NT, every program group is one of two types: common or personal. Common program groups are always available on the workstation, no matter who is logged on. Personal program groups are private to the user who creates them.

At Windows NT Workstation computers, only members of the workstation's Administrators and Power Users groups can create common program groups. When one of these users creates a program group at a workstation, the user chooses whether to make the group common (making it available to all users of that workstation) or personal (making it available only to that user). Personal program groups are saved as part of a user's local and personal profile.

When you create user profiles, you can include only personal program groups. If you want to create a program group for the purpose of including it in the profile, it must be a personal group.

When creating a profile, you also choose whether to allow the profile's user to have access to a workstation's common program groups. If you choose to do so, when a user logs on at a workstation, any common groups already existing at the workstation appear, and the user has access to them. If you choose to hide common program groups from a user, the user will never see common groups at any workstation, and the only program groups the user can use are the personal program groups in the user's profile.


Allowing for Different Hardware Configurations
Managing User Environments	9 of 19

How User Profiles Work

Allowing for Different Hardware Configurations

Because profiles you create and assign to users may be used from various types of workstations, you should keep in mind that these workstations may have different hardware configurations, particularly differing video boards and display monitors.

Because a profile determines screen placement and size of windows, the type of display hardware a workstation has affects how well the profile works. For example, the window setup in a profile created for a computer with a super-VGA screen may not look correct when loaded on a computer with a regular VGA monitor.

To prevent problems, keep two things in mind:

When creating or editing a profile for a single user, use a computer with the same type of video hardware as the computer the user typically uses.

When creating a mandatory profile for a group of users, create a single profile for the whole group of users only if they all use computers with the same type of video hardware.

For example, if you are creating a profile for a group of bank tellers, some of whom use super-VGA hardware and some VGA hardware, you may want to create two profiles instead: TELLER-SUPERVGA.MAN and TELLER-VGA.MAN. When doing so, use a super-VGA computer to create TELLER-SUPERVGA.MAN and a VGA computer to create TELLER-VGA.MAN.


Allowing for Different Software Configurations
Managing User Environments	10 of 19

How User Profiles Work

Allowing for Different Software Configurations

Different workstations on your network probably have software configurations that are different, perhaps in the applications installed or where they reside. Because of this, the program paths you specify when you configure Program Manager while setting up a user profile may not always work. This is particularly a problem when a user uses more than one computer or when you are setting up a mandatory profile for multiple users.

You have three possible solutions to this problem:

Put the needed applications on a server, and in the command line of the program group item, specify a path to each program.

One advantage of this technique is that it makes it easy to upgrade everyone to a new version of a program by upgrading the single program on the server. (However, you must be sure to adhere to the multiple-user restrictions imposed by an application's license.)

Make sure that the application is installed in the same location on every workstation.

For example, if APP.EXE is located in C:\EXAMPLE on all workstations, you would cause no problems by specifying C:\EXAMPLE\APP.EXE in the command line for that program item.

Make sure every workstation has an applications directory, whatever that directory is, in its search path. Then, in the command line for the application's program item, you can simply specify the application's name.

For example, if APP.EXE is located in C:\EXAMPLE on one computer and in D:\APPS\APP on another, be sure C:\EXAMPLE is in the search path of the first computer and D:\APPS\APP is in the path of the second. This way, a profile specifying just the program's name (APP.EXE) works on both computers.

The search path is specified in the User Environment Variables box of the System option in the Windows NT Control Panel.

If you assign home directories to users on your network, you may want to specify %HOMEDRIVE%%HOMEPATH% as the working directory of each application in every user's profile. %HOMEDRIVE% and %HOMEPATH% specify the local drive letter assigned to the share containing the user's home directory and the path to that directory. This way, each user will have a home directory set as the default directory to be used in all File Open and Save As dialogs.


Using Profiles to Start Applications Automatically
Managing User Environments	11 of 19

How User Profiles Work

Using Profiles to Start Applications Automatically

You can use a profile to specify what application(s) automatically start when the profile's user logs on. To do this, you place an icon for the application in a startup group for the user.

The best way to create a startup group in a user's profile is to do so in the User Profile Editor. This tool allows you to designate any one of the user's program groups as the startup group. Note that when you designate a startup group this way, the startup group name does not have to be Startup.

When a user logs on at a workstation, the applications in up to two program groups may start automatically:

If the workstation has a common program group called Startup, the applications in this group start.

If the user has a server-based profile, and you used User Profile Editor to designate one of the user's program groups as a startup group, the applications in that group start. If the user does not have a profile, or the user's profile does not have a startup group designated, Windows NT checks to see whether the user has a personal program group called Startup. If so, the applications in that group are started.

Note that a user's personal group named Startup works only if an administrator has not designated one of the user's other program groups as a startup group. If an administrator has done so, the user's personal group named Startup is disabled.


How You Create User Profiles
Managing User Environments	12 of 19

How User Profiles Work

How You Create User Profiles

You can create a server-based profile in one of two ways, depending on whether you want to make any initial settings in the profile.

If you don't need to make settings in the profile, you can just specify a personal profile filename (with the .USR extension) in each user's account. There should be no file corresponding to the filename you specify. This way, the next time the user logs on, Windows NT determines that no server-based profile currently exists for the user. Then, when the user logs off, Windows NT creates a file by the filename you specify and saves all the per-user settings the user currently has into that file. This profile is then loaded the next time the user logs on. This is a good way to give the advantages of server-based profiles to many users, even if they already have user accounts. Be sure to specify a different profile filename for each user, so that the changes one user makes do not affect other users.

If you do want to make settings in users' profiles, you create the profile using the User Profile Editor, and follow three general steps:

1.	Go to a Windows NT Workstation computer, and configure the workstation the way you want. Use Program Manager to create program groups and items, make network connections, set window size and position, and set screen appearance.

2.	Use the User Profile Editor to make further settings for the user and, if you want, restrict the actions the user can take at the workstation.

3.	Use the User Profile Editor to grant permissions to a user or global group to use this profile, and then save the profile. This will save both the settings you made with User Profile Editor and the general configuration you created in step 1.

When you save a user profile, you can save it either as a regular mandatory or personal profile, or as the workstation's default profile or system default profile. (Default profiles are explained in "Understanding the Default Profile," earlier in this chapter.) The system default profile is used at a computer when no user is logged on at the computer. The only settings that matter in a system profile are the wallpaper, background color, and screen saver settings.

For more detailed instructions, see the Windows NT Server System Guide.


Managing Existing Profiles
Managing User Environments	13 of 19

How User Profiles Work

Managing Existing Profiles

When you want to change an existing profile, you can do so in either of two ways:

Assign the profile to a user account, and then log on at a workstation specifying that account as your user name. Then modify the profile, both by making changes to the user environment using the normal Windows tools such as Program Manager and Control Panel, and by using the User Profile Editor.

Or, open the User Profile Editor, and modify the settings there. You can use this method while logged on to your usual user account. However, you can modify only those settings found in the User Profile Editor; for example, you can't create personal program groups, change window sizes, or change screen colors.

If you use the first method to modify profiles, it is a good idea to first create a special user account for administering profiles. This way, when you want to change a profile, you can temporarily assign the profile to the profile administrator's account, rather than assigning it to your user account.

To create a profile administrator's account, create a regular user account with User Manager, and be sure to add the account to the domain's Domain Admins global group.


Logon Scripts
Managing User Environments	14 of 19

Logon Scripts

Logon scripts are batch files or executable files that run automatically when a user logs on at a computer running either Windows NT or MS-DOS. Logon scripts are often used to configure users' working environments by making network connections and starting applications.

User profiles can do everything that logon scripts can do, and more. However, there are several reasons you may want to use logon scripts instead of, or in addition to, user profiles:

You have users working on MS-DOS computers. User profiles work only on Windows NT Workstation computers.

You want to manage part of the user environment (such as network connections) without managing or dictating the entire environment.

If you use only personal profiles, you may want to use logon scripts to create common network connections for multiple users.

Logon scripts are easier to create and maintain.

You already have LAN Manager 2.x running on your network, and you want to continue to use logon scripts you created for that system.


How Logon Scripts Work
Managing User Environments	15 of 19

Logon Scripts

How Logon Scripts Work

To assign a user a logon script, simply designate the path name of the logon script file in the user's account. Then, whenever that user logs on, the logon script is downloaded and run. You can assign a different logon script to each user or create logon scripts for use by multiple users.

Note

The path name you specify in the user's account is relative to the logon script path of the computer where the script is stored. For example, if the computer's logon script path is systemroot\SYSTEM32\REPL\IMPORT\SCRIPTS and the logon script for CristalW is systemroot\SYSTEM32\REPL\IMPORT\SCRIPTS \CRISTALW.BAT you need specify only CRISTALW.BAT as the logon script path name in CristalW's account.

To create a batch-file logon script, simply create an MS-DOS batch file. (For more information on creating batch files, see the Windows NT Server System Guide or your MS-DOS documentation.)

There are several special parameters you can use when creating logon scripts, as shown in the following table.

Special Logon Script Parameters

Parameter	Description

%HOMEDRIVE%	The user's local workstation drive letter connected to the user's home directory

%HOMEPATH%	The full path name of the user's home directory

%HOMESHARE%	The share name containing the user's home directory

%OS%	The operating system of the user's workstation

%PROCESSOR%	The processor type (such as 80386) of the user's workstation

%USERDOMAIN%	The domain containing the user's account

%USERNAME%	The user name of the user

A logon script is always downloaded from the server that validates a user's logon request. For users with accounts on Windows NT Server domains that have one or more backup domain controllers as well as a primary domain controller, any one of the domain controllers may authorize a user's logon attempt. So, 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 primary and backup domain controller in the domain.

The best way to do this is to use the Replicator service. This service maintains identical copies of a directory tree on multiple computers. When you make a change to a file in the master copy of the tree (located on the export server), the Replicator service automatically copies the change to the other computers (the import computers).

When you use the Replicator service with logon scripts, you'll set up one of the domain controllers as the export server and all the other domain controllers in the domain as import servers.

For more information about the Replicator service, see Chapter 5, "Managing Network Files." For instructions on setting up and using the Replicator service, see the Windows NT Server System Guide


Home Directories
Managing User Environments	16 of 19

Home Directories

Home directories can serve as private storage spaces for users. Users typically use their home directories to store their private data. Normally, users also control access to their home directories and can restrict or grant access to other users.

If your network workstations have little spare hard-disk room, you may want to assign each user a home directory on a server. You can also assign users home directories on their own workstations; you may want to do this if a user's workstation has enough hard-disk space for the user's data but you don't want the user to be able to access the files and directories on the rest of the workstation. In this case, you'll probably want to set up the user's workstation so that the home directory, and the subdirectories under it, are the only directories for which the user has more than List permissions. (For more information on file and directory permissions, see Chapter 5, "Managing Network Files.")

If a user has a home directory on a computer other than his or her own workstation, a connection is automatically made to the home directory every time the user logs on.

Whenever a user starts a command prompt, the user's home directory is set as the default directory. The user's home directory is also set as the working directory for all applications the user starts, except for applications that have a program item that specifies a different working directory.

Windows NT provides three special replaceable parameters for home directories: %HOMEPATH%, %HOMEDRIVE%, and %HOMESHARE%. %HOMEPATH% represents the path name of the user's home directory, and %HOMEDRIVE% is the local drive letter for the network connection to the home directory, if the home directory is not located on the user's workstation. %HOMESHARE% is the uniform naming convention (UNC) name of the shared directory containing the user's home directory. You can use these variables when setting up logon scripts or other batch files, or in Program Manager, such as when you specify application path names or working directories.


How Environment Variables Are Set
Managing User Environments	17 of 19

How Environment Variables Are Set

On a Windows NT computer, environment variables are various settings that affect how Windows NT finds programs, allocates memory space for some programs, and controls the behavior of various programs.

Windows NT has two types of environment variables: user and system. You can view and change both user and system environment variables (and create new ones) in the System option of Control Panel.

User environment variables can be different for each user of a workstation. A computer's system environment variables are the same for every user of that computer.

If any conflict exists between different types of environment variables with the same name (such as having both a temp user environment variable and a temp system environment variable), Windows NT resolves the conflict in this way:

System environment variables are set first.

User environment variables defined in the System dialog box are set next.

Variables defined in AUTOEXEC.BAT are set last.

If an environment variable is set as both a system environment variable and a user environment variable, the value for the user environment variable overrides the value for the system environment variables. However, variables in AUTOEXEC.BAT do not override the other two types of environment variables; if a variable in AUTOEXEC.BAT duplicates another variable, the value from AUTOEXEC.BAT is discarded.

The PATH environment variable is an exception. The directories specified in both the PATH user environment variable and AUTOEXEC.BAT are appended to those specified in the PATH system environment variable.

User environment variables are saved in user profiles.

The following table lists available system and user environment variables. You can also add new environment variables.

Environment variable	Explanation
System:
ComSpec	Specifies the directory where the command interpreter, CMD.EXE, is located.
OS2LibPath	Specifies the directories where programs running on the OS/2 subsystem are to search for .DLL files.
Path	Specifies the directories in which to search for executable program files.
WinDir	Specifies the directory where Windows NT Server or Windows NT is installed. This variable is provided for backward-compatibility with older applications.
User:	tmp
temp	Both specify the default directory in which applications can place temporary files while running. Both are necessary because some existing applications use tmp as the environment variable, while others use temp.


User Environment Example
Managing User Environments	18 of 19

User Environment Example

The following example shows how to apply the concepts explained in this chapter.


Configuring User Environments for Usability
Managing User Environments	19 of 19

User Environment Example

Configuring User Environments for Usability

Suppose you want to configure users' environments to make them as convenient as possible for a group of Windows NT users who all need the same set of initial network connections and program items.

To be able to modify program items, you must use profiles. You can use either mandatory profiles or personal profiles. To decide, think about how you want the profiles to be modified and maintained: If you want to be able to make changes to the environments of the whole group at once, use mandatory profiles. If you want users to be able to make lasting changes themselves, use personal profiles.

Once you have decided this, create a user account, and name it Profile Administrator. Log on to this account. Then make the network connections you want users to have automatically when they log on, and create program items for the applications they need. Make all the other environment settings you want the users to have, as well. Then start User Profile Editor and save the configuration as a profile. If you have decided to use mandatory profiles, give the profile a name that represents the whole group, and use the .MAN extension (for example, ACCOUNTANTS.MAN). If using personal profiles, give the profile the filename that is the same as the user name of one of your users, with the .USR extension (for example, PEGET.USR).

Log off the Profile Administrator account and log on to your regular administrative account.

With User Manager, assign the profile to the appropriate user account(s). If you have chosen to use a mandatory profile, your work is done.

If you have chosen personal profiles, and you have not yet created user accounts for all users who will use this profile, you should do so by copying the user account to which you assigned this first profile. That way, the profile name setting of the new account is made automatically. For example, if you create an account JeffHo by copying the account PegEt, and PegEt's account specifies a personal user profile of PEGET.USR, the user profile name in JeffHo's account is automatically set to JEFFHO.USR.

To finish the work required for personal profiles, repeatedly copy the original profile you created (copying it to a new filename each time) until a profile file exists for each user. The filename of each profile file must correspond to each user's user name: for example, if ErnestA is one of the users, you must copy the profile to a file named ERNESTA.USR.

If the user accounts of each user do not already specify the appropriate filename, do so with User Manager.


Managing Network Files
Chapter 5	1 of 15

Managing Network Files

An important use of servers on most networks is for sharing files and directories with network users. When a directory is shared, users can make connections to the directory from their own workstations and access the files in the directory from there. The shared directory functions as another hard disk available to the user.

The Windows NT Server operating system provides superior performance, reliability, and security for file sharing - especially if you use the Windows NT file system (NTFS).

You can set file permissions on files and directories on NTFS volumes, so that only appropriate users can access them. With NTFS file permissions, you can set security differently for each file and directory, if you want. For each file and directory, you can specify exactly which groups and users can access the file, and exactly what level of access each group or user is permitted. NTFS file permissions apply to both users working at the computer containing the file and to users accessing the file over the network, if it is shared.

You can audit the access of files and directories on NTFS volumes on the server. When you audit a file or directory, an entry is written to the Windows NT Server security log whenever a user accesses the file. You can define exactly which types of access for each file or directory cause audit entries to be written.

The concept of file ownership is also supported. Each file and directory has an owner, who controls access to the file or directory. Other users can access the file or directory only if the owner allows it.

Windows NT Server also supports directory replication. With the Replicator service, you can set up a directory tree on one server (called the export server) and designate other servers and workstations (called the import computers) to maintain duplicates of this directory tree. Subsequently, when you make changes to the directory tree on the export server, Windows NT Server copies the changed files to all the import computers, ensuring that all the computers always have identical copies of the tree.


Choosing a File System
Managing Network Files	2 of 15

Choosing a File System

This section contains updated information for Windows NT version 3.51. Click here to see the new information.

Servers running Windows NT Server support three file systems: the Windows NT file system (NTFS), the file allocation table (FAT) file system, and the high-performance file system (HPFS).

A server running Windows NT Server can use one or more of these file systems on its disks and partitions. You must choose which file system(s) to use on each of your servers.

It is recommended that you use the following guidelines to choose your server file system(s):

If the server does not need to boot MS-DOS or OS/2 in addition to Windows NT Server, use only NTFS on the server.

If the server does need to boot MS-DOS or OS/2, maintain the current file system (either MS-DOS or HPFS) on the C drive. You may optionally put NTFS on additional partitions on the server, as long as those partitions don't need to be readable by MS-DOS or OS/2.

These additional guidelines may affect your decision of which file system(s) to use on your servers:

For an x86-based computer, Windows NT looks for certain files in the root directory of the C drive at startup. So this partition must be formatted with the NTFS, HPFS, 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 for the FAT file system. If you want to use NTFS, you need to create a second partition large enough to contain everything you want to protect with Windows NT security.

The following table describes the advantages and disadvantages of each of the three file systems in full detail.

File System Advantages and Disadvantages

Advantages		Disadvantages
Windows NT File System (NTFS):
Supports complete Windows NT security, so you can specify who is allowed various kinds of access to a file or directory. This "discretionary access control" is available for files on NTFS partitions. Keeps a log of activities to restore the disk in event of power failure or other problems. Supports the fault-tolerance capabilities of Windows NT.  Supports file and directory names of up to 255 characters and supports extended file attributes. Automatically generates correct MS-DOS filenames so that files can be shared with MS-DOS users. A program designed to run under other operating systems such as MS-DOS can access NTFS files when running under Windows NT.  On a Windows NT system, NTFS provides higher performance than FAT or HPFS.		Recognized only by Windows NT. When the computer is running another operating system (such as MS-DOS or OS/2), that operating system cannot access files on an NTFS partition. If drive C is formatted for NTFS, you cannot run MS-DOS from your hard disk. (But you can still run MS-DOS - based applications.)
File allocation table (FAT):
As it is the most widely used file system for PCs, files can be accessed when your computer is running another operating system, such as MS-DOS or OS/2.  You must use FAT on the partition for drive C if you want to run MS-DOS from the hard disk. Floppy disks or removable hard disks for sharing data between computers must use FAT.		Files on a FAT partition are not protected by the security features of Windows NT. Cannot support large files. Less robust than NTFS; for example, no automatic disk restore features.
High-performance file system (HPFS):
Created for and used by the OS/2 operating system, version 1.2 and higher. Supports long filenames.  Provides better error correction than does the FAT file system.		Has not been widely adopted. Files on an HPFS partition are not protected by Windows NT security. On HPFS volumes, MS-DOS and Windows 3.1-based applications cannot access files with long filenames or with long directory names in their paths.


Sharing Files with Network Users
Managing Network Files	3 of 15

Sharing Files with Network Users

When you share a directory on the server, users can theoretically gain access to that directory, the files in it, all subdirectories of that directory and their contents, and all subdirectories of those subdirectories and their contents, and so on. Every point on the directory tree below the shared directory could be available to network users.

If the shared directory is on an NTFS partition, however, you can effectively block some directories in a shared directory tree from access while allowing access to other directories, by setting permissions on the various directories. For example, in the preceding figure, you could share the Applications directory but set permissions to allow users to access all the directories under Applications except dBASE®.

When you share a directory, you assign it a sharename, a name that network users will use to refer to the shared directory. Users of Windows will see the share name when using File Manager to browse the network, and users of MS-DOS can see the share name with the net view command. A share name can be the same as the actual directory name, but it doesn't have to be.

Users see the share name appended to the computer name of the server. For example, if you share a directory on the server Production, and give the directory the share name Data, users will see the share as PRODUCTION\DATA.

A shared directory is often referred to simply as a share.

You can share multiple directories on the same directory tree, if you want. In this case one shared directory might be accessible to users in two different ways - as one of the directories that is actually shared, and as a subdirectory of another shared directory.


How Users Make Connections
Managing Network Files	4 of 15

Sharing Files with Network Users

How Users Make Connections

Network users generally make connections to shared directories by assigning a drive letter on their computer to the shared directory. Then they use the assigned drive letter to refer to the directory to which they have made the connection. For example, suppose a user makes a connection to the Applications directory in the following figure, assigning the drive letter F to the directory. The user then sees the contents of the Applications directory on the server as the contents of his or her own F drive. The subdirectory TOOLS is F:\TOOLS to the user.

Users of Windows NT, Windows for Workgroups, and Windows 3.1 use File Manager to make network connections, using a dialog box similar to the following (dialog boxes may vary according to the system used).

Once a Windows user has made a connection to a directory, the drive letter assigned to that directory and an icon appear in the drive bar of File Manager.

Users of MS-DOS computers with LAN Manager client software (but without Windows) use the net use command to make network connections. The following command connects the user's drive letter F to the TOOLS directory on the server named PRODUCTION.

net use f: \\production\tools

Users of MS-DOS computers (both with and without Windows 3.1 or Windows for Workgroups) have further restrictions on how they view and access shared directories, as described in the following section.


Considerations for MSDOS Users
Managing Network Files	5 of 15

Sharing Files with Network Users

Considerations for MS-DOS Users

When you assign share names to shared directories, first determine whether the directory will be accessed by users of MS-DOS (including users of Windows 3.1 and Windows for Workgroups). If so, you should assign a share name that follows the MS-DOS convention of 8.3 names, where the name can have up to 8 characters, optionally followed by a period and up to 3 more characters. MS-DOS computer users will not be able to access shares with share names that do not follow this convention.

If a share is going to be accessed only by Windows NT users, you can use a different style of share name. Share names can include up to 12 characters.

On NTFS and FAT volumes, you can give files and directories names of up to 255 characters. However, you don't have to worry whether these names will be seen by MS-DOS users. Windows NT provides name mapping, where each file or directory that has a name that doesn't conform to the MS-DOS 8.3 standards is automatically given a second name that does conform. MS-DOS users accessing the file or directory over the network see the 8.3 version of the name, but Windows NT users continue to see the actual long name. Keep in mind that Windows NT creates short names only for files and directories with long names. Windows NT does not generate short names for share names that do not conform to MS-DOS naming standards.

Windows NT name mapping also allows applications that do not support long filenames to access files with such names. These applications refer to files with long names by their shorter names.

Note

If an application that does not support long filenames opens a file with a long name and then saves the file, the long name is lost, and only the short name remains.

When you create a long name, Windows NT uses the following rules to create the short name:

Spaces are removed.

Characters not allowed in MS-DOS - style names are changed to underscores (_).

The name is truncated to its first six remaining characters (or all the characters before the first period in the long name, if the first period is in the first six characters). A tilde and a digit are then added to these six characters. The digit for the first short name created for a set of six characters is 1. If more names using these six characters are created, the next short name uses a 2 instead of a 1, and so on. If a tenth name is created, then only five characters from the long name are used, and 10 is appended after the tilde.

If the long name has any periods followed by another character, the last of those periods and the first 3 characters following that period are used as the filename extension of the short name. For example, VERY.IMPORTANT.MEMOS is shortened to VERY~1.MEM.

If you are using Windows NT Server in an environment where long filenames are not always supported, you may want to continue using MS-DOS conventions for the first six characters of names and use periods only to separate the name from the extension. For example, you could name a file AUGSAL~August 1992 Sales Report.XLS. Then the short name would be AUGSAL~1.XLS.


Using Permissions to Keep Shared Directories Secure
Managing Network Files	6 of 15

Sharing Files with Network Users

Using Permissions to Keep Shared Directories Secure

You can set permissions on your shared directories to maintain security, ensuring that only authorized users can access each file or directory, and that those users can access them only in appropriate ways.

Permissions work differently on NTFS volumes than they do on FAT and HPFS volumes. Security is much more powerful on NTFS volumes. You can set permissions differently for each file and directory, and these permissions apply to users working at the server itself, in addition to users accessing the directory over the network.

On FAT and HPFS volumes, you grant only one set of permissions for each share, and that one set of permissions must apply to all files and subdirectories of the shared directory. Also, on FAT and HPFS volumes, the permissions you set on a share do not apply to users working at the server itself.

Differences in File Systems

Ability		NTFS	FAT and HPFS
Can you set permissions individually on each file and directory?		Yes	No
Do permissions apply to local users?		Yes	No
Can you set share permissions on shared directories?		Yes	Yes
Note

By default, only Administrators, Server Operators, Account Operators, Print Operators, and Backup Operators can log on locally at a server. Therefore, files on a server's FAT and HPFS volumes are protected from local access by users who are not members of these groups because they cannot log on at the server.

How File Permissions Work on NTFS Volumes

Windows NT offers a set of standard permissions you can set on files and directories in NTFS volumes. These standard permissions offer useful combinations of specific types of access, which are called individual permissions.

The standard permissions for directories and files and their meanings are shown in the following tables, along with what individual permissions each standard permission represents. In the first column of the first table (for directory permissions), the first set of individual permissions applies to individual permissions for the directory itself, and the second set of individual permissions applies to new files subsequently created in the directory.

Standard Permissions for NTFS Directories and Files

Permissions	Meaning
Directory:
No Access (None) (None)	User cannot access the directory in any way, even if the user is a member of a group that has been granted access to the directory.
List (RX) (Not Specified)	User can only list the files and subdirectories in this directory and change to a subdirectory of this directory. User cannot access new files created in this directory.
Read (RX) (RX)	User can read the contents of files in this directory and run applications in the directory.
Add (WX) (Not Specified)	User can add files to the directory but cannot read the contents of current files or change them.
Add & Read (RWX) (RX)	User can add files to the directory and read current files but cannot change files.
Change (RWXD) (RWXD)	User can read and add files and change the contents of current files.
Full Control (All) (All)	User can read and change files, add new ones, change permissions for the directory and its files, and take ownership of the directory and its files.
File:
No Access	User cannot access the file in any way, even if the user is a member of a group that has been granted access to the file.
Read (RX)	User can read the contents of the file and run it if it is an application.
Change (RWXD)	User can read, modify, and delete the file.
Full Control (All)	User can read, modify, delete, set permissions for, and take ownership of the file.
The individual permissions and their abbreviations are:

Read (R)	Write (W)	Execute (X)
Delete (D)	Change Permissions (P)	Take Ownership (O)
If you want, you can specify individual permissions directly when setting permissions on a file or directory, rather than use only the standard permissions. However, you will probably need to do so rarely (if ever).

To work effectively with NTFS security, keep the following in mind:

You do not have to assign No Access to every user or group that you want to prevent from accessing a file or directory. You can prevent a user from accessing a file or directory just by not granting the user (or any groups the user is a member of) any permissions for it.

Permissions are cumulative. For example, if the Coworkers group has Add permission for a file while the Finance group has Read permission and Jane is a member of both groups, Jane has Add and Read permissions.

The exception is the No Access permission, which overrides all other permissions. You can use the No Access permission to grant a group access to a file while preventing access to a subgroup or individual who is a member of that group. For example, suppose Jane is a member of Coworkers and Coworkers has the Change permission for a file. If you then set the No Access permission for Jane for the file, Jane will be unable to use the file even though she is a member of a group that can access the file.

By default, new files and new subdirectories inherit permissions from the directory in which they are created. For example, if you add a file to a directory where the Coworkers group has Change permission and the Finance group has Read permission, those same permissions will apply to the file.

When you change the permissions on an existing directory, you have the choice of whether to apply the changes to all files and subdirectories in the directory.

The user who creates a file or directory is the owner of that file or directory. The owner can always control access to the file or directory by changing the permissions set on it. For more information on file ownership, see "How File Ownership Works," later in this chapter.

Share Permissions on Shared NTFS Directories

Before you share a directory on an NTFS volume, you should set permissions on the directory and its files and subdirectories.

When you actually share the directory, you also have the opportunity to set Share permissions. Share permissions operate in addition to the individual file and directory permissions. Share permissions serve as a maximum set of permissions for any file or subdirectory of the shared directory.

For example, suppose you grant JohnLo Full Control for both the APPLICATIONS directory and its subdirectory TOOLS. Then you share the directory, and in the Share permissions grant JohnLo the Read Files/Directories permission. Then, when JohnLo accesses the directory over the network, he can only read it. The restrictions set by the share permissions prevent JohnLo from having full control, despite the Full Control permissions granted to JohnLo for the directories themselves.

In the preceding example, if JohnLo can log on at the server itself, he will have Full Control for the two directories. The share permissions apply only when users access the share over the network.

To simplify administration, you can just set the share permissions to Full Control of Files/Directories whenever you share an NTFS directory (assuming that you have carefully set permissions on individual files and directories on the server). By setting the share permissions to Full Control, you effectively let the permissions set for individual directories and files serve as the means of security for these directories and files.

When you share FAT and HPFS directories, however, share permissions provide you with a valuable means of control.

Granting Permissions

When you grant permissions for files and directories on a server running Windows NT Server, you can grant permissions to the following:

Local groups, global groups, and individual users in the domain containing the server

Global groups and individual users in domains that this domain trusts

The special identities Everyone, SYSTEM, NETWORK, INTERACTIVE, and CREATOR OWNER

You can grant permissions to both the domain's built-in local groups (such as Administrators and Domain Users) and to any groups that you create in the domain.

Everyone represents all current and future users of the network, including guests and users from other domains. You can assign Everyone permissions for both directories and files.

SYSTEM represents the operating system of the local computer. SYSTEM is initially granted permissions for several system directories when Windows NT is installed, and you should not revoke these permissions. You usually do not have to grant permissions to SYSTEM for any file or directories you create, unless a system service needs to access them.

NETWORK represents all current and future users accessing this file or directory over the network. INTERACTIVE is the opposite - it represents any user who accesses the file or directory while working at the server itself. For example, while CristalW accesses a file over the network (while working at her own workstation), she has any permissions assigned to NETWORK, but not those assigned to INTERACTIVE. If CristalW moves to the server and accesses the file from there, she then has permissions assigned to INTERACTIVE but not those assigned to NETWORK.

You can assign CREATOR OWNER permissions only for directories. CREATOR OWNER represents users who subsequently create files and directories in the current directory. If you grant CREATOR OWNER permissions for a directory, anyone who creates a file or subdirectory there will be automatically granted the permissions you gave to CREATOR OWNER for that file or subdirectory.

Strategies for Using NTFS File Permissions

It is recommended that you grant permissions only to groups, not individual users. Granting permissions only to groups makes the server easier to maintain. If several users need access to a certain set of files, you can put them into a group and then give permissions just to the group. Then, if another user needs the same type of access, you can just add the user to the group, instead of giving the user access to each file individually.

Similarly, it is often a good idea to create local groups and assign permissions to them, rather than assigning permissions directly to global groups. For example, if there are files that managers from all groups in your company should see, you should create an All Managers local group in your domain and assign permissions to it. This way, if more files are made available to your company's managers, you need only grant permissions for them to the All Managers group, saving you from having to grant permissions to the many global groups that All Managers contains.

For more information on the strategies of using groups and users, see Chapter 3, "How Network Security Works."

When you create and share a file or directory on a server, grant Full Control to the Administrators local group. That way, all administrators of that domain can change permissions for and otherwise administer the file or directory in the future.


Default Directory Permissions
Managing Network Files	7 of 15

Sharing Files with Network Users

Default Directory Permissions

When a new subdirectory or file is created on an NTFS volume, you can set permissions on it. If you do not set permissions, the new subdirectory or file inherits the permissions of the directory containing it. The following tables list the permissions set by default on directories on both Windows NT Server and Windows NT Workstation.

Default Directory Permissions on Windows NT Server

Default Directory Permissions on Windows NT Server (continued)

Default Directory Permissions on Windows NT Workstation

Default Directory Permissions on Windows NT Workstation (continued)

In addition to these permissions, the special identity SYSTEM, representing the operating system, has Full Control permission for all these directories.

Caution

You should not revoke any of these default permissions on these directories. If you do so, parts of the operating system may not work. Furthermore, you should not use File Manager to examine the permissions on the SYSTEM32\REPL\IMPORT directory, or else the special permissions initially set there will be lost. These initial permissions enable directory replication to work, and you do not need to change them. For more information on directory replication, see "Directory Replication," later in this chapter.

How Permissions Work on FAT and HPFS Volumes

On FAT and HPFS volumes, you cannot assign permissions individually to files and directories. The only time you can restrict access to a FAT or HPFS directory is by setting share permissions when you share it, and then the restrictions apply only to users accessing it over the network.

When you share a directory, you can grant each group and user one of four types of permissions for the share: Full Control of Files/Directories, Change Files/Directories, Read Files/Directories, or No Access to Files/Directories.

For example, if you share a directory that will contain information about the Engineering group's plans for next year, you might grant the Engineer Managers group Full Control to the share, the Engineers group Read permission, and grant no permissions to anyone else on the network.

You do not need to assign No Access to every user you want to exclude from a share. You can prevent a user from accessing a share just by not granting the user (or any groups the user if a member of) any permissions for the share.

The No Access permission is useful when you want to exclude certain individuals or groups from having access to a directory, when those individuals or groups would otherwise have access to the directory through other permissions you have assigned. For example, you can give all network users except the members of Accountants access to a share by granting Everyone Full Control and Accountants No Access.


Using Auditing to Keep Users Accountable
Managing Network Files	8 of 15

Sharing Files with Network Users

Using Auditing to Keep Users Accountable

By auditing files and directories on a server, you can track their usage. You can identify who took various types of actions with the files and directories and hold those users accountable for their actions.

When you audit a file or directory, an entry is written to the Windows NT security log whenever the file or directory is accessed in a certain way. You determine which files and directories to audit, whose actions to audit, and exactly what types of actions are audited.

You can audit successful and failed attempts of the following types of directory and file access:

Types of directory access		Types of file access
Displaying names of files in the directory Displaying directory attributes Changing directory attributes Creating subdirectories and files Going to the directory's subdirectories Displaying the directory's owner and permissions Deleting the directory Changing directory permissions Changing directory ownership		Displaying the file's data Displaying file attributes Displaying the file's owner and permissions Changing the file Changing file attributes Running the file Deleting the file Changing the file's permissions Changing the file's ownership
To set auditing on a file or directory, use File Manager. To view audit entries, use the Event Viewer.


How File Ownership Works
Managing Network Files	9 of 15

Sharing Files with Network Users

How File Ownership Works

Every file and directory on an NTFS volume has an owner. The owner controls how permissions are set on the file or directory, and can grant permissions to others. File ownership provides a way for users to keep private files on the server private, even from the server's administrators.

When a file or directory is created, the person creating the file or directory automatically becomes its owner. It is expected that administrators will create most files on network servers, such as when they install applications on the server. Therefore, most files on a server will be owned by administrators, except for data files created by users and files in users' home directories.

Ownership can be transferred in the following two ways:

The current owner can grant the Take Ownership permission to other users, in which case those users can take ownership at any time.

An administrator can take ownership of any file on the computer. This is useful, for example, if an employee leaves the company suddenly and the administrator needs to take control of the employee's files.

Although an administrator can take ownership, the administrator cannot then transfer ownership to others. This way, if an administrator wrongly takes ownership of someone's files, that administrator cannot subsequently transfer ownership back to the original owner. When the original owner discovers that he or she is no longer the owner of the files, he or she can check the current ownership of the files and discover who took ownership of them.


Directory Replication
Managing Network Files	10 of 15

Directory Replication

With the Replicator service of Windows NT Server, you can set up and maintain identical directory trees on multiple servers and workstations. 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, while import computers can run either Windows NT Server or Windows NT Workstation.

By providing identical copies of files or applications among many computers, you can spread some of the resource usage of file sharing among many computers. If you have many users who need to periodically access a file, you can prevent any one server from becoming overburdened by replicating the file to several computers instead of providing only one source. Then you can give different groups of users access to the file from different computers.

You can replicate directories between computers in different domains, if you want.

File replication is also essential if you use logon scripts in a domain with more than one Windows NT Server.

The following sections provide an overview of directory replication. For detailed instructions on setting up directory replication, see Chapter 15, "Server Manager," of the Windows NT Server System Guide.


How Directory Replication Works
Managing Network Files	11 of 15

Directory Replication

How Directory Replication Works

To use directory replication, you first create a special user account. Internally, this user account initiates and drives the replication process.

You then place the directories you want to be replicated into the export directory on the export server. All direct subdirectories under the export directory can be replicated to other computers. For each of these directories, you can also choose whether you want their subdirectories to be replicated as well.

You can also choose whether to have the export server send changes out as soon as a file has changed, or to wait until the entire export tree has been stable for two minutes before exporting, to prevent the exporting of partially changed trees.

In addition, you can lock a particular subdirectory of the export directory, when needed. Changes to the locked subdirectory are not exported 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.

On each of the import computers, you simply designate which export servers they are to replicate directories from.

If you want, you can set up a server to replicate a directory tree to itself (from its export directory to its import directory). This 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.


Replicating Logon Scripts
Managing Network Files	12 of 15

Directory Replication

Replicating Logon Scripts

If you use logon scripts in a domain that has at least one backup domain controller (in addition to the primary domain controller), you should replicate the logon scripts among the domain controllers. All domain controllers authorize logon requests, and the logon script for a user must be located on the server that approves the user's logon request. By replicating logon scripts among the primary and backup domain controllers, you ensure that logon scripts are always available to users, yet you still need to maintain only one copy of each script.

To provide for the replication of logon scripts, Windows NT Server creates a SCRIPTS subdirectory under both the default import and export directories used for replication. If you replicate logon scripts, you must be sure to use Server Manager to change each server's logon script path to systemroot\SYSTEM32\REPL \IMPORT\SCRIPTS or systemroot\SYSTEM32 \REPL\EXPORT\SCRIPTS, as appropriate. For more information, see Chapter 15, "Server Manager," of the Windows NT Server System Guide.

The export server for the logon scripts can be, but doesn't have to be, the primary domain controller.


File Sharing Examples
Managing Network Files	13 of 15

File Sharing Examples

This section includes examples showing how to apply the concepts discussed in this chapter.


Setting Up File Permissions
Managing Network Files	14 of 15

File Sharing Examples

Setting Up File Permissions

Suppose you need to set file permissions on a server used by a small department. The file server includes an applications directory, home directories for each of the department's users, a public directory where users can share files, and a drop directory where users are to be able to file confidential reports that only the group manager can read.

In the applications directory, make all executable programs read-only to all users, to prevent viruses and Trojan horses. You can also grant the individual Change Permissions (P) permission to Administrators, so that an administrator can give himself or herself Write permission when it is time to update an application. Giving Administrators the Write permission initially provides less virus protection than giving them the Change Permissions permission and forcing them to change permissions before updating the application.

If none of your applications need to write any files (such as initialization setting files) in their own directories, you should also make all the directories containing applications read-only.

For the home directories, give each user Full Control over his or her own directory, and don't give anyone permissions for any other directory.

For the public directory, you can give all users Change permission, which lets them read and write to the directory. Change is more appropriate than Full Control, because Full Control would also allow users to set permissions for the public directory and take ownership of it.

To create a drop directory, just grant Users or Everyone the Add permission for the directory, and give the Change permission to the manager who is to read the files in the directory.

Don't give anyone except Administrators or Server Operators access to any files or subdirectories under the WINNT directory.


Setting Up Replication of Multiple Directory Trees
Managing Network Files	15 of 15

File Sharing Examples

Setting Up Replication of Multiple Directory Trees

You have a domain where you want to replicate two directory trees: one for logon scripts, and one for other data. The groups of computers that need to import the two trees are different: only the four domain servers need the logon scripts, while only two of the domain servers, along with two Windows NT Workstation computers, need to import the other data.

The best solution is to set up different servers as the export servers of the scripts directory tree and the data directory tree.

Remember that a single export server has only one list of import computers to which it replicates. If you set up only a single export server for the two directories, it will export both directory trees to all import computers, even though not all import computers use both directory trees.


Sharing Printers
Chapter 6	1 of 25

Sharing Printers

This chapter offers guidelines for setting up and sharing printers on a Windows NT network. While printer setup itself is easy, it's worth taking time to understand the various options available for configuring printers. By carefully planning printer access, you can maximize use of each printer and at the same time avoid long printing delays.


Overview of Windows NT Printing
Sharing Printers	2 of 25

Overview of Windows NT Printing

A Windows NT network offers several advanced printing features:

You can browse the network for available Windows printers and connect to a printer by double-clicking a printer name. The browsing function is available from Print Manager and, even more conveniently, from within the Print Setup dialog of Windows NT applications.

You do not have to install printer driver files on a local Windows NT computer to use a remote Windows NT printer. If all printing clients are Windows NT-based, it is only necessary to install printer driver files in one place - at the print server.

You can browse the network for printers managed by other providers. For example, you can browse the network for LAN Manager 2.x print servers and connect to print shares on these servers. In this case, Windows NT prompts you to install the appropriate printer driver locally if it is not already present.

You can remotely administer Windows NT print servers, printers, print jobs, and printer drivers.


Planning Your Printing Operations
Sharing Printers	3 of 25

Planning Your Printing Operations

Because every network user has occasion to print, it is worth making sure network print operations are efficient and cost-effective. Choices you need to make include:

What printers to use

What computers to use as print servers

How to configure shared printers for maximum use


What Printers to Use
Sharing Printers	4 of 25

Planning Your Printing Operations

What Printers to Use

Today's choice of printers includes devices specifically designed for network use. These printers offer options such as automatic port and emulation switching, dual paper bins, and double-sided printing. Before deciding on network printers, carefully evaluate your printing needs:

Do you need a few high-volume printers or several less expensive personal printers?

High-volume printers generally have more features but affect many more users if they break down.

How many pages do you expect to print?

You'll probably experience fewer maintenance problems if you match printing volume with a printer's duty cycle (the number of pages it can print per month).

What graphics support do you need?

The combination of Windows NT and TrueType® technology makes it possible to print sophisticated graphics and fonts on most printers, even those that normally only support bitmaps and text. TrueType is integrated with the operating environment, so all Windows NT applications can use TrueType fonts without changes or upgrades. If you intend to print many graphs, charts, or halftone photographs, consider a printer that supports 300 dots per inch (dpi) or greater.

How important is printing speed?

Whereas printers have traditionally attached to the network through serial or parallel ports on computers, newer printers connect directly to the network using built-in LAN cards. Network links offer faster throughput than currently available parallel and serial buses. However, print throughput rates also depend on network traffic and the type of printer used.

Windows NT supports most traditional printers, including dot matrix, inkjet, and laser printers. It also supports Hewlett-Packard network-interface printers, such as the Hewlett-Packard LaserJet IIIsi.


Choosing Computers to Be Print Servers
Sharing Printers	5 of 25

Planning Your Printing Operations

Choosing Computers to Be Print Servers

On a network of any size, you'll probably concentrate printer installation at a few select servers. A computer acting as a print server might simultaneously act as a file server or database server. No special hardware requirements exist for print servers except that they have the right output ports if you're using parallel or serial printers.

Twelve MB of RAM is adequate for x86-based print servers controlling a small number of print devices. Managing a large number of printers requires more memory. Disk space requirements are minimal except in cases where print jobs are likely to accumulate.

Combining File and Print Services

When you use Windows NT for both file and print sharing, file operations have first priority - printing transactions never slow access to files. Likewise, file operations have negligible impact on printers attached directly to the server; parallel and serial ports are always the greater bottleneck. A dedicated print server may only be necessary if the server is to manage many heavily used printers.

The decision to combine print and file servers may depend on security concerns. While printers should always be available to those persons using them, you may want to lock up a file server.


Planning How Users Access Printers
Sharing Printers	6 of 25

Planning Your Printing Operations

Planning How Users Access Printers

Before installing printers on a server, you need to be aware of configuration options that can improve the flexibility and efficiency of network printing. After studying these options, you'll be ready to use Print Manager to install and configure printers.

To take advantage of various print configurations, you first need to understand the distinction between a printing device, which you connect to your computer or to the network, and a logical printer you create using the Windows NT Print Manager. A printing device is mechanical hardware that actually prints, such as a Hewlett-Packard LaserJet. The printer you create using Print Manager is a software interface between the operating system and the printing device. It defines where the document will go before it reaches the printing 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. When users connect to printers, they are connecting to logical printer names that represent one or more printing devices.

By associating logical printers and printing devices in different ways, you can offer users flexibility in their printing operations. Several configurations are possible, as shown in the following diagrams.

Single Printer to Single Printing Device

Multiple Printers to Single Printing Device

Single Printer to Multiple Printing Devices

The ability to assign more than one logical printer to a printing device gives users flexibility in printing documents. For example, two logical printers associated with a single printing device may offer different print properties: one may print separator pages and the other may not. Or, one logical printer could hold jobs and print them at night, while the other processes jobs 24 hours a day.

Print flexibility and efficiency can also be improved by means of various print configurations; the rest of this section discusses this topic.

Postponing Print Jobs

A good way to maximize use of printing devices is to stagger printing times. To do this, use Print Manager to define the time during which a printer can print jobs. When you specify printing times, the print spooler accepts jobs at any time, but it doesn't print to the target printing device until the designated start time. At the stop printing time, the spooler stops sending jobs to the printing device and saves any jobs remaining until start-printing time. If printer traffic is heavy during the day, you can postpone printing of less important jobs by routing them through a printer that prints only during off-hours.

Giving Printers Different Priority Levels

There may be times when you need to print a document immediately and want to bypass the jobs waiting for a printing device. You can do this by creating printers with different priority levels. (Print priority is set in the Details dialog box within Print Manager.) If two logical printers are associated with a single printing device, jobs routed to the printer with the highest priority level (lowest number) print first.

To take advantage of this print priority system, create multiple printers that lead to one printing device. Assign each printer a priority level, and then create a group of users that correspond to each printer. For example, users in Group1 might have access rights to a priority 1 printer, users in Group2 might have access rights to a printer with priority 2, and so on. In this way, you can prioritize print jobs according to the users submitting their jobs.

Using a Printing Pool

A printing pool consists of two or more similar printing devices associated with one logical printer. To set up a pool, you create a printer using Print Manager and assign it as many output ports as you have identical printing devices. (Windows NT places no limit on the number of printers in a pool.) Whichever printing device is idle receives the next print job. This configuration maximizes use of printing devices while minimizing the amount of time users must wait for print jobs.

Printer pools have the following characteristics:

All devices in the pool share the same print model and act as a single unit. All print property settings apply to the whole pool.

Printer ports can be of the same type or mixed (serial, parallel, and network).

When a job arrives for the printer pool, the spooler checks printer output destinations to see which device is idle. The first port installed gets checked first, the second port second, and so on. If your pool consists of a different type of ports, make sure you select the fastest port first (network, then parallel, then serial).

If one device within a pool stops printing - when it runs out of paper, for example - it will hold a single print job at that device. Other jobs continue to print to the other devices in the pool while the delayed job waits until the nonfunctioning device is fixed.

It's impossible to predict which printer in a pool will receive a particular job. However, if the Windows NT Messenger Service is active, a workstation will get messages indicating when print jobs are complete and identifying the printer by output port. Unless you want users to rely on these messages, it's a good idea to place pooled printers in a single location.

A particularly efficient printer configuration is one in which a printing device is accessible both in and outside of a printing pool, as shown in the following figure. This configuration provides both the fast throughput of a printing pool and the flexibility of more than one logical printer.


Attaching Printers to Your Network
Sharing Printers	7 of 25

Attaching Printers to Your Network

After deciding how you want users to share network printers, you're ready to attach your printing devices to the network. Shared printers may connect to the serial or parallel ports on a computer, or directly to the network, if they have a built-in network adapter card.


Configuring Parallel and Serial Printers
Sharing Printers	8 of 25

Attaching Printers to Your Network

Configuring Parallel and Serial Printers

Printers attach to computers through parallel or serial port connections. Printers connected with parallel cables must be less than 20 feet from the server; serial cables can be up to 100 feet. Standard IBM-compatible computers support three parallel ports and two serial ports. RISC-based computers generally come with one parallel and two serial ports built in and support as many additional ports as there is space for.

Configuring parallel ports may require setting hardware jumpers or switches. Serial communication requires handshaking, which defines a method for the printer to tell Windows NT that its buffer is full. Serial ports can be configured for No Handshaking, XON/XOFF, Software Handshaking, or Hardware Handshaking by choosing the Ports icon in the Windows NT Control Panel. Printer documentation should tell you what communications settings to use. Usually, the setting is 9600 baud, No parity, 8 bits, 1 stop bit, and Hardware Handshaking.

If you are using a serial printer, use the cable that originated with the device. Wiring schemes often vary from cable to cable.

Setting Hardware Interrupt Levels

The number of printers and other devices you can attach to a computer is dependent on the number of interface card slots, addresses, and interrupt request (IRQ) lines available. For example, although Windows NT supports an unlimited number of serial and parallel ports, finding an available IRQ level can be difficult, since AT®-bus computers have a limited number of IRQs. The standard devices COM1, COM2, LPT1, and LPT2 are assigned the following IRQs:

COM1 = IRQ4

COM2 = IRQ3

LPT1 = IRQ7

LPT2 = IRQ5

On RISC-based systems LPT1, COM1, and COM2 are built-in and don't conflict with IRQ levels on the EISA (Extended Industry Standard Architecture) bus. This frees IRQs 3, 4, and 7 for other devices.

Some interface cards support sharing of interrupts. This means two device addresses can use the same IRQ level. However, some devices require exclusive use of certain interrupts. To avoid conflicts, check hardware manuals for these devices before configuring your ports. To see current IRQ settings on your computer, run the Microsoft Diagnostics program (systemroot\SYSTEM32\WINMSD.EXE). For more information on IRQ settings, see "Troubleshooting" in the Windows NT Server Installation Guide.


Configuring Network-Interface Printers
Sharing Printers	9 of 25

Attaching Printers to Your Network

Configuring Network-Interface Printers

Unlike parallel and serial devices, printers with built-in network adapter cards do not have to be adjacent to the print server. Where you locate these types of printers has no effect on printing performance, assuming users and printers aren't on opposite sides of a network bridge. A Windows NT print server can control an unlimited number of Hewlett-Packard network-interface printers. To maintain high server throughput levels, increase memory as you add printers.

Network-interface printers are attached to the network through a built-in adapter card. To use an HP network-interface printer, such as the HP LaserJet IIIsi, you need to install the Data Link Control protocol (included with Windows NT). You can do this during Setup or later, using the Network icon in the Control Panel.

After connecting a network-interface printer, run a self-test to obtain the network card address. When you install the printer on the server, you'll end up choosing this card address from a list of available printer addresses. For instructions on how to set up a network-interface printer, see Chapter 6, "Print Manager," in the Windows NT Server System Guide.


Creating Printers on a Server
Sharing Printers	10 of 25

Creating Printers on a Server

After physically connecting printing devices, you need to install them on a computer. To do this, you create printers on the intended print server using the Windows NT Print Manager. To create printers on remote Windows NT computers, use the Server Viewer option in Print Manager to focus on the computer on which you want to create the printers. To create a printer, you must be logged on as a member of the Administrators, Server Operators, or Print Operators group.

When you create a printer you assign the printer certain characteristics or properties. For example, you can specify that a printer print only at certain times or that it generate a separator page. How you set properties may depend on how you want users to access printing devices (see "Planning How Users Access Printers," earlier in this chapter).

Regardless of print configuration plans, when you create a printer, you must set the following properties:

Printer name

Printer driver

Print destination

After you set these properties, you'll be prompted to set device-specific properties (fonts, printer memory, color, and so forth). If you don't change a specific property, Windows NT prints using default settings.

You also need to share the printer to make it available to network users. Default settings for other print properties usually suffice for printing to occur.

As soon as you share a printer, it appears in the Print Manager network-wide printer list. Users can choose Windows NT printers from this list by selecting Connect To Printer within Print Manager. Or from the Options menu in a Windows NT application, they can choose Printer Setup and then select the Networks button.

Users can also connect to Windows NT printers by creating a local printer and then redirecting the local port within Print Manager. This requires, however, that a local printer driver be installed at the user's workstation.


Installing Printer Drivers
Sharing Printers	11 of 25

Creating Printers on a Server

Installing Printer Drivers

A printer driver is a program that converts graphics commands into a specific printer language, such as PostScript® or PCL®. Printer drivers also contain important information that Windows NT needs to know about your printer, such as details about printer hardware, including descriptions of fonts and paper sizes.

Windows NT supplies drivers for most available print devices. When you select a printer driver name, Print Manager prompts you for driver location (this can be a path name or a floppy drive). To install a driver that is not supplied with Windows NT, select Other from the Driver list. Windows NT will prompt you for the driver name and location.

RISC and x86-based computers require different printer drivers. To use a printer created on an x86-based Windows NT computer, a RISC-based client requires the appropriate RISC printer driver for that printer. The driver may be installed locally or on the x86-based server. Likewise, x86-based clients can only use a RISC-based print server, if the requisite x86 drivers are installed locally or on the server.

If your network contains a mixture of RISC and x86-based computers, you may want to install both types of drivers on your print servers. This ensures that print jobs originating from either type of computing environment can use all printing devices. For example, if your print server is an x86-based computer, install the appropriate driver for your printing device from the driver list. Then, choose Other from the driver list, and install the comparable RISC driver for the same device. Print Manager determines whether incoming print requests are RISC or x86-based and automatically uses the appropriate driver if it is present.

If a particular driver is not supported, try setting up the printer according to this table:

If it is a		Set it up as a
Laser printer:
HPPCL (LaserJet) compatible		Hewlett-Packard LaserJet Plus
PostScript compatible		QMS®-ColorScript
Color PostScript		Apple® LaserWriter® Plus
35-font Plus font set or superset
Dot matrix printer:
9-pin dot matrix
IBM compatible		IBM Proprinter™
Epson® compatible		Epson FX-80 for narrow, or FX-100 for wide carriage
24-pin dot matrix
IBM 24-pin compatible		IBM Proprinter X24
Epson LQ compatible		Epson LQ-1500
Other:
		Contact the manufacturer to see if custom drivers are available
For information about obtaining new printer drivers for your system, contact your hardware manufacturer or Microsoft Product Support Services.


Choosing a Print Destination
Sharing Printers	12 of 25

Creating Printers on a Server

Choosing a Print Destination

When you create a printer, you must tell Print Manager where you want it to print. A printer can print to one or more of the following destination types: a local output port, a file, a remote print share name, or a network printer address. If you configure a printer to print to more than one destination, you are creating a printer pool.

The following print destinations appear as options in Print Manager:

LPT1 through LPT3 represent parallel ports.

COM1 through COM4 represent serial ports. You can set up more serial ports using the Ports option in the Control Panel.

FILE enables you to print directly to a file. This option is not advisable for network printers because the filename prompt will appear on the server rather than at the user workstation.

Network Printer offers the following choices:

Local port is a port not previously installed.

Hewlett-Packard Network Port gives you the option of selecting a Hewlett-Packard network printer address. This selection appears only if the Data Link Control protocol is installed.


Using Separator Pages
Sharing Printers	13 of 25

Creating Printers on a Server

Using Separator Pages

You can set up a printer so that one or more separator pages print at the beginning of each job. Separator pages typically state who submitted the job and give the date and time of printing.

You can select a separator page file through the Printer Details option of the Printer Properties dialog box (in Print Manager). Enter the name of the Separator Page file directly, or browse through the directories and select a file. The file may be one of four separator pages included with Windows NT or a custom separator page file you create.

The following table shows the names of separator files supplied with Windows NT, the purpose of each, the type of printer with which each is compatible, and whether or not the file can be edited. By default, separator page files are kept in the systemroot\SYSTEM32 directory.

Filename		Purpose		Compatible with	Can be edited?
SYSPRINT.SEP		Prints a page before each document		PostScript	Yes
PSLANMAN.SEP		Prints a page before each document		PostScript	Yes
PCL.SEP		Switches printer to PCL printing		PCL	Yes
PSCRIPT.SEP		Switches printer to PostScript printing		PostScript	Yes
To create your own separator page, you can modify and rename one of the supplied separator files. The following table shows the escape codes you can include in a separator page file. Windows NT replaces these escape codes with appropriate data, to be sent directly to the printer.

Escape codes always start with an escape character and end with a letter or number. The first line of your custom separator page must contain only the escape character (assume @ is the first character in the file, the escape character).

Escape code	Function
@N	Prints the user name of the person that submitted the job.
@I	Prints the job number.
@D	Prints the date the job was printed. The representation of the date is the same as the Date Format in the International section in Control Panel.
@T	Prints the time the job was printed. The representation of the time is the same as the Time Format in the International section in Control Panel.
@Lxxxx	Prints all the characters (xxxx) following it until another escape code is encountered.
@Fpathname	Prints the contents of the file specified by path name, starting on an empty line. The contents of this file are copied directly to the printer without any 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; the maximum width is 256. Any printable characters beyond this width will be truncated.
@U	Turns off block character printing.
@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 printing to the next line.
@B@M	Prints text in double-width block characters until @U is encountered.


Setting Device-Specific Properties
Sharing Printers	14 of 25

Creating Printers on a Server

Setting Device-Specific Properties

Device-specific printer properties describe the physical configuration of a printing device - how many plotter pens it has, how much memory, and so forth. These properties vary from device to device. When you create a printer, use Print Manager to make sure device-specific properties match the settings of the printing device. While default settings work for many printing needs, many special printing options, such as those available with PostScript printer drivers, require setting changes.

It's easy to confuse printer-specific settings with job properties. Job properties do not rely on a device's physical settings. If an application does not set a job property, such as page orientation or paper size, the printing device defaults to the job properties set in the Job Defaults menu in Print Manager. Application settings always override job defaults set within Print Manager. The following lists show typical job and printer-specific properties.

Device-specific properties:		Job properties:
Color		# of copies
Resolution		Page orientation
Memory		Two-sided printing
Font cartridge name		Collate copies
Form location		Form
Plotter pen
Setting Printer Memory

If you are using a page printer, such as a laser printer, it's important to make sure that the amount of memory available in the device matches the value shown in the Printer Memory box. (This device-specific setting appears in the Printer Properties dialog box after you install a printer driver.) Because they need to store an entire page in memory, page printers require relatively large amounts of memory.

If the printer has substantially more or less memory than what is shown in the Printer Memory box, print throughput may suffer. For example, Windows NT may try to download more fonts to the printer than it can reasonably handle. Running a printer self-test usually tells you how much RAM the device contains.

Using Forms

Windows NT maintains a forms database. A form consists of a physical paper size, margins that define the image area, and a name. Users can define new forms and add them to their database. For example, you could create a form called LEGAL2 that uses legal size paper and 2-inch margins.

If a printing device has a legal-size form in the upper tray and letter-size form in the bottom tray, you must set printer properties accordingly. Note that the printer driver automatically indicates the physical sizes of the forms it can accept - it does not offer you the option of specifying forms that the printer driver is not capable of processing.

A user picks which form to use in a particular document through application software. Windows NT applications allow users to print different portions of a document on different forms.

Choosing Font Types

Fonts are collections of characters and symbols that have a specific design and resolution. There are three types of fonts that are used by printing devices:

Device fonts are fonts that actually reside in the hardware of your printer. They can be built into the printer itself or can be provided by a font cartridge or font card.

Screen fonts are Windows NT fonts that can be translated for output to the printer. These include TrueType fonts. To install screen fonts, use the Fonts option in Control Panel.

Downloadable soft fonts are fonts you install in the same location in which you install a printer driver. Thus, when Windows NT computers use printers installed on a remote Windows NT print server, soft fonts only need to be present at the print server. An MS-DOS -based computer that redirects an output port to use the same printer should install soft fonts (and a printer driver) locally. On Windows NT computers, use Print Manager to install soft fonts.

Not all devices can use all three types of printer fonts. Pen plotters, for example, cannot normally use downloadable soft fonts or print raster screen fonts.

For each document, Windows NT downloads required screen and soft fonts to the printing device. You can improve printing times by using device fonts, which are already present at the printer.

Windows NT includes three types of screen fonts that may be reproduced on printers:

TrueType fonts are device-independent fonts that can be reproduced on all printing devices. TrueType fonts are stored as outlines and may be scaled and rotated. To be reproduced on a printing device, fonts only need to be present on the computer originating a print job.

Raster fonts are stored as bitmaps and are device-dependent. If a printer doesn't support the font, it won't print it. Raster fonts cannot be scaled or rotated.

Vector fonts are useful for devices such as plotters that cannot reproduce bitmaps. They may be scaled to any size or aspect ratio.

The greatest benefit of TrueType in a networking environment is its portability; documents with TrueType fonts are independent of any one printing device, application, or system.


Making Network Printers Available
Sharing Printers	15 of 25

Creating Printers on a Server

Making Network Printers Available

To share printers with network computers, you check a box in the Print Manager interface. Print Manager automatically gives your printer a share name, which is a name for workstations that do not recognize long print (and file) names supported by Windows NT. Windows NT computers do not use share names to identify printers - they use printer names (which may be up to 32 characters).

If you are sharing printers with MS-DOS computers, share names must be no more than eight characters, optionally followed by a period and one to three characters. When you share a printer, Print Manager automatically truncates the printer name to form a share name that is compatible with MS-DOS computers.


Controlling Printer Access
Sharing Printers	16 of 25

Controlling Printer Access

You can control printer usage under Windows NT by setting permissions for each printer.

By default, all shared printers you create are available to all network users. Restricting access to a printer requires altering the printer's permission settings for a particular group or user. To change permissions on a printer, you must be the owner of the printer or have been granted Full Control permission. Settings are accessible by choosing Permissions within the Security menu of Print Manager.

Four types of permissions apply to network printers:

No Access

Print

Manage Documents (permission to manage all jobs aimed at that printer)

Full Control

Permissions are cumulative except that the No Access permission overrides all other permissions.

To allow the following uses of a printer, grant the permission shown.

To create a printer on a server, you must be logged on as a member of the Administrators, Server Operators, or Print Operators group. (If the server is not a primary or backup domain controller, you must be logged on as a member of the Administrators or Power Users group.)

By default, Administrators, Print Operators, and Server Operators have Full Control rights on a server; Administrators and Power Users have Full Control rights on a workstations. All users can manage their own documents.


Managing Printers and Print Jobs
Sharing Printers	17 of 25

Managing Printers and Print Jobs

All direct management of printers takes place through Print Manager. This includes:

Viewing a list of printers and their respective print jobs.

Purging jobs waiting for a printer.

Holding or releasing a print job.

Restarting a print job from the beginning.

Deleting a print job.

Stopping a job that is currently printing.

Pausing and continuing a printer.

Deleting a printer.

You can manage a local or remote print server from any workstation on the network, as long as you have Full Control rights at that print server.

When you select a print server from the Server Viewer window, Print Manager displays the status of all the printers managed by that computer, the documents spooled to each printer, and the progress of all documents currently printing. You can monitor several print servers and printers simultaneously.

Any network user can check on the status of a remote printer by connecting to it. However, only users who have Full Control or Manage Documents permission for a printer may manage print jobs other than their own.


Printing from Other Types of Computers
Sharing Printers	18 of 25

Printing from Other Types of Computers

Network computers running MS-DOS or versions of Windows for MS-DOS can access Windows NT printers by redirecting their output ports to the appropriate \\server\sharename. However, unlike Windows NT Workstation computers, these types of client computers must have a printer driver installed locally. (See the example "Setting Up MS-DOS Computers for Network Printing," at the end of this chapter.)

Fonts and forms available on a Windows NT print server are not accessible by non-Windows NT client computers.


Using Printers Managed by Other Providers
Sharing Printers	19 of 25

Using Printers Managed by Other Providers

Your network may include other types of print servers, such as LAN Manager 2.x or Novell NetWare servers. These servers and the printers they control appear when you browse the network using the Connect To Printer menu in Print Manager. However, because Windows NT computers cannot use the printer drivers on non-native servers, when you connect to this type of printer, Print Manager prompts you to create a local printer and install a local driver. You can configure the new local printer just as you would any other printer you create.

You must be a member of the Administrators or Power Users group to connect to printers managed by other providers.


How Printing Works
Sharing Printers	20 of 25

How Printing Works

This section describes exactly what happens when you print from a Windows NT computer to a printing device. The process can vary with the type of application you are running and whether you are printing locally or remotely.

By supporting a large number of printers, fonts, and graphics commands, Windows NT minimizes exposure to the mechanics of printing. At the same time, it leaves the printing process accessible-you can modify it for special applications.


Printing from a Windows NT-Based Application
Sharing Printers	21 of 25

How Printing Works

Printing from a Windows NT-Based Application

When you instruct a Windows NT-based application to print to a remote printer, you initiate the following sequence of events:

1.	First, the appropriate printer driver is temporarily copied from the print server across the network to the user workstation. This enables the software application to query the driver for current printer settings (resolution, color fonts, and so on). The application communicates with the printer driver through the graphics engine.

2.	Next, the application generates a description of the requested output using graphics device interface (GDI) commands. These commands specify everything Windows NT needs to know about the content and formatting of your document, but they do not tell your printer how to print the document.

3.	Next, the Windows NT graphics engine translates these GDI calls into device driver (DDI) calls, which are translated by the printer driver into printer language and spooled to the print server. From now on the spooler located on the print server manages the document.

(Note that for local printing, printer driver translation may take place after the job is spooled to the local disk drive.)

4.	When the destination printer is ready, the spooler releases the document to the print processor, which checks for a compatible data type and passes it back to the spooler.

5.	The spooler then passes the job to the monitor, which writes the data to the appropriate print destination (LPT1, COM1, \\server\sharename, and so on).

6.	The printer receives the information and produces printed output.

The rest of this section describes these steps in more detail.

Rendering Graphics

When you initiate the printing process, your application creates a list of graphical device calls that describe your document. The graphics engine takes these calls and converts them into DDI calls. In order to correctly interpret the document, the application must ask the appropriate printer driver for setup information, such as printer resolution and available fonts. This information is available because Windows NT temporarily copies the driver over the network into your workstation memory. This occurs when you choose a new printer or make a change to device-specific settings. Some WYSIWYG (what you see is what you get) applications, such as Microsoft Word for Windows, request the printer driver at application startup.

For remote printing, these DDI calls are then rendered by the printer driver and spooled as raw files to the print server. (Raw files contain printer-specific commands.) In the case of local printing, rendering can happen later in the printing process if the application is capable of spooling a journal file. Journal files are records of DDI calls and do not contain printer-specific commands.

Managing Print Requests

The spooler oversees the printing process. Every Windows NT computer has an identical spooler process running in background mode. During the printing process, the spooler on the client workstation passes the document to the spooler on the print server. This spooler coordinates and schedules all print jobs arriving at the server. It also links together all the components of the printing process.

Once it has spooled a print job, the spooler checks to see if the destination printer is busy. When the device is ready, the spooler passes the file on to the print processor if the following conditions are true:

The print device is functioning properly and is not paused.

The device is capable of printing the job (correct plotter pens, paper, and so on).

The print and job schedule times allow printing.

There are no other jobs with a higher priority.

Print Processing

Prior to printing, all documents must pass through a print processor. The Windows NT print processor is a program that interprets the command format (data type) of a document. Based on the data type, the print processor decides what further processing is required. The print processor also supplies a means of modifying the printing process.

The default Windows NT print processor supports two data types, journal and raw. As discussed earlier, journal files contain DDI calls, while Raw files contain printer specific commands.

The Windows NT print processor is implemented as a dynamic-link library (DLL). As written, the print processor's job is to interpret compatible data types. Its real significance, however, lies in the access it provides to the printing process. You can modify the printing process by substituting a custom program in place of the Windows NT default print processor. This program could be used to filter data, to create a special dialog with the printer device, or to interpret a new data type.

Rendering for a Specific Device

How a device driver handles a print job depends on the type of printing device. The following scenarios are possible:

If the output device is a raster printer, the graphics engine sends the printer driver a series of DDI commands to generate a bitmap. If the printer doesn't have enough memory to accommodate the bitmap, the driver performs banding, a process whereby the document is replayed several times to generate the full image.

If the target device is a PostScript printer, the graphics engine sends DDI commands, which are translated by the PostScript driver into printer commands. All rendering is done by the printer CPU.

If a plotter is the output device, the graphics engine transmits commands, which the printer driver uses to create a line drawing.

Managing Output Destinations

A monitor program is responsible for writing the print job to an output destination such as a local port or another file. Windows NT has three monitor programs. One monitor writes to local ports, one writes to remote print shares, files, and named pipes, and one writes to network addresses used by Hewlett-Packard network-interface printers.

If the destination is a port (LPT1, COM1), the monitor opens the port, writes the data, and then closes the port. For serial ports, it sets the baud rate, parity, and so forth.


Printing from Windows 3.1 and MSDOS – Based Applications
Sharing Printers	22 of 25

How Printing Works

Printing from Windows 3.1 and MS-DOS – Based Applications

Windows 3.1-based applications running on a Windows NT platform print in the same way as Windows NT-based applications. These applications use Windows NT printer drivers.

If an MS-DOS application running under Windows NT generates graphics, they must be rendered by the application itself, using an MS-DOS printer driver. The appropriate printer driver must be located on the local Windows NT computer. Output is sent to the print server by redirecting parallel ports to a network address.

The process is as follows:

1.	An MS-DOS application creates a document using a local printer driver.

2.	The document is passed to the print server.

3.	When the printer is ready, the spooler passes the document to the print processor.

4.	The print processor checks the data type and passes the document to the spooler.

5.	The spooler passes the job to the monitor, which writes the data to the output port (or other destination).

6.	The printer processes the data and produces output.


Print Setup Examples
Sharing Printers	23 of 25

Print Setup Examples

This section includes examples showing how to apply the concepts discussed in this chapter.


Setting Up a Pool of Network-Interface Printers
Sharing Printers	24 of 25

Print Setup Examples

Setting Up a Pool of Network-Interface Printers

A company wants you to set up 12 HP IIIsi network-interface print devices under the control of one print server. The printers will be shared among employees working on one floor of an office building.

To prevent employees from having to take long walks, choose four locations at which to place printers. Place three printers at each location. Locate the print server wherever it's convenient. (Remember that you can administer the server remotely.) If the computer is a dedicated x86-based printer server, 12 MB of RAM is adequate.

Use the Network icon in the Control Panel to install the Data Link Control protocol on your print server. Install network interface cards in each of the printers, and then run a printer self-test to identify the network card addresses.

Using Print Manager, create printers on your print server as follows:

1.	Create a printer name for each of the four groups (for example, LaserWest, LaserEast, LaserSouth, LaserNorth).

2.	Select the appropriate printer driver for each Printer Name. One printer might use a PostScript driver; another might use a PCL driver.

3.	In the print destination box, select Hewlett-Packard Network Port. In the dialog box that appears, type in a short name for the port, and choose one address from the list of network print addresses. Repeat this process 12 times, until you've installed all 12 HP printer ports. Then you can assign three ports each to LaserWest, LaserEast. and so forth. To assign more than one port, select Details, and then Print To Additional Ports.

4.	Modify the printer-specific properties to reflect the physical setup of each group of devices.

When a user selects LaserNorth, output may show up on any of three printing devices on the north side of the floor. Since the printers are identical, each group uses the same print model. However, if preferred, you could configure LaserNorth to use legal paper, LaserSouth to print only at night, and so on.


Setting Up MSDOS Computers for Network Printing
Sharing Printers	25 of 25

Print Setup Examples

Setting Up MS-DOS Computers for Network Printing

A company has recently installed a Windows NT network. Network computers include clients running MS-DOS and versions of Windows for MS-DOS. These computers need to access a laser printer managed by a Windows NT print server.

On each MS-DOS computer, install the MS-DOS printer driver file for the laser printer. You need to make this driver accessible to each application you use on the computer. This may mean copying it into each application directory. At the MS-DOS prompt, redirect a free parallel port to the printer share name on the Windows NT print server (net use lpt1: \\server\sharename).

For all MS-DOS – based Windows computers: use the Printers icon in the Windows Control Panel to install the correct printer driver and associate it with a free parallel port. Then, connect the printer to the appropriate Windows NT print server and share name. You only need to do this once for all Windows applications.


Managing Fault Tolerance and UPS
Chapter 7	1 of 23

Managing Fault Tolerance and UPS

Fault tolerance is the ability of a system to continue functioning when part of the system 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 systems use redundant disk controllers and power supplies as well as fault-tolerant disk subsystems. You can also use uninterruptible power supplies (UPSs) to safeguard against local power failure.

Although the data is always available and current in a fault-tolerant system, you still need to make tape backups to protect the information on your disk subsystem against catastrophic disasters such as fire, earthquakes, tornadoes, floods, and user errors. Disk fault tolerance is not an alternative to a backup strategy with offsite storage.


Understanding RAID
Managing Fault Tolerance and UPS	2 of 23

Understanding RAID

Fault-tolerant disk systems are standardized and categorized in six levels known as Redundant Arrays of Inexpensive Disks (RAID) level 0 through level 5. Each level offers various mixes of performance, reliability, and cost.

The RAID levels are somewhat loosely defined, and details on performance or disk utilization vary from one configuration to the next. Depending on the implementation, definitions may overlap or be combined. For example, in some hardware implementations, you can use levels 0 and 1 (striping and mirroring) together to provide the ultimate in redundancy and performance, if cost is no concern.

The major difference between RAID and earlier, more expensive large-disk technologies (also called single large expensive disks, or SLED) is that RAID combines multiple disks with lower individual reliability ratings to reduce the total cost of storage. The lower reliability of each disk is offset by the redundancy.

Be aware that there is no fault tolerance until the fault is repaired. Few RAID implementations can withstand two failures simultaneously. When the failed disk is replaced, the data can be regenerated using the redundant information. (See the "Disk Administrator" chapter in the Windows NT Server System Guide for more information on fixing mirror sets and stripe sets with parity.) When this operation is complete, all data is current and again protected against disk failure. This occurs without bringing in backup tapes or performing manual update operations to cover transactions that took place since the last backup. The ability to provide cost-effective high data availability is the key advantage of disk arrays.


Level 0
Managing Fault Tolerance and UPS	3 of 23

Understanding RAID

Level 0

This strategy is commonly known as disk striping and uses a disk file system called a stripe set. Data is divided into blocks and spread in a fixed order among all the disks in the array. This strategy is similar to level 5, which also has data redundancy.

Disk striping in Windows NT writes data to multiple partitions, as is done with volume sets, but striping writes files across all disks, so that data is added to all partitions in the set at the same rate.

Disk striping offers the best performance of all the Windows NT Server disk management strategies, including volume sets. However, like volume sets, it does not provide fault tolerance. If any partition in the set fails, all data is lost.

(See the "Disk Administrator" chapter in the Windows NT Workstation System Guide or the Windows NT Server System Guide for information on creating and deleting stripe sets. See also the discussion on hardware reliability in "Understanding Reliability Issues," later in this chapter.)

RAID Level 0


Level 1
Managing Fault Tolerance and UPS	4 of 23

Understanding RAID

Level 1

This strategy is commonly known as disk mirroring and uses a disk file system called a mirror set. Disk mirroring provides an identical twin for a selected disk; all data written to the primary disk is written to the twin or mirror disk. This results in disk space utilization of only 50 percent. If one disk fails, the system uses data from the other disk (with the exception of the boot sectors). (For a discussion of how to deal with startup failures, see "Fixing a Startup Failure," later in this chapter.)

Of the two Windows NT Server fault-tolerance strategies, disk mirroring has better overall read and write performance than stripe sets with parity. Another advantage of mirroring over stripe sets with parity is that there is no loss in performance when a member of a mirror set fails. Disk mirroring is more expensive, in terms of dollars per megabyte, because its disk space utilization is less. But its entry cost is lower because it requires only two disks, whereas stripe sets with parity require three or more. Disk mirroring is best suited to peer-to-peer and modest server-based LANs.

(See the "Disk Administrator" chapter in the Windows NT Server System Guide for information on creating and deleting mirror sets. See also the discussion of hardware reliability in "Understanding Reliability Issues," later in this chapter.)

RAID Level 1


Level 2
Managing Fault Tolerance and UPS	5 of 23

Understanding RAID

Level 2

This method adds redundancy by using an error-correcting code. It employs a disk striping strategy that breaks a file into bytes and spreads it across multiple disks. The error-correction method used is rather ponderous and requires several disks to store the error-correction information. This strategy offers only a marginal improvement in disk utilization over level 1. This was an improvement, historically speaking, over mirroring, but compares poorly with current technology.


Level 3
Managing Fault Tolerance and UPS	6 of 23

Understanding RAID

Level 3

This strategy is similar to level 2 in that it employs the same striping method. The level 3 error-correction method requires only one disk for parity data. The disk space utilization varies with the number of data disks and may be as high as 86 percent. This strategy is best for applications that have access to a small number of large files.


Level 4
Managing Fault Tolerance and UPS	7 of 23

Understanding RAID

Level 4

This strategy employs striping data in much larger blocks or segments than levels 2 and 3. It still keeps all the error-correction data on a single disk and separate from the user data. Again, utilization varies with the number of disks in the array.


Level 5
Managing Fault Tolerance and UPS	8 of 23

Understanding RAID

Level 5

This strategy is commonly known as striping with parity. This is the most popular strategy for new designs. It is similar to level 4 in that it stripes the data in large blocks across all the disks in the array. It differs in that it writes the parity across all the disks. The data redundancy is provided by the parity information. The data and parity information are arranged on the disk array so that the two are always on different disks.

Stripe sets with parity have better read performance than mirroring. However, when a member is missing, such as when a disk has failed, the read performance is degraded by the need to recover the data with the parity information.

Nevertheless, this strategy is recommended over mirroring for applications that require redundancy and are primarily read-oriented. Write performance is reduced by the parity calculation. Also, a write operation requires three times as much memory as a read operation during normal operation and, when a partition fails, reading requires at least three times the memory as would normally be used, both caused by parity calculation.

Note

The use of Windows NT Server stripe sets with parity requires more system memory than using mirror sets. The recommended minimum RAM is 12 MB; 16 MB or greater is preferred.

(See the "Disk Administrator" chapter in the Windows NT Server System Guide for more information on creating and deleting stripe sets with parity. See also the discussion of hardware reliability in "Understanding Reliability Issues," later in this chapter.)

RAID Level 5 Configuration


Planning a Fault-Tolerant System
Managing Fault Tolerance and UPS	9 of 23

Planning a Fault-Tolerant System

As previously mentioned, you may implement RAID fault tolerance in either hardware or software. Windows NT Server offers three of the RAID strategies in a software solution. In a hardware solution, the controller interface handles the creation and regeneration of redundant information. In Windows NT Server, this activity is performed in the software.


Using Hardware Solutions
Managing Fault Tolerance and UPS	10 of 23

Planning a Fault-Tolerant System

Using Hardware Solutions

Disk arrays are a popular disk-storage solution for high-performance LAN servers. Disk arrays consist of multiple disk mechanisms coordinated by a controller. Individual data files are typically written to more than one disk in a manner that, depending on the RAID level used, may improve performance and/or reliability.

A hardware implementation of the RAID level can offer performance advantages over use of the Windows NT Server RAID strategies. You can achieve RAID level 5 data protection through hardware solutions, such as disk array adapters, that do not use any system software resource, such as the Windows NT Server fault-tolerance solutions. This improves data throughput significantly. The key to this performance edge is the use of more disks at a given capacity than a conventional storage solution. If you use multiple controllers in an intelligent approach, reading and writing performance can be improved significantly over a SLED.

Hardware implementations of the RAID strategies can provide very good performance, depending on the configuration. You may even be able to replace a failed drive without shutting down the system. The disadvantages of a hardware implementation are that they can be very expensive and may lock you into a single-vendor solution.


Using the Windows NT Software Solution
Managing Fault Tolerance and UPS	11 of 23

Planning a Fault-Tolerant System

Using the Windows NT Software Solution

The Windows NT Server operating system implements several of the RAID strategies with any vendor's disk or interface hardware. The Windows NT Server disk-systems strategies include:

Stripe sets (RAID level 0).

Mirror sets (RAID level 1).

Stripe sets with parity (RAID level 5).

In Windows NT Server, stripe sets provide the best performance but provide no fault tolerance (that is, data redundancy).

When compared to stripe sets with parity, a mirror-set implementation has a lower entry cost, requires less system memory, provides the best overall performance, and does not show performance degradation during a failure. However, its cost-per-megabyte is higher than that for stripe sets with parity.

A stripe-set-with-parity implementation has better read performance and a lower cost-per-megabyte, but it requires more system memory and loses its performance advantage while a member is missing.


Understanding Reliability Issues
Managing Fault Tolerance and UPS	12 of 23

Planning a Fault-Tolerant System

Understanding Reliability Issues

Notice that adding disks as a volume set or stripe set reduces the disk subsystem's reliability because there is no information redundancy. If any of the disks in the set fail, all data in the set is lost. Hardware reliability is the same for mirror sets and striping with parity, but these strategies offer reliable information redundancy.

The chance that a disk might fail is typically described by a statistical unit called mean time between failures (MTBF), measured in hours. The probability of a hardware failure in a disk subsystem is calculated as follows:

MTBFset = MTBFdisk/N

where MTBFset is the MTBF of the set, MTBFdisk is the MTBF rating of any individual disk in the array (assuming they are identical), and N is the number of disks in the set.

For example, a set containing four disks has one-fourth the mean time between failures when compared to a single disk or, in other words, it is four times more likely to fail in any given period of time. This is considered a weakness that could be significant in systems that place a high priority on the availability of current data. This also increases the importance of a good backup strategy.


Understanding Windows NT Parity Usage
Managing Fault Tolerance and UPS	13 of 23

Planning a Fault-Tolerant System

Understanding Windows NT Parity Usage

The data redundancy method used in Windows NT Server for striping with parity is a function of the Boolean operation called exclusive OR, also referred to as XOR. The important concept to remember about parity is that regeneration uses the parity information in conjunction with the data on the good disks to recreate the data on the failed disk. The Windows NT Server stripe-sets-with-parity form of fault tolerance maintains an XOR of the total data. This enables the reconstruction of missing data (on a failed disk or sector) from the remaining disks in the stripe set with parity.


Sparing Bad Disk Sectors
Managing Fault Tolerance and UPS	14 of 23

Sparing Bad Disk Sectors

The file system verifies all sectors when it formats a volume. All faulty sectors are spared from service. Additional Windows NT Server fault-tolerance services add sector-recovery capabilities to the system.

When there is a sector I/O failure in a fault-tolerant system with redundant copies of the data, the Windows NT Server Fault Tolerance driver attempts to spare the bad sector from use. This includes performing a device control asking the disk device driver to spare the sector from use. Small Computer System Interface (SCSI) devices can do this, but AT devices (that is, Integrated Device Electronics [IDE] and Enhanced Small Device Interface [ESDI]) cannot. When the sector cannot be spared, the correct information obtained from the redundant copy is returned to the file system with a status message stating that there is a faulty sector in the I/O. The Windows NT file system (NTFS) reacts to this message by attempting to locate the failure and sparing the bad sectors by removing their usage from the sector map of the file system. The administrator is also notified in the Event Viewer program of the potential for data loss if the partition containing the redundant copy also fails.


Fixing a Startup Failure
Managing Fault Tolerance and UPS	15 of 23

Fixing a Startup Failure

If the boot partition of a disk fails, the system will not start. The process used to recover from a startup failure depends on the disk configuration and the computer system's microprocessor type. If the boot partition on the disk is not part of a mirror set, the system-backup copies should be restored to the replacement disk.

For a boot partition configured as part of a mirror set, which is the only fault-tolerance method that can be applied to the boot or system partition, the recovery procedure depends on whether the computer is x86-based or RISC-based. Both use a floppy disk for boot protection, and both use Advanced RISC Computing (ARC) names to describe the boot process. Notice that you should create and test such a fault-tolerant boot floppy disk in advance of any failure or you will not be able to boot off the mirror if the primary boot partition is lost.


Understanding ARC Names
Managing Fault Tolerance and UPS	16 of 23

Fixing a Startup Failure

Understanding ARC Names

To set up the boot information for recovery in the Windows NT environment, you must understand ARC names and how they are constructed. ARC names are a generic method of identifying devices within the ARC environment. For disk devices, ARC names are constructed as follows:

<component>(x)disk(y)rdisk(z)partition(a)

where <component> identifies the hardware adapter for the device. The two valid values for this field are scsi and multi, where scsi indicates a SCSI disk and multi indicates a disk interface other than SCSI. For Windows NT, this could be a disk supported by the AtDisk driver or one supported by AbiosDsk.

x is the ordinal number of the adapter. For example, if there are two SCSI adapters in the system, the first to load and initialize is assigned the ordinal 0 and the next number assigned is 1. This continues for all adapter drivers that initialize.

y is, for scsi, the SCSI bus number for multiple-bus SCSI adapters. For multi, this is always 0.

z is, for scsi, always 0. For multi, this is the ordinal for the disk on the adapter.

a is the partition ordinal for the partition used on the disk. All partitions receive a number, except type 5 (MS-DOS Extended) and type 0 (unused) partitions.

For example, if the Windows NT tree is located on the fourth partition on a SCSI disk with the target ID of 3 on the second SCSI controller in the system, the ARC name is:

scsi(1)disk(3)rdisk(0)partition(4)


Recovering a Mirrored Boot Partition
Managing Fault Tolerance and UPS	17 of 23

Fixing a Startup Failure

Recovering a Mirrored Boot Partition

The boot environment differs between x86-based and RISC-based systems; therefore, the methods used for recovering the boot partition also differ.

Recovering on x86-based Systems

For x86-based systems, there is a BOOT.INI file located on the partition used by the system BIOS as the boot partition. This file contains a menu selection and the ARC-name location for the Windows NT boot tree. In this case, the ARC names are constructed in the same manner as they are for a RISC-based system.

For example, if the system contains one Adaptec™ SCSI adapter and two Future Domain SCSI adapters and the boot partition is located on the second Future Domain adapter, the ARC names are as follows:

scsi(0)disk()rdisk()partition() is the basis for the Adaptec SCSI devices. scsi(1)disk()rdisk()partition() is the basis for the first Future Domain adapter. scsi(2)disk()rdisk()partition() is the basis for the second Future Domain adapter.

In the case of a Windows NT Server mirror for the boot tree, a boot floppy disk is created by formatting a floppy disk using the Windows NT operating system and copying the following files to the disk:

NTLDR

NTDETECT.COM

NTBOOTDD.SYS (required only if the boot partition is on a SCSI disk; this file is the SCSI miniport driver used to find the mirror disk)

BOOT.INI (with an alternate path pointing to the mirrored copy of the system partition, specified using ARC naming conventions)

Recovering on RISC-based Systems

RISC-based systems that conform to the ARC environment maintain the equivalent information for the operating system loader in nonvolatile RAM. So the process for creating a "boot disk" for RISC systems using the Microsoft firmware is to copy the following files to the Windows NT-formatted blank floppy disk:

OSLOADER.EXE

HAL.DLL

The Microsoft firmware provides for boot maintenance operations by means of menu selections. To set up a boot selection for the boot disk, set the OSLOADER value to multi(0)disk(0)fdisk(0)\OSLOADER.EXE and the SYSTEMPARTITION value to multi(0)disk(0)fdisk(0). The value for fdisk(x) could be changed to 1 to use the second floppy in the system. If the floppy used in the ARC system is a SCSI-based floppy, change multi to scsi and follow the previously described ARC-name rules for the SCSI target ID. You also need to set appropriate values for the following selections:

OSLOADPARTITION, which is the ARC name that specifies the secondary mirrored partition

OSLOADFILENAME, which is the path to the \systemroot directory for Windows NT (for example, \WINNT35 or \WINDOWS) on the secondary mirrored partition

After the Windows NT Loader program has finished loading Windows NT and the configured drivers, the fault-tolerant services are present and can perform the remaining corrective actions for starting the system. Notice, however, that RISC-based systems can only access SCSI devices connected to the built-in SCSI adapter during the firmware boot process. Therefore, to protect the boot or system partition on a RISC-based system, both drives used must be connected to the internal SCSI adapter.

Testing Your Newly Created Boot Disk

After creating your fault-tolerant boot floppy disk, you can perform the following simple test to reassure yourself that it will work when needed.

1.	Insert the fault-tolerant boot floppy disk and restart the computer.

2.	If your boot selection correctly specifies the alternate ARC path to the secondary mirrored partition, your system should begin to boot and then fail with the following STOP message:

***STOP: 0x0000006B (0xC000000D, 0x00000002, 0x00000000, 0x00000000)PROCESS1_INITIALIZATION_FAILED

If your system fails for any other reason, then your fault-tolerant boot floppy disk will not help you to recover the boot partition in the event of a disk failure.

3.	On x86-based computers, you should then check the following items:

The selection in the BOOT.INI file must specify the correct ARC path to the secondary mirrored partition.

If the mirrored partition is on a SCSI disk, the NTBOOTDD.SYS file must correspond to the controller to which that disk is connected.

NTLDR and NTDETECT.COM must be present on the floppy disk.

4.	On RISC-based computers, you should then check the following items:

OSLOADFILENAME must specify the correct ARC path to the secondary mirrored partition.

OSLOADPARTITION must specify the correct ARC path to the OSLOADER.EXE file on the floppy disk.

SYSTEMPARTITION must specify the correct ARC path to the floppy disk.

OSLOADER.EXE and HAL.DLL must be present on the floppy disk.

Using Your Boot Disk

When a member of a mirrored set is orphaned, you must first break the mirror-set relationship to expose the remaining secondary partition as a separate volume. When the disk that fails is the system or boot partition, you need to do the following steps to recover Disk 0 by using the information on Disk 1:

1.	Use the Windows NT Server fault-tolerant boot floppy disk (with a BOOT.INI file specifying the ARC path pointing to Disk 1) to boot the remaining secondary partition.

2.	Open Disk Administrator, select the mirror set partition, and break the mirror.

3.	Re-establish the mirror for that partition between Disk 0 and Disk 1.

4.	Exit Disk Administrator.

Disk Administrator will force the system to reboot when needed.

5.	Boot the repaired Disk 0 using the fault-tolerant boot floppy disk to boot from Disk 1.

The mirror on Disk 1 will rebuild the files on Disk 0.

6.	Open Disk Administrator, select the two disks and break the mirror.

7.	Modify the drive-letter assignments to have the C drive on Disk 0 and the D drive on Disk 1, and then mark the C drive on Disk 0 as active.

This will enable you to avoid having to change the SCSI numbers for the disks.

8.	Exit Disk Administrator.

9.	Remove the fault-tolerant boot floppy disk and then reboot from Disk 0.

Note

This procedure works best when the disk geometry (that is, the number of heads, cylinders, and sectors per track) of the drives used for the primary and secondary partitions is the same, and the drives are of the same brand and model.

Maintaining Your Boot Disk

You should update the boot disk every time partitions are changed. For example, if you are using partition 2 to boot and you delete partition 1, you must change the ARC name to boot using partition 1. Likewise, if you are booting on partition 2 and you delete partition 1 and repartition it into partitions 1 and 2, you must change the ARC name to boot using partition 3.


Managing Uninterruptible Power Supplies
Managing Fault Tolerance and UPS	18 of 23

Managing Uninterruptible Power Supplies

An uninterruptible power supply (UPS) provides power when the local power fails. It is usually rated to provide a specific amount of power for a specific period of time. This power comes from batteries that are kept charged while main power is available. The main power is converted from an AC voltage to a DC voltage used to charge the battery. When needed, the DC power is converted to an AC voltage compatible with the computer power supply. Usually, all that is needed from a UPS is time to shut down the system in an orderly fashion by terminating processes and closing sessions.


Understanding UPS Types
Managing Fault Tolerance and UPS	19 of 23

Managing Uninterruptible Power Supplies

Understanding UPS Types

Uninterruptible power supplies fall into two categories: online and standby.

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.

Configuration of an Online UPS

A standby UPS 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. The UPS power supply is kept in standby (that is, ready to provide power but using very little), and the battery is kept charged. 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. This should occur so quickly that the computer power supply is able to provide uninterrupted service. A standby UPS may also provide power conditioning during regular service if it is built into the main power path, but it is not a function of the conversion process of the UPS power supply.

Configuration of a Standby UPS

Hybrid versions of these two types may also exist. Check the reliability and failure-handling mechanism of the UPS device before buying one or installing it.


Understanding How a UPS Interacts with Operating Systems
Managing Fault Tolerance and UPS	20 of 23

Managing Uninterruptible Power Supplies

Understanding How a UPS Interacts with Operating Systems

Many UPS devices offer the ability to interface with operating systems, enabling the operating system to notify users automatically of the pending shutdown process or provide notification that the power has been restored and a shutdown is no longer necessary.

During a power failure, the UPS service immediately pauses the Server service to prevent any new connections and sends a message to notify users of the power failure. The UPS service then waits a specified interval of time before notifying users to terminate their sessions. If power is restored during the interval, another message is sent to inform users that power has been restored and normal operations have resumed.


Understanding How the Windows NT UPS Service Works
Managing Fault Tolerance and UPS	21 of 23

Managing Uninterruptible Power Supplies

Understanding How the Windows NT UPS Service Works

The Windows NT UPS option in Control Panel enables the UPS service to communicate with a UPS device via a serial port with the following signals:

Signal	Pin	Asserted by
Power Failure	CTS (Clear To Send )	UPS hardware
Low Battery	DCD (Data Carrier Detect)	UPS hardware
UPS Shutdown	DTR (Data Terminal Ready)	Windows NT UPS service
The assertion of each of these pins can be either positive or negative, depending on the UPS device's implementation. Use the UPS dialog box to specify the polarity used by the UPS hardware.

To support contact-closure type UPS devices, the UPS service always does the following:

TXD (Transmit Data) pin 6 is set permanently low.

RTS (Request To Send) pin is set permanently high.

When the UPS service is started, it verifies the settings in the UPS dialog box by assuming that the system is not starting during a power failure and 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 may 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.

When the UPS service starts, it waits until the CTS pin is asserted by the UPS. If you have indicated in the UPS dialog box that your UPS device does not support a Low Battery signal, the UPS service uses the parameters specified in the UPS Characteristics box of the UPS dialog box to estimate the charge level of your battery in terms of minutes. Each time you start the UPS service, the charge level of your battery is reset to 0 minutes. As time elapses, the Battery Recharge parameter is used to estimate the battery life to a maximum time specified by the Expected Battery Life parameter. The UPS service requires at least 2 minutes to perform a graceful shutdown successfully. Therefore, if your battery does not have more than 2 minutes of life remaining, a shutdown is performed immediately. Since it is important that the parameters in the UPS Characteristics box be set accurately, it is best to use worst-case estimates.

When a power failure occurs, the UPS service uses the parameters in the UPS Service box of the UPS dialog box to decide how to respond. For noisy power (that is, power that fluctuates regularly), the first parameter should be set for a few seconds. This minimizes messages being broadcast. The UPS device continually sends messages at an interval specified in the second parameter of the UPS Service box. This parameter should be set very low if you want to ensure that users are aware of the power failure, or set high if it is not important to let users know about the power failure. When the UPS battery is low, the service initiates a shutdown and then turns off the UPS device (if this feature is supported).


Using a UPS with Windows NT
Managing Fault Tolerance and UPS	22 of 23

Managing Uninterruptible Power Supplies

Using a UPS with Windows NT

You should use the following Windows NT services in combination with the UPS device that you select for your computer:

UPS

Alerter

Messenger

EventLog

The following are some basic points to be aware of to ensure that your UPS is installed correctly and to protect your computer from the hazards of a power failure.

A UPS device supplies power to your computer and peripherals (for example, the display monitor and printer) when the main power supply is interrupted or fails completely. Some UPS devices can supply power for only a few minutes, while others can supply power for many hours. In any case, you should interface the UPS device properly to Windows NT so that the UPS can track power fluctuations and take appropriate actions. For example, if a power failure is prolonged, the UPS may not be able to supply power for the entire duration of the failure. In this case, Windows NT warns users of the power failure. When the UPS reaches a critical state, a shutdown of the operating system is performed, and the UPS device is turned off. Therefore, you should ensure that your UPS device guarantees at least 2 minutes to enable the operating system to perform a graceful shutdown.

Select a UPS device that works with Windows NT. This usually means ordering the correct serial cable from the UPS manufacturer. This cable is designed to follow the UPS interfacing specification for Windows NT. If you are upgrading your computer to Windows NT and already have a UPS, check with the manufacturer to ensure that the existing cable works with Windows NT. Unexpected results may occur if the wrong cable is used.

UPS manufacturers may have their own software that can be purchased separately to take advantage of the unique features of their UPS device. In this case, you should not use the UPS service that comes with Windows NT. Follow the instructions that come with the UPS manufacturer's software.

The UPS service is configured using the UPS dialog box. You should base the configuration on the features supported by the UPS device that you are using. The three features that Windows NT supports are:

Main-power failure detection.

Low battery detection.

UPS shutdown capability.

To determine the correct settings, carefully read the user's manual for your UPS device, or contact the manufacturer. Based on the features supported by the UPS, you may have to enter additional parameters in the UPS Characteristics box of the UPS dialog box.

The UPS service can be controlled in several ways. One way is to configure the settings in the UPS dialog box and choose the OK button. A message appears and asks whether or not you want to start the UPS service. Another way to start the service is by using the Services option in Control Panel.

The Alerter and Messenger services must be started manually using the Services option in Control Panel. The Alerter service sends alerts to selected users, and the Messenger service sends messages to your local Windows NT computer and to other users on the network. All detected power fluctuations and power failures are recorded in the event log, along with UPS service start failures and server shutdown initiations.

To ensure that the computer is protected from power failures, 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 there were no errors.


Running a Command File upon UPS Shutdown
Managing Fault Tolerance and UPS	23 of 23

Managing Uninterruptible Power Supplies

Running a Command File upon UPS Shutdown

This section contains updated information for Windows NT version 3.51. Click here to see the new information.

The Windows NT UPS service supports the running of a command file defined by the administrator. You should specify a command file only if your system requires special actions prior to a system shutdown. For example, you may have a custom application running that is connected to another computer. You may use the command file to end the session and log off of the connected computer automatically, prior to system shutdown.

The command file must reside in your \systemroot\SYSTEM32 directory and have one of the following extensions:  .EXE, .COM, .BAT, or .CMD. After you have created the file and placed it in the proper directory, use the UPS dialog box to activate its use upon UPS shutdown. Select the Execute Command File option, type the filename, and choose the OK button.

Note

The command file must finish running in 30 seconds. A run time that is greater than 30 seconds threatens the ability of Windows NT to complete a graceful system shutdown. You should test the operation of the command file under a worst-case scenario.


Backing Up Network Files
Chapter 8	1 of 19

Backing Up Network Files

Regular backup of servers and local hard disks prevents data loss or damage caused by disk drive failures, power outages, virus infection, and many other potential network disasters. If a backup operation is based on careful planning and reliable equipment, file recovery should be relatively painless.

This chapter begins by discussing general strategies for setting up a tape backup system on your network. Concepts that relate specifically to the Windows NT Backup program are described later in the chapter. Additional disaster prevention measures, such as fault tolerance and uninterruptible power supplies (UPS), are covered in Chapter 7, "Managing Fault Tolerance and UPS."


Forming a Network Backup Plan
Backing Up Network Files	2 of 19

Forming a Network Backup Plan

Windows NT includes a tape backup program you can use to protect Windows NT servers and workstations. Whether you use this program or another type of tape backup system, you need to consider the following:

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've designed a backup operation, document both your backup and restore procedures. After your backup system is in place, it's a good idea to practice restoring an entire server, as well as individual files.

Note

Only MS-DOS – based tape backup programs that support the Microsoft tape format can create Windows NT-compatible tapes.


Choosing Hardware
Backing Up Network Files	3 of 19

Forming a Network Backup Plan

Choosing Hardware

The most common medium for backups, and one used by Windows NT Backup, is magnetic tape. Tape is popular because it offers great capacity at low cost. The primary tape drive types used for server backup include quarter-inch cartridge (QIC), digital audio tape (DAT), and 8-mm cassette. High-capacity, high-performance tape drives generally use Small Computer System Interface (SCSI) controllers.

Tape technology changes rapidly, so it's best to research the relative merits of each type of medium before purchasing. When choosing a tape drive, consider reliability, capacity, speed, and drive and media cost. Ideally, a tape drive should have more than enough capacity to back up your largest server. It should also provide error detection and correction during backup and restore.

How Many Tape Drives Do You Need?

The number of drives you need depends on your overall backup strategy. Do you plan to back up your entire network remotely, or do you want each user to be responsible for backing up locally? Since tape cartridges are available in sizes greater than 5 gigabytes, you can probably back up your entire network with a few tapes and a single high-speed drive. However, the recent availability of less expensive tape hardware makes local backups a sound option.

Advantages of local backup include:

Fewer network resources committed to a lengthy backup procedure.

Quicker recovery of files.

One solution is to run centralized backups of file servers and leave workstation backups to individual users.


Where to Put Your Tape Drive
Backing Up Network Files	4 of 19

Forming a Network Backup Plan

Where to Put Your Tape Drive

To run remote backups, you can connect your tape drive to a workstation or to a server. There are advantages and disadvantages to either configuration. If you run backups from a server, you can back up and restore that server very quickly. On the other hand, if your network has more than one server, the speed advantage is lost. Servers normally operate 24 hours a day and are logical candidates to run backups during off hours. However, if there is ever a problem with backup hardware, you may have to power down your server. As a general rule, though, if most of your information is on one server, you're better off running backups from that server.

Whether you run remote backups from a server or a workstation, it makes sense to place a tape drive on the portion of your network with the greatest bandwidth (highest transmission frequency). If your tape drive is expensive, you might also consider placing it in a secured room.


Choosing a Type of Backup
Backing Up Network Files	5 of 19

Forming a Network Backup Plan

Choosing a Type of Backup

The most common types of backup are normal (full), incremental, and differential.

A normal backup always copies all selected files and marks each file 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.

The incremental method only backs up files that were 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 files that were 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.

The following table lists advantages and disadvantages associated with running each type of backup.

Backup type	Advantages		Disadvantages
Normal	Files are easy to find because they are always on a current backup of your system or on one tape or tape set.		Most time-consuming.
Incremental	Recovery requires only one tape or tape set.		If files do not change frequently, backups are redundant.
	Least data storage space required.		Requires large amount of tape space.
	Least time-consuming.		Files difficult to find because they are spread across several tapes.
Differential	Less time-consuming than normal backups.		Recovery takes longer than if files were on single tape.
	Recovery only requires last normal backup tape and last differential tape.		If large amounts of data change daily, backups can be more time consuming than incremental.
Most backup software, including Windows NT Backup, provides a Copy command. Copy is the same as normal backup except that the files copied to tape are not marked as having been backed up. The Copy command is useful when you want to move large numbers of files to another computer. It's also useful for making a tape copy that won't interfere with an ongoing backup schedule. For example, suppose a company runs centralized backups on a regular basis. A company employee working on a very important project might want to make his or her own backups, either as extra protection or for quicker file recovery. Because the Copy command does not mark files as backed up, using it won't invalidate other backup operations.

Caution

Changing the date on your computer can cause a backup program to restore files incorrectly from an incremental backup tape. These programs generally use the date function to determine which version of a file is more current and may mistakenly overwrite a file with an incorrect date. (Windows NT Backup records the last backup date for HPFS and NTFS files.)


Planning a Backup Schedule
Backing Up Network Files	6 of 19

Forming a Network Backup Plan

Planning a Backup Schedule

In planning a backup schedule, you need to address the following questions:

How often to back up

How many tapes to use

When to verify backups

Plan to perform regular backups when the least number of people are using your network. If many files are in use, you risk a backup that inaccurately reflects your network.

How Often to Back Up

How often you back up depends on how often your data changes and how valuable it is to you. Having three separate copies of important data is recommended to protect against tape failure or loss. Backups might consist of a weekly, a monthly, and an archive backup. The archive tape could be a simple copy rather than a full-fledged backup.

Backups are also a protection against virus contamination. Because some viruses take weeks to appear, keep normal backup tapes for a month or more to ensure that you can restore a system to its status prior to when it became infected.

Rotating Tapes

Rotating tapes used during backup is common practice because it lowers the cost of backups. A sample rotation schedule follows. This 12-week schedule uses a different backup tape each day for two weeks and then reuses the first tape at the beginning of each third week. At the end of the 12 weeks, the cycle starts over with a new set of tapes. The life cycle of a tape depends on the manufacturer and on storage conditions.

One of the most popular tape-rotation schedules is one that uses 19 tapes over the course of one year. This schedule, shown next, uses the same four tapes Monday through Thursday for incremental (or differential) backups. Every Friday, normal backups are made to one of three other tapes. The remaining 12 tapes are used for monthly normal backups and are stored off-site.

How Often to Verify Backups

A verify operation ensures reliability by comparing files on disk to files that have been written to tape. You can perform a verify operation after every backup or at strategic backup points. If you are backing up to a set of tapes that will be stored for a long time, it's wise to verify them. Verifying after file recovery is also recommended.

The verify operation occurs after all files are backed up or restored and takes about the same time as the backup procedure itself. If a verify procedure fails for a given file, check to see when that file was last modified. If someone changes a file between a backup and verify operation, the backup will not verify.


Storing Backup Tapes
Backing Up Network Files	7 of 19

Forming a Network Backup Plan

Storing Backup Tapes

You need to find an off-site location to store backup and archive tapes. This can be in a vault or other place that can protect them against fire, water, theft, and other hazards. If you use a fireproof safe, make sure it is specifically designed to protect magnetic media.

Tapes survive best in cool, humidity-controlled locations. Your storage area should also be free of magnetic fields, such as those found near the backs of computer terminals and analog telephones.


Documenting Backup Operations
Backing Up Network Files	8 of 19

Forming a Network Backup Plan

Documenting Backup Operations

Accurate backup records are essential to finding missing information quickly, particularly if you've accumulated large numbers of high-volume tapes. Records can include tape labels, log files, catalogs, and log books.

Tape labels should contain a date, the type of backup (normal, incremental, or differential), and complete information regarding tape contents. Indicating the type of backup is important. If you are restoring from differential or incremental backup tapes, you need to locate the last normal backup tape, and either the last differential tape or all incremental tapes created since the last normal backup. Alternatively, you can label tapes sequentially and keep a log book of tape contents.

As a supplement to tape labeling, most types of backup software include a mechanism for cataloging backup files. Windows NT Backup stores backup catalogs on tape, temporarily loading them into memory during program sessions. It's not possible to print the catalog or save it to disk.

In addition to an online catalog, Windows NT Backup offers the option of logging all operation information to a file. The log file can include the names of all files and directories successfully backed up.


Using Windows NT Backup
Backing Up Network Files	9 of 19

Using Windows NT Backup

Windows NT includes a backup program that offers centralized backup of network hard drives and the ability to restore data in the case of lost files or a corrupt disk drive. Supported tape drives include popular SCSI 4-mm DAT, 8-mm, and quarter-inch devices.

Windows NT Backup also supports:

Backup and recovery of Windows NT files on NTFS, HPFS, or FAT.

Placing multiple backup sets on a tape.

Spanning multiple tapes with both backup sets and files (there is no file-size restriction).

Creating a batch file to automate repeated backups of drives.

To run Windows NT Backup, the backup tape drive must be local to the Windows NT computer running the program, and only one tape drive may be specified at a time.

You can use the Windows NT program to back up Windows NT Server computers, Windows NT Workstation computers, LAN Manager 2.x servers, and any other types of computers to which you can connect remotely. Windows NT Backup recognizes Windows for Workgroups shares but does not recognize MS-DOS or Windows 3.1 workstations. Note also that the Windows NT program cannot back up Registry or event log files over the network.

Prior to running the program, each computer you want to back up must be established as a logical drive (D, E, F, and so on). Typically, you'd incorporate logical drive connections into the batch file you use to run your backups.


Granting Backup and Restore Rights
Backing Up Network Files	10 of 19

Using Windows NT Backup

Granting Backup and Restore Rights

On a Windows NT computer, only administrators and backup operators have default rights to back up files they do not own or have access to (secured files). Other users may only back up files that they can read. Windows NT Backup enables users to restrict access to backup tapes through software. Only an administrator, the creator of the tape, or someone with restore rights may restore a tape that has been restricted. You should not restrict access to a tape if you created it for file-transfer purposes.

While it's possible to grant backup and/or restore rights to regular users, distribution of these rights should be limited to a few individuals who have regular responsibility for backing up your network. Large sites may want to create two groups of backup operators - one with only backup rights, the other with backup and restore rights.

The following table shows default backup and restore rights.

Default Backup and Restore Rights

Task		Administrator	Backup operator	Everyone
Back up secured files		Yes	Yes	Only if user has read access
Restore a tape created with restricted access		Yes	Yes	Only if user created tape


Restoring File Security Settings
Backing Up Network Files	11 of 19

Using Windows NT Backup

Restoring File Security Settings

Windows NT files may have permissions, ownership, and audit flags associated with them. Windows NT Backup preserves this information except when you restore files to an HPFS or FAT partition. It's not possible to secure information on HPFS or FAT file systems.

If you restore files to a new computer, you will probably choose to restore without preserving security settings. In this case, restored files inherit the permissions of the directory in which they are placed. If the directory has no permissions, the file retains its previous permissions, including ownership.


Restoring Configuration Files
Backing Up Network Files	12 of 19

Using Windows NT Backup

Restoring Configuration Files

When you back up a local hard drive, Windows NT Backup gives you the choice of backing up local configuration information. These configuration files, known collectively as the Registry, are located in the systemroot\SYSTEM32\CONFIG directory.

Note

Windows NT Backup does not back up configuration information or event logs located on remote computers.

You should be aware of these steps before you attempt to restore Registry files:

After restoring the Registry, you must reboot your computer, which means you lose any configuration changes made since the last Registry backup.

To restore a Registry onto a new computer (if, for example, your hard drive breaks), you must first reinstall Windows NT on the new computer and then restore a full backup tape of your hard drive.


Files That Are Not Copied
Backing Up Network Files	13 of 19

Using Windows NT Backup

Files That Are Not Copied

Windows NT Backup does not indiscriminately copy and restore all files. Instead, it follows rules that protect system security and data integrity.

The following is a list of file types that are not automatically backed up when you run Windows NT Backup:

Files you do not have permission to read. Only persons with backup rights can copy files they do not own.

Paging files. These are temporary files used to represent virtual address space.

Registry files on remote computers. Windows NT only backs up local Registry files.

Exclusively locked files. Windows NT Backup cannot copy files locked by application software. However, it supports backup of local files that are exclusively locked by the operating system. Windows NT locks two types of files: event logs and Registry files.

If Windows NT Backup encounters an open file, it normally backs up the last saved version of the file.

Windows NT Backup recovers all files except:

Tape files that are older than a disk file. If a file being restored already exists on disk, and the disk file is newer than the tape file, the Backup program asks you to confirm replacement. Event logs are an example of files that shouldn't be overwritten.

A file to be restored into a directory for which you don't have access. Likewise, if you do not have write access to a file, you cannot restore over it. These conditions do not apply if you have restore rights.


How Windows NT Backup Keeps Track of Files
Backing Up Network Files	14 of 19

Using Windows NT Backup

How Windows NT Backup Keeps Track of Files

Each tape you create may consist of several backup sessions or sets. At the end of each backup set, Windows NT Backup stores a summary of file and/or directory information in a backup set catalog. At the end of each tape, there is a backup set map that maintains the exact tape location of the backup set's data and catalog. This information is temporarily cached from tape to disk when you run the Backup program.


Recovering a Server
Backing Up Network Files	15 of 19

Recovering a Server

The most common failures that require system recovery of a server are hardware failure, where the physical disk is damaged and must be replaced, and accidental deletion or modification of data. Either of these failures can happen on your bootable system partition or on a data partition.

If a failure occurs on a server running Windows NT Server, you will want to recover the server and get it running again as soon as possible. To be able to do this, you should have a plan of action ready. The following sections should help you with your disaster recovery plan.


Making Recovery Easier
Backing Up Network Files	16 of 19

Recovering a Server

Making Recovery Easier

When you first set up a server, you can reduce the amount of time needed for system recovery by putting your Windows NT Server bootable partition and your data partition(s) on separate physical drives. This will greatly simplify recovery if a physical disk is damaged. If you must have the bootable partition and data on the same physical drive, recovery in the event of failure will take longer.

Once your server is installed and running, the foundation of data protection is creating and maintaining a rotation of backup tapes. How to do this, and how to keep records to allow you to quickly find the correct backup tape, is explained earlier in this chapter.

If you use Disk Administrator to create striped sets or disk mirrors, you should save the disk configuration data each time you change your configuration. You can save the configuration to the server's Emergency Repair disk or to a separate floppy disk.

Another helpful record to have during disk recovery is a written list of disk partitions and their sizes. You may want to affix this information to the front of each disk drive.

The Emergency Repair disk contains the BOOT.INI file and some Registry information needed to recover a server if the partition containing the Windows NT Server software is lost. If system recovery of a server running Windows NT Server requires reinstallation of system software, you can use the Emergency Repair disk and choose the Repair option of the Setup program to automatically restore this information.

With Windows NT Server 3.5, you can use the new RDISK.EXE utility to update the Emergency Repair disk with the most current information. You should use this utility whenever you make changes to the BOOT.INI information or the Registry.


How to Recover a Server
Backing Up Network Files	17 of 19

Recovering a Server

How to Recover a Server

If a server has a physical disk failure on the disk containing the server's bootable partition, the basic steps to recover the server from tape are as follows. Later in this section are some tips on how to reduce the time needed for this process.

1.	If there was a physical disk failure, replace the disk.

2.	If the failed disk contained the bootable partition, reinstall Windows NT Server on the new disk. You can recover the server's BOOT.INI and part of its Registry information by using the Setup program's Repair option, and the server's Emergency Repair disk.

3.	Restart the server.

4.	From a tape drive attached to the server (not over the network), restore the system partition from the last normal backup. Then restore any applicable incremental or differential backup sets. Be sure to select the Restore Local Registry option to recover the rest of the Registry information.

5.	Restart the server.

It is now ready for normal use.

Step 2, reinstalling Windows NT Server on the new disk, can be a significant delay if the server performs time-critical functions. To minimize the time necessary to recover the server, you could create a recovery drive. This is an external SCSI drive, as small as 100Mb. It can be a dedicated disk drive, which sits on the server's SCSI chain but is powered off to prevent accidental modification, or it can be a pooled portable drive, which you can then cable to any server that fails.

To prepare the recovery drive for future use, install Windows NT Server on the drive, and configure a local paging file and tape driver on it. Then create a bootable floppy disk containing a bootloader and BOOT.INI that points to the SCSI address of the recovery drive.

When a system failure occurs, cable the recovery drive to the server (or power it on if it is already attached to the server). Restart the server using the boot floppy you made for the recovery drive.

If the recovery drive has the minimal software and user accounts to run your server, you can operate the server with the recovery drive until the next scheduled maintenance period, and then make a full restore from tape.

Depending the size of the recovery drive, you can either make the recovery drive your new system drive and restore from tape to it, or you can replace the failed drive and restore to the new drive in the background, while the recovery drive keeps the server running.


Backup Example
Backing Up Network Files	18 of 19

Backup Example

The following example shows how to apply the concepts explained in this chapter.


Setting Up a Backup Program for a Small Network
Backing Up Network Files	19 of 19

Backup Example

Setting Up a Backup Program for a Small Network

Suppose you need to back up a Windows NT Server computer and 20 client computers. The clients are a mix of MS-DOS, Windows for Workgroups, and Windows NT computers. You plan to purchase one tape drive and controller card and to use Windows NT Backup.

You can work out a solution by following four steps:

1.	Research and choose a tape drive based on reliability, speed, capacity, cost, and Windows NT compatibility. The drive should support tape cartridges with more than enough space to back up your entire server.

2.	Locate your tape drive at the server so that you can back up the server Registry and so that server backups take place as quickly as possible. From the server, you can back up user files on remote Windows NT and Windows for Workgroups computers.

3.	Install the tape controller card in the server, and attach the tape drive. Be sure that the tape drive is turned on before powering up the server; otherwise, the SCSI tape driver will not be loaded properly.

4.	Choose a tape rotation schedule that includes backup of Windows NT Workstation and Windows for Workgroups computers. To conserve tapes, back up client computers less frequently than your server and, space permitting, encourage the user to copy extremely important files to the server at the end of the day. The following illustration shows a possible rotation schedule.

Because Windows NT backup does not back up MS-DOS files, consider reserving some space on the server where MS-DOS users can copy important files. These files would be backed up during regular server backups.


Monitoring Network Activity and Performance
Chapter 9	1 of 19

Monitoring Network Activity and Performance

This chapter discusses Windows NT tools that track network activity and performance. These tools, Event Viewer, Server Manager, and Performance Monitor, display three types of information, respectively:

Event logs that record errors, security audits, and other significant events for problem diagnosis

Usage statistics that tell who is currently accessing a server or workstation and how they are accessing it

Performance statistics that indicate such things as queue activity, processor utilization, memory usage, and server throughput

To increase the effectiveness of these tools, Windows NT includes a network Alerter service that can be configured to send messages notifying administrators of important errors and events.

This chapter also briefly describes Windows NT services that allow TCP/IP and SNA-based networks to monitor a Windows NT enterprise. These services translate messages generated by Windows NT computers into a format recognized by the Simple Network Management Protocol (SNMP) and NetView, two industry-standard network management products.


Monitoring Security and Errors
Monitoring Network Activity and Performance	2 of 19

Monitoring Security and Errors

Windows NT keeps a record of errors, logon activities, and other significant events that happen on computers. These records are stored in event logs, which may be examined using the Windows NT Event Viewer. Typical log entries include such items as the failure of a device driver, a data error from a network card, or an unsuccessful logon.

Every Windows NT computer has three logs in which events are recorded: system, security (audit), and application.

The following table describes each event log.

Event log	Description		Event selection process
System	Errors, warnings, or information generated by the Windows NT system		Selection of events is preset by the operating system.
Security	Valid and invalid logon attempts and events related to resource use such as creating, opening, or deleting files or other objects		Control of security event auditing is set in the Policies menu of User Manager. Control of file and directory access audits is set through the Security menu in File Manager.
Application	Errors, warnings, or information generated by application software, such as an electronic mail or database program		Application developers decide which events to monitor.
System and application logs are available to be viewed by all users, while security logs are accessible only to system administrators. With appropriate administrative rights, you can also view logs on other computers.

After selecting a log for display in Event Viewer, you can view, sort, filter, and search through it for details about events. For example, you could filter logs to display only warnings, or to show only errors generated by a particular network card or device driver. Filtering has no impact on what Windows NT actually records and does not modify logs.

Setting an Event Logging Policy

Event logging starts automatically at system boot time. By default, each log file (system, security, and application) has a maximum size of 512K. You can increase or decrease maximum log sizes, and there is no limit to log size except for disk and memory capacities. However, you cannot set maximum log size below its current capacity, without clearing the log. When log files become full, they may be archived for later viewing in Event Viewer or for analysis using a spreadsheet or other application.

What happens when a log file becomes full depends on the logging strategy you choose. Several strategies are possible:

Set logs to automatically overwrite themselves as needed. This is a good choice for low-maintenance systems. The disadvantage of this configuration is that a flood of events could wipe out prior log entries, potentially obscuring the origin of a problem. This is especially true for a security log, where tracking an initial security breach may be important.

Set logs to automatically overwrite events provided they have been kept for a user-specified period of days (the maximum is 365). This strategy is recommended because it minimizes the chance of losing important log entries and at the same time keeps log sizes reasonable.

Maintain logs for manual clearing. This is a particularly good option for security logs. You can configure Windows NT to send periodic messages informing the system administrator that an event log is full and won't resume logging until it is cleared. For information on configuring network alerts, see "Using Network Alerts," later in this chapter.

The default logging policy is to overwrite logs as needed, provided events are at least seven days old. In all likelihood, you'll want to implement different strategies for different logs.

Logging stops when an event log becomes full and cannot overwrite itself - either because you've set it up for manual clearing or because the first event in the log is not old enough. To avoid losing data in this situation, you can either extend maximum log size, decrease event retention time, or archive the log and then clear it.

Using Event Logs to Troubleshoot

Each entry in an event log may include the following information: Date, Time, Source, Type, Category, Event ID, User, and Computername. In addition, most events also generate a text description and sometimes binary data, which are available by double-clicking on a single entry or choosing Details in the View menu. The binary data is generated by the application that was the source of the event record. Because the data appears in hexadecimal format, interpreting it may require consulting someone who is familiar with the source application. Binary data may be displayed in words or in bytes.

Careful monitoring of event logs can help you predict and identify the sources of system problems. For example, if log warnings show that a disk driver is only able to read or write to a sector after several retries, it probably indicates that the sector will go bad eventually. Log files can also confirm problems with application software. If an application crashes, an application event log provides a record of activity leading up to the event for support personnel to analyze.

Here are some suggestions to help you diagnose problems using event logs:

Archive logs in log format. The binary data associated with an event is discarded if you archive data in text or comma-delimited format.

If you suspect a hardware component is the origin of system problems, filter the system log to show only events generated by that component.

If a particular event seems related to system problems, try searching the event log for other instances of the same event or to judge the frequency of an error.

Make sure to note Event IDs. These are unique numbers that match a text description in a source message file. This number can be used by product support representatives to understand what occurred in the system.

Using Event Logs to Analyze Activity

Using spreadsheet or word-processing programs, you can manipulate event log data saved as text to produce graphs, charts, and reports. Graphs generated from event logs might be used to show the times when logon activity is highest, the average time between network failures, and so on.

Reading event logs into other applications requires saving them in text or comma-delimited text format. This type of archive discards binary data associated with an event but saves all other log details.


Monitoring Server Usage
Monitoring Network Activity and Performance	3 of 19

Monitoring Server Usage

Every time a user at a client computer successfully connects to a server, a session with the server begins. A session validates the user's permission to access the server and establishes what performance and functional features the client can use. Monitoring session activity is useful for gauging a server's workload and for identifying whom to notify when you need to shut down a server or free its resources.

With Windows NT Server, you can monitor server and workstation statistics using Server Manager. Server Manager lists all users that currently have sessions on a selected computer, as well as the resources opened during their sessions. You can check to see when a user opened a resource and if a session has been idle for an extended period of time. Statistics such as the number of file locks, the number of open resources, and number of printers currently in use are also available.

Note

Server Manager shows present usage levels - it does not collect statistics over a period of time. To see cumulative usage statistics, type net statistics server (or workstation) at the command prompt. This will show you performance and activity statistics collected since computer startup.

In many cases, you'll be able to identify the source of server access problems by checking the number and nature of its user sessions. For example, should server throughput slow to a crawl, the number of active sessions may tell you why. It could be that many people are simultaneously attempting to download files from a server, thereby saturating the system processor. Checking share usage can show you if the activity is concentrated in a particular location.

Study server information on a regular basis. The more familiar you are with statistics that reflect normal activity, the easier it will be to spot changes that indicate problems.

Usage statistics are available for Windows NT Workstation computers, Windows NT Server computers, and LAN Manager 2.x servers. To monitor a computer using Server Manager, you must be an administrator or server operator for that computer.


Monitoring Performance
Monitoring Network Activity and Performance	4 of 19

Monitoring Performance

Windows NT includes a tool for tracking computer performance called Performance Monitor. This tool is based on a series of counters that track such things as the number of processes waiting for disk time, the number of network packets transmitted per second, and the percentage of processor utilization. When collected over a period of time, counter statistics show performance trends, which in turn can help you tune your network and systems. Performance statistics are also valuable in troubleshooting performance problems and planning for network expansion.

Effective performance monitoring requires archiving data over an extended time period. Because there are few hardware-independent counter values, anticipating and solving performance problems usually requires familiarity with the normal range of system and network operating conditions. In some cases, counter values will not be sufficient to diagnose performance problems, and you'll need to move to another, more focused tool, such as a hardware monitor or processor usage profiler.


How Performance Monitor Displays Information
Monitoring Network Activity and Performance	5 of 19

Monitoring Performance

How Performance Monitor Displays Information

Performance Monitor displays information graphically (through Charts) or as text (through Reports). Data may be displayed as it happens or collected in logs for later display as a graph or report. You can also configure Performance Monitor to generate alert logs. Entries are posted to alert logs every time a counter exceeds or falls below a user-specified value. You can also configure Performance Monitor to generate network messages or run a program based on alert log entries (see "Using Network Alerts," later in this chapter).

Users have control over the frequency with which Performance Monitor updates information in logs, graphs, and reports through time interval settings. These settings, which can vary with each display mechanism, determine the resolution of the displayed data. Each displayed value is usually an average over the last two data reads, which are separated by the length of the time interval. (When displaying log file data, you can manipulate the time interval to be a subset of or equivalent to the total time period of the log file.)

Time interval settings also affect the amount of memory and processor time used by Performance Monitor. Monitoring is generally not a huge burden on processor time or memory unless you retrieve data very frequently from a large number of computers.

For more information on Performance Monitor user interface settings, see the Windows NT Server System Guide.


Understanding Counter Organization
Monitoring Network Activity and Performance	6 of 19

Monitoring Performance

Understanding Counter Organization

When monitoring a system, you're really monitoring the behavior of its objects. In Windows NT, an object is a standard mechanism for identifying and using a system resource. Objects are created to represent individual processes, sections of shared memory, and physical devices. Performance Monitor groups counters by object type. A unique set of counters exists for the processor, memory, cache, hard disk, processes, and other object types that produce statistical information. Certain object types and their respective counters are present on all systems; other counters, such as transport protocol counters, only appear if the computer is running the associated software.

Each object type can have several instances. For example, the Processor object type will have multiple instances if a system has multiple processors. The Physical Disk object type has two instances if a system has two disks. Some object types (the Memory and Server) do not have instances. If an object type has multiple instances, each instance produces the same set of statistics (counter information).

Two object types, processes and threads, have a particularly close relationship. A Windows NT process is created when a program runs. A process may be either an application (Microsoft Word, Corel® Draw), a service (Event Log, Computer Browser), or a subsystem (print spooler, POSIX). In addition to an executable program, every process consists of a set of virtual memory addresses and at least one thread.

Threads are objects within processes that execute program instructions. They allow concurrent operations within a process and enable one process to execute different parts of its program on different processors simultaneously. Each thread running on a system shows up as an instance for the Thread object type and is identified by association with its parent process. For example, if Print Manager has two active threads, Performance Monitor identifies them as Thread object instances Printman= =>0 and Printman= =>1.

Note

Instances of the Process object type appear as numbers if they are internal system processes. Other types of processes are identified by the name of the executable file.


Knowing What to Measure
Monitoring Network Activity and Performance	7 of 19

Monitoring Performance

Knowing What to Measure

When you first start Performance Monitor, the number of performance counters may seem overwhelming. It's not necessary to be familiar with all performance counters. Some counters are appropriate only for programmers writing Windows NT-based applications; others are useful for vendors who need to test hardware performance. This section focuses on counters of interest to system administrators, specifically those counters that indicate something about system and network throughput.

System throughput problems usually occur when the demand for resources exceeds supply. Resources, in this case, are the microprocessor(s), memory, hard disk(s), and networking hardware and software. Finding out how user applications interact with each of these resources is a logical first step when you start monitoring.

An important second step is to assess the overall load on each resource. How close to being saturated is a system processor? How many applications are waiting to use the disk drive? User applications are not the only programs demanding resource time; a number of operating system processes also consume fixed amounts of each resource.


Watching How Applications Use System Resources
Monitoring Network Activity and Performance	8 of 19

Monitoring Performance

Watching How Applications Use System Resources

You can learn a lot about a system by looking at how various applications use memory, the microprocessor, and disk I/O time. You can figure this out using four counters:  % Processor Time, Working Set, File Read Operations per second, and File Write Operations per second.

These counters, which all belong to the Process object type, are defined as follows:

% Processor Time

The percentage of elapsed time that a processor is busy executing a thread for a particular process. (Notice that % Processor Time is high for the Idle process when the system is not busy.)

Working Set

Working Set is the current number of memory bytes used by or allocated to a process. This value may be larger than the minimum number of bytes actually needed by the process.

File Read Operations/sec

The rate (number per second) of read operations on peripheral devices, such as hard disks or printers, issued by threads in a process.

File Write Operations/sec

The rate (number per second) of write operations on peripheral devices issued by threads in a process.

Using these counters, you can generate a report that focuses on all or a subset of the applications running on a computer. The following sample report shows activity for three applications: Notepad, Performance Monitor, and File Manager.

This example represents a snapshot of system activity; in a real-time report or chart, certain counter values, such as Working Set, are relatively static, while others, such as % Processor Time, change constantly. For example, at application startup, it's normal to see the % Processor Time value climb sharply, decrease, and then level off.

This example shows that the disk and processor activity caused by Notepad reflects the savings of a Notepad file to disk. Performance Monitor's processor activity occurred when it was time to read a new set of counter values. Counter reads occur at regular intervals set by the user. If you were to double the data retrieval interval and then rerun the sample Report, % Processor Time would decrease by half to approximately 1.20%.

File Manager (WINFILE) experienced no activity, but because it was started, the operating system allotted memory to it. Every running application may use a portion of physical memory - its working set. This counter value will change slowly over time depending on the activity of the application. The working set value is of particular interest when the Available Bytes counter sinks below a certain threshold. (The Available Bytes counter belongs to the Memory object type.) This signifies that Windows NT is gradually beginning to steal memory from the working sets of running applications in order to ensure that a certain amount of free memory exists. If large numbers of bytes are stolen, an application's response time will decrease.

The following chart shows how Windows NT satisfies the memory requirements of Application A by using free (available) bytes. It then begins to replenish the lack of available bytes by gradually taking memory from the working sets of less active programs (Applications B and C).

You can expand sample reports and charts to include more applications and more counters. To understand system activity, watch these and other counter values while changing system activity levels.


Making Sure You Have Enough Memory
Monitoring Network Activity and Performance	9 of 19

Monitoring Performance

Making Sure You Have Enough Memory

Memory usage is perhaps the most important factor in system performance. A system must have enough memory for large operations as well as enough memory for a mix of smaller jobs that characterize everyday work. When memory demand exceeds supply, your system will start paging. Paging refers to moving blocks of data from RAM to disk to free up space for a process. Some paging is acceptable. It enables Windows NT to use more memory than actually exists in physical memory (RAM). Constant paging, however, is a big drain on system performance.

When you start Windows NT, the operating system automatically creates a paging file (PAGEFILE.SYS) on your system. The recommended size for the paging file is equivalent to the amount of RAM available on your system plus 12 MB. However, the size of the file also depends on the amount of free space available on your hard disk when the file is created. You can change paging file size using the System option in Control Panel.

The size of the paging file is somewhat elastic; depending on paging requirements and available disk space, it can expand upward to a user-specified maximum size (also set through the Control Panel). If memory demands decrease, the paging file may shrink back to its original size. When running a large number of applications, it may be necessary to expand paging file size. (It's more efficient to expand initial paging file size than to extend maximum file size; forcing Windows NT to allocate more paging file space slows the start of applications and fragments the disk.)

There are two situations involving memory that commonly cause problems. The first is a situation in which excessive paging is causing slow performance. The second is a case in which a system paging file size is too small and could prevent you from running further applications.

Checking for Excessive Paging

If you suspect excessive paging, check the Pages/sec counter in Performance Monitor. This counter, which is part of the Memory object type, shows the number of pages that had to be read from disk because they were not in physical memory. (Note the difference between this counter and Page Faults/sec, which only tells you that data was not immediately available in the specified working set in memory.)

When you first start an application, you'll see Pages/sec jump and then almost immediately decrease. How much paging is too much paging is a subjective decision. Each page read from disk takes a certain amount of disk access time. This value is typically around 20 ms per read but may vary from computer to computer. To confirm excessive paging, add together the Avg. Disk sec/Transfer (a physical disk counter) and Pages/sec counter values. If the product of these counters exceeds 0.1, paging is taking more than 10% of disk access time. If this occurs over a long period, you probably need more memory. The next step is to take a look at running applications. If possible, stop the application with the highest working set value, and see if that dramatically changes the paging rate.

Checking Paging File Size

One way to see if your paging file is approaching its upper limit is to check the actual file size and compare it to the maximum paging file size setting in the System option in Control Panel. If these two numbers approach each other, you need to consider increasing initial paging file size or running fewer applications.

Paging file counters are another way to check if the size of PAGEFILE.SYS is appropriate. The two counters of interest are % Usage and Usage Peak (bytes) under the Paging File object type. If the Usage Peak value approaches the maximum paging file setting, or if % Usage nears 100%, consider increasing the initial file size.

If you have multiple paging files spread across multiple disk drives, the path name of each file appears as an instance of the Paging File object type.


Monitoring Processor Activity
Monitoring Network Activity and Performance	10 of 19

Monitoring Performance

Monitoring Processor Activity

Each process thread requires a certain number of processor cycles when it runs. If demand exceeds supply, long processor queues develop and system response suffers. To see how busy a processor is, check the % Processor Time counter (under the Processor object type). % Processor Time shows the percentage of elapsed time that a processor is busy executing a non-idle thread.

The following chart is a simultaneous comparison of processor activity on four separate servers.

If processor utilization is 100%, it is reasonable to assume that a faster processor will improve performance. However, 100% processor usage is not necessarily bad, unless the processor queue length is excessive. Windows NT does not measure a processor's queue length directly, but you can see this indirectly. If processor usage is 100%, chart % Processor Time for all instances of the Process object type. Use the Histogram option, and set the time interval to 5 seconds to see average usage. If more than a couple of application processes are contending for the majority of processor time, you may need to install a faster processor, or another processor if you are using a multiprocessor system.

Acceptable processor usage may depend on computer activity. If a system is used for computational work, it's reasonable to see heavy processor usage. On servers that are busy processing many The Interrupts/sec counter, which measures the rate of service requests from I/O devices, is also an important Processor counter. If this counter value increases dramatically without a corresponding increase in system activity, it could indicate a hardware problem.

The Interrupts/sec counter, which measures the rate of service requests from I/O devices, is also an important Processor counter. If this counter value increases dramatically without a corresponding increase in system activity, it could indicate a hardware problem.


Monitoring Disk Activity
Monitoring Network Activity and Performance	11 of 19

Monitoring Performance

Monitoring Disk Activity

Disk usage statistics can help you balance the workload of network servers. By monitoring disk activity, you can identify the most popular share points and move them to the best-performing equipment. Monitoring disk performance is also important: if disk I/O is performing properly, there will be less strain on virtual memory, and programs will run faster.

Performance Monitor provides two groups of disk counters: one for the physical disk and one for logical disks (partitions). Physical disk counters are important for troubleshooting and capacity planning. Reasons to monitor a logical disk are to obtain free space statistics or as a means of finding the source of activity on a physical volume.

Note

Because disk counters can increase disk access time by approximately 1.5% on x86 processors, Windows NT does not automatically activate the counters at system startup. To activate system disk counters, type diskperf -y at the command prompt, and restart your computer. To monitor disk activity on a remote computer, type diskperf -y \\computername. To disable disk counters, type diskperf -n or diskperf -n \\computername and restart your computer. To activate a system's disk counters, you must be a member of the Administrators group for that computer.

Determining Workload Balance

To balance loads on network servers, you need to know how busy server disk drives are. This information is available from the % Disk Time counter (under the Physical Disk object), which indicates the percentage of time a drive is active. If % Disk Time is high, check the Disk Queue Length counter to see how many system requests are waiting for disk access. The number of waiting I/O requests should be sustained at no more than 1.5 to 2 times the number of spindles making up the physical disk. Most disks have one spindle, although Redundant Array of Inexpensive Disks (RAID) disks usually have more. A RAID device appears as one physical disk in Performance Monitor.

If Disk Queue Length and % Disk Time values are consistently high, consider upgrading the disk drive, or move some files to an additional disk or server.

Tracking Disk Performance

The Avg. Disk sec/Transfer counter shows you how much time a disk takes to fulfill requests. If this value is high, it may indicate that the disk controller is continually retrying the disk because of failures. For most disks, high average disk transfer times correspond to values greater than 0.3 seconds. A missed disk revolution typically adds 16 ms to average disk transfer time.

You can also check if Avg. Disk Bytes/Transfer is high. If this counter value is greater than 20K, the disk drive is generally performing well, although low values result if an application is accessing a disk inefficiently. Applications that access a disk at random  also raise Avg. Disk sec/Transfer times because random transfers require increased seeking time.


Monitoring Network Activity
Monitoring Network Activity and Performance	12 of 19

Monitoring Performance

Monitoring Network Activity

At a minimum, network monitoring typically consists of two activities: watching server performance and measuring overall network traffic. On a Windows NT network, you can use Performance Monitor to track server performance and to troubleshoot if a problem occurs. Monitoring overall network traffic requires specialized tools such as dedicated network monitoring software or a packet sniffer.

Watching Server Throughput Statistics

Every Windows NT computer includes networking software that enables it to act as a client or a server. Redirector software (RDR.SYS) transmits requests while Server software (SRV.SYS) receives and interprets incoming messages. (Redirector and Server software are represented in the user interface as the Workstation and Server services, respectively.) Each computer also uses at least one type of protocol software to handle packet formatting and routing. Windows NT supports several protocols, including NetBEUI and TCP/IP.

The Server, the Redirector, and NetBEUI and TCP/IP if they are installed, each generate a set of statistics that appear as Performance Monitor counters. (Note that other protocols may also generate counters.) Abnormal network counter values often indicate problems with a server's memory, processor, or disk(s). For that reason, the best approach to monitoring a server is to watch network counters in conjunction with previously discussed counters such as % Processor Time, % Disk Time, and Pages/sec.

For example, if a dramatic increase in Pages/sec is accompanied by a decrease in Bytes Total/sec handled by a server, it's probable that the computer is running short of physical memory for network operations. Most network resources, including network adapter cards and protocol software, use non-paged memory. If a computer is paging excessively, it could be because most of its physical memory has been allocated to network activities, leaving a small amount of memory for processes that use paged memory. To verify this, check the computer's system event log for entries indicating that it has run out of paged or nonpaged memory.

The following table lists various network counters of interest. Observing these counter values over a period of time is a good way to gain knowledge of network operations.

Object type	Counter		Description
Server	Bytes Total/sec		The number of bytes sent and received from the computer each second. This value gives an overall indication of how busy a computer is.
NetBEUI	Frame Bytes Received/sec Frames Received/sec		Bytes and frames sent to this computer's network address. The ratio of Frame Bytes to Frames Received (the number of bytes per frame) should remain fairly constant.
	Frames Rejected/sec		Frames received by the computer that were incorrect and therefore had to be resent. The ratio of Frames Rejected to Frames Received should be very low.
NetBEUI Resource	Times Exhausted		This is a cumulative counter that indicates the number of times since system startup that certain network resources were unavailable.A sharp and consistent increase in values for instances 0 through 4 (links, addresses, address files, connections and requests) usually indicates network problems.
Monitoring Overall Network Traffic

If network traffic exceeds LAN capacity, it usually means performance suffers across the network. To prevent this, it's important to monitor network-wide traffic levels, particularly on larger networks with bridges and routers. When monitoring network traffic, three statistics are of special interest: bandwidth utilization, total bytes per second, and total broadcasts per second. These statistics are usually available from dedicated network monitoring products.

Bandwidth utilization tells you how close the network is to full capacity. Watching packets per second is important for anticipating when bridges and routers will become flooded, and total broadcasts per second reflects overall network performance. A broadcast is a network message transmitted to all network computers. Because each computer processes every broadcast, high broadcast levels mean lower performance.

On small networks, you can use Performance Monitor to figure out network traffic levels by adding up the Bytes Total/Sec counter (under the Server object type) for each server on your network. If the sum is approximately equal to the maximum transfer rates of your network line, you may need to segment the network.


Solving Performance Problems
Monitoring Network Activity and Performance	13 of 19

Monitoring Performance

Solving Performance Problems

Performance troubleshooting is a complex topic, touched on only briefly in this chapter. The troubleshooting suggestions discussed here represent a starting point: solving a performance problem could necessitate consulting someone with extensive monitoring experience. Network problems in particular are difficult to diagnose and may require using tools such as a LAN packet sniffer.

As noted earlier, performance problems usually occur because of excessive demand for resources, where the important resources are the microprocessor(s), disk(s), memory, and network components. Resource shortages can occur for any of the following reasons:

There is not enough of a particular resource.

Resources are not sharing workloads evenly.

A resource is malfunctioning.

An application is monopolizing a particular resource.

A resource is incorrectly configured.

Windows NT is a self-tuning system, so most performance problems will be resolved by correcting one of the problems mentioned above. This may be different from other systems you have tuned that probably required you to adjust a large number of possibly conflicting system parameters.

When a user complains of a performance problem, the first step should be to try to identify which resource is in short supply by examining key performance counters and checking event logs for possible errors. Compare the performance of network and non-network applications to see if you can isolate the source of the problems.

The following table lists the first counters to look at when troubleshooting.

Object type	Counter		Possible bottleneck
Processor	% Processor Time		If this value is consistently high and disk and network counter values are low, suspect the processor.
Physical Disk	% Disk TimeDisk Queue Length		If % Disk Time is consistently high and Disk Queue Length is greater than 2, suspect the disk.
Memory	Pages/sec		If counter value is consistently > 5 for a single disk, suspect memory.
Server	Bytes Total/sec		If the sum of Bytes Total/sec for each server is roughly equivalent to the maximum transfer rates of your network, you may need to segment the network.
Once you've identified the probable bottleneck (there may be more than one), the next step is to figure out if the resource is simply overused, broken, or the victim of a badly written application. Take a careful look at the sources of system activity: Which processes are most active? Is one application or thread monopolizing the resource?

An obvious way to solve performance problems is to add more resources. This is sometimes not a satisfactory solution, however, because it is expensive and may not fix your problems. Before you consider adding memory or disk drives, you might experiment with the following alternatives:

Create multiple paging files - one for each physical disk and controller on a system. Spreading paging files across multiple disk drives and controllers improves paging performance because each disk can issue I/O commands concurrently. If you have two disks and one paging file, put Windows NT system files on one disk and your paging file on the other. Use the System option in Control Panel to create new paging files.

Run memory-intensive applications at times when the system is not busy, or run them on your highest-performance computers.

Make sure the load on network servers is balanced. Do this by distributing applications among servers until each computer displays reasonably equivalent values for the counters listed in the previous table.

Unbind infrequently used network cards by choosing the Bindings button in the Network option in Control Panel.

Configure your network so that systems shared by the same group of people are on the same subnetwork.

Read Chapter 10, "Tuning for Network Performance," for other suggestions on improving server and workstation performance.


Planning for Additional Resources
Monitoring Network Activity and Performance	14 of 19

Monitoring Performance

Planning for Additional Resources

If not anticipated, network growth can lead to overused resources and poor levels of network service. By characterizing system performance over time, you can justify the need for new resources before you get into a panic situation. For example, if you see a trend towards increasing page faults on a server, it could be one indication that server workload is outgrowing its hardware capacity and that it is time to install more memory.

Capacity planning starts with regular measurements on a daily basis. Initially, you might log at 5 minute intervals all day long and then relog the files with the intervals increased to 15 minutes and the time window focused on the most active 2 hours of the days. Append these 2 hours' worth of information to an ongoing archive log you've created.

Tracking the measurements in the following list provides a good starting point for resource planning.

Object type	Counter
Processor	% Processor Time, Interrupts /sec
System	File Read/write operations/sec
Memory	Pages/sec, Available Bytes
Server	Bytes Total/sec
Physical Disk	% Disk Time, Avg. Disk sec/Transfer
Logical Disk	% Free Space


Using Network Alerts
Monitoring Network Activity and Performance	15 of 19

Using Network Alerts

In most cases, it's preferable to learn about system events before they cause problems for network users. Instead of constant network monitoring, you can configure Windows NT to notify you when system errors or important events occur. This type of notification is known as an alert. An alert message might inform you that a disk is near capacity or warn you when too many logon violations have occurred.

Note

The list of events that can trigger network alerts is predetermined by Windows NT. You cannot specify which events or errors cause alerts except in the case of Performance Monitor counter alerts, which are set by the user.

Designate the users and computers that are to receive alerts either through the Server option in Control Panel or with Server Manager. To generate an alert, a computer must be running the Alerter and Messenger services; on computers designated to receive alerts, the Messenger service must be active. Note that if the destination computer is turned off, the network message will eventually time out.

Counter values that trigger entries in the Performance Monitor alert log also generate network alerts. However, Performance Monitor alerts can only be received by remote computers whose net name has been designated as the recipient by the computer originating the alert. For information on setting up remote computers to receive performance counter alerts, see the chapter called "Performance Monitor" in the Windows NT Server System Guide.


Monitoring from Other Networks
Monitoring Network Activity and Performance	16 of 19

Monitoring from Other Networks

Windows NT supports monitoring services that enable network management products to monitor a Windows NT network remotely. These services are Simple Network Management Protocol (SNMP), NetView Alert (NVAlert), and NetView Run Command (NVRunCmd).

To run SNMP, you need to install the TCP/IP protocol (included with Windows NT) on all computers that require monitoring. To use NVAlert or NVRunCmd, install SNA Services for Windows NT on each computer you intend to monitor. SNA Services is purchased separately from Windows NT.


SNMP
Monitoring Network Activity and Performance	17 of 19

Monitoring from Other Networks

SNMP

Simple Network Management Protocol (SNMP) is a widely used protocol that specifies a format for collecting network management data. With the Microsoft SNMP service, Windows NT computers are able to send status information to a SNMP management program running on a TCP/IP network.

The SNMP service sends information to a host in two instances: when a host requests such information, and when a significant event occurs on a server or workstation. The SNMP service can communicate with multiple hosts simultaneously.

The SNMP service also provides application programming interfaces (APIs) to let you develop third-party Management Information Bases (MIBs) and also build your own SNMP-based management program.


NVAlert and NVRunCmd Services
Monitoring Network Activity and Performance	18 of 19

Monitoring from Other Networks

NVAlert and NVRunCmd Services

The NVAlert and NVRunCmd services link Windows NT with centralized management programs running on systems network architecture (SNA) networks. SNA networks are mainframe-based.

With the NVAlert service installed, a Windows NT computer can automatically report error and status information on an IBM NetView® or compatible network-management host. The NVAlert service operates by converting Windows NT event log entries into generic alerts. Users have the opportunity to choose which Windows NT events they want to map to which alerts.

The NVRunCmd service supports the NetView run command or equivalent with remote Windows NT command-line access. For example, using NVRunCmd, you can add a new share point on a server running Windows NT Server, add Windows NT users, or delete files.

For more information on running NVRunCmd or NVAlert, check the Microsoft SNA Services documentation.


Monitoring Examples
Monitoring Network Activity and Performance	19 of 19

Monitoring Examples

The following examples illustrate how to apply some of the concepts discussed in this chapter.

1.	Suppose you have just converted a computer from Windows 3.1 to Windows NT. When the workstation starts up, an error message appears stating that the dependency service or group failed to start.

The first step when you receive an error message is to check the appropriate event log. (The Event Log service should run regardless of problems with other network services.) Checking the system event log, you'll see various errors that appeared as a result of one or more dependent services being unable to start. At the bottom of the event log, notice that the first error originates with an adapter card driver. Double-click the event to read the event details, which indicate that an interrupt-setting conflict occurred with your adapter card.

Run the Microsoft Diagnostics program (systemroot\SYSTEM32\WINMSD.EXE) to see which interrupt settings are free, and reconfigure your card using the Network icon in Control Panel.

2.	Activity on a server suddenly becomes very slow. A look at key counters (% Processor Time, Interrupts/sec, Pages/sec, % Disk Time, and Bytes Total/sec) shows that Bytes Total/sec is close to 1 MB/sec, which approximates the limit for Ethernet LANs.

If Bytes Total/sec is near 1.2 MB/sec and you are on a single ethernet line, it's probable that traffic to and from the server has saturated the network segment. Solutions include distributing the server's applications among multiple computers or routing server traffic through multiple network segments.

3.	Activity on a server suddenly becomes very slow. Key counters show the following values:

Since % Processor Time and Interrupts/sec values are the only counters with unusually high values, processor saturation looks like the probable cause of system slowdown. Create a histogram (under the Chart option) showing the % processor time for all instances of the Process object type. Check to see if a single application is monopolizing processor time.

If processor time is shared equally among all applications, you may need to consider moving some applications to another server or upgrading to a faster processor.


Tuning for Network Performance
Chapter 10	1 of 4

Tuning for Network Performance

Windows NT automatically adjusts system parameters to accommodate user demands and various network configurations. For example, it alters the size of the system paging file and cache buffer as memory requirements change, and autotunes network time-out values to fit varying LAN topologies.

With a few exceptions, manual tuning of operating system parameters is not required to improve network performance. However, there are several other steps you can take, such as reconfiguring or changing hardware components, that can increase file-sharing performance. This chapter discusses these steps.


Configuring Computers for File-Sharing Performance
Tuning for Network Performance	2 of 4

Configuring Computers for File-Sharing Performance

The following steps can help you obtain the best performance from your Windows NT computers.

Before making major configuration changes, use Performance Monitor to evaluate your current configuration; this can help you determine if a particular system or network component is acting as a performance bottleneck. (For information on Performance Monitor, see Chapter 9, "Monitoring Network Activity and Performance.")

If you have more than one disk drive and controller, create multiple paging files. Spreading paging files across multiple physical disk drives and multiple controllers improves paging performance because each disk can issue I/O commands concurrently. In addition, having multiple paging files makes paging file expansion easier (each file expands a little rather than a single one expanding). To create paging files, click on the System icon in Control Panel, and choose the Virtual Memory button.

Determine the right size for your paging file. In response to paging activity, Windows NT expands paging file size to a user-specified maximum size (set through the System icon in Control Panel). However, it's better to make sure initial paging file size matches system application requirements - forcing Windows NT to expand file size slows the start of applications and fragments the disk.

Make sure you have enough memory. Depending on the size of your network, server memory requirements range from 12 MB on up.

Install faster hard disks or disk controllers (or both).

On servers, use Disk Administrator to create stripe sets on multiple disks. This increases throughput because I/O commands can be issued concurrently.

Install a high-performance network adapter card in the server. If your server uses an 8-bit adapter card, you can significantly increase performance by replacing it with a high-performance 16-bit or 32-bit card.

Disable rarely used network adapter cards. This improves overall network performance by decreasing the number of broadcast packets on the network. Each broadcast packet must be processed by every active adapter card on the network. High broadcast rates adversely affect LAN performance by increasing network connection time. You can disable an adapter card by choosing the Bindings button in the Network Settings dialog box (under the Network icon in Control Panel).

If there are no wide area network (WAN) links in the network, and if there is no need to connect to any devices other than Windows NT computers, equip your servers with a small, fast protocol such as NetBEUI. If you need WAN internet capability, add the TCP/IP protocol. With both stacks supported on all servers, you can benefit from NetBEUI performance when connecting to local computers and still be able to connect over WANs to other networks.

You can install additional protocols by selecting the Network icon in Control Panel. For step-by-step instructions, see "Choosing and Installing Protocol Software" in the Windows NT Server System Guide. For information about the available network protocols, see "Choosing Network Drivers and Protocols" in this manual.

If you are using more than one protocol, you can set the order in which the Workstation and NetBIOS software bind to each protocol (you can find the list order by selecting the Bindings button within the Network icon in Control Panel). You might change list order for one of the following reasons:

If the protocol you use most frequently is first in the Binding list, average connection time decreases.

Some protocols are faster than others for certain network topologies. Putting the faster protocol first in the Bindings list improves performance.

There is no reason to reorder Server bindings because the Server accepts incoming connections on the basis of the protocol chosen by the client computer. For information on reordering the Bindings list, see "Configuring Network Bindings" in the Windows NT Server System Guide.

Use multiple network adapter cards. Windows NT supports multiple adapter cards for a given protocol and multiple protocols for a given card. Although this configuration can create distinct networks that cannot communicate with each other, it is a way to increase file-sharing throughput.

Configure Server memory settings to match network activity. This step is discussed in more detail in the next section, "Tuning Memory Settings."

For tuning suggestions related to Transmission Control Protocol/Internet Protocol (TCP/IP) and other supported protocols, see the Windows NT Server TCP/IP manual.


Tuning Memory Settings
Tuning for Network Performance	3 of 4

Configuring Computers for File-Sharing Performance

Tuning Memory Settings

You can increase network responsiveness by tuning the memory Windows NT Server allocates for server operations. Memory settings are changed by selecting the Network icon in Control Panel and then choosing the Configure button for each component.

Four memory settings are available:

Minimize Memory Used

This allows memory to be allocated for up to approximately 10 network connections.

Balance

This provides memory for up to approximately 64 connections and is the default setting.

Maximize Throughput for File Sharing

Allocates maximum memory for file sharing operations.

Maximize Throughput for Network Applications

Optimizes server memory for distributed applications that do their own memory caching, such as Microsoft SQL Server.

Consider changing memory settings if network interactions seem slow or if entries in a computer's system event log indicate that there is not enough memory for network operations. If physical memory is abundant, there is little penalty for increasing the amount of memory available for network operations. However, if physical memory is limited, such memory allocation may diminish overall system performance. Unlike user applications, which use a portion of memory that can be temporarily transferred to disk, network operations generally use nonpaged memory. The more nonpaged memory allocated to the network, the more such memory becomes scarce for the operating system and other processes that require it.


Tuning Example
Tuning for Network Performance	4 of 4

Tuning Example

Suppose that after adding 50 additional workstations to a Windows NT network, network operations slow perceptibly. The network includes three Windows NT Server computers, each using NetBEUI.

First use Event Viewer to check system event logs on the servers. If there are no events indicating problems with network software or hardware, experiment with the following steps:

1.	Use Performance Monitor to determine if there is a workload discrepancy between servers. If so, consider redistributing applications or files to equalize server workload.

2.	Use Performance Monitor to determine if any of the servers is paging excessively because of insufficient memory. If so, you may want to add memory.

3.	Use Performance Monitor to determine if a server disk is saturated. If so, consider a faster disk and/or controller, or distribute the load across several disks by creating stripe sets.

4.	Double-click the Network icon in Control Panel, and then double-click the Server selection in the Network Software and Adapter Cards box. Change memory optimization to Maximize Throughput and Connections on each computer (if not already set).

5.	Use Performance Monitor to determine if a server's network segment or network card is saturated. If the network bandwidth is at its physical maximum, you can change physical cabling. Another possible solution is to split the workstations among several physical networks, using routers to get extra bandwidth.

If the network card is saturated, consider a faster network card in the server.