http://www.microsoft.com/TechNet/boes/bo/winntas/technote/nt303.htm (PC Press Internet CD, 03/1996)
| Updated: March 13,1996 |  Go To TechNet Home Page |
Phone:(206) 882-8086
Fax:(206) 936-7329
Overview
Windows NT Networking Architecture
Network Interoperability with Microsoft Windows NT
Windows NT Domains and Trust Relationships
Fault-Tolerance Windows NT and Windows NT Server
This document discusses the networking functionality of Microsoft® Windows NT™ and Microsoft Windows NT Server. It focuses on the underlying architecture used by all networking products in the Microsoft Windows NT family, cooperative processing within Microsoft Windows NT, the concepts and functionality of trusted domains, and fault-tolerance functionality within Microsoft Windows NT.
A significant difference between the Microsoft® Windows NT operating system and other operating systems is that networking capabilities are built into Windows NT. With MSDOS®, Windows™3.x, and OS/2®, networking was added on top of the operating system.
By providing both client and server capabilities, your Windows NT-based computer can be either a client or server in a distributed application environment, as well as in a peer-to-peer networking environment.
Windows NT provides the ability to interoperate in many different network environments. It supports the following:
To understand networking on Windows NT, you need to understand its architecture. The Windows NT network architecture is modular in design, allowing one network component to be replaced with a newer one without having to provide a new set of components from the ground up.
Windows NT networking components include:
The networking architecture of Windows NT is organized in layers. This provides expandability by allowing other functions and services to be added.
A boundary is the unified interface between the layers in the Windows NT network architecture model. Creating boundaries as a breakpoint in the network layers helps open the system to outside development. It makes it easier for vendors to develop network drivers and services because the functionality that must be implemented between the layers is well defined. They only need to program between the boundary layers instead of going from the top to the bottom layer. Boundary layers also allow software developed above and below a level to be mixed and matched without rewriting it.
There are two significant boundary layers in the Windows NT network architecture: the NDIS 3.0 layer and the Transport Driver Interface (TDI) boundary layer. The NDIS 3.0 boundary layer provides the interface to the network driver interface specification (NDIS) wrapper and device drivers. The TDI boundary layer provides a common interface for a driver, such as the Windows NT redirector and server, to communicate with the various network transports. This allows redirectors and servers to remain independent from transports. Unlike NDIS, there is no driver for TDI, it is simply a standard for passing messages between two layers in the network architecture.
NDIS (Network Device Interface Specification) is a standard that allows for multiple network adapters and multiple protocols to coexist. NDIS permits the high-level protocol components to be independent of the network interface card by providing a standard interface. Windows NT supports NDIS 3.0.
The network adapter card driver is at the very bottom of the Windows NT network architecture. Because Windows NT supports NDIS 3.0, it requires network adapter card drivers written to the NDIS 3.0 specification. NDIS 3.0 allows an unlimited number of network adapter cards in a computer and an unlimited number of protocols that can be bound to a single adapter card.
NDIS 3.0 is based on NDIS 2.0, which was the standard used by OS/2 NDIS device drivers. NDIS 3.0 conforms to the device driver standards established for Windows NT:
In Windows NT, NDIS has been implemented in a module called NDIS.SYS, which is referred to as the NDIS wrapper.
The NDIS wrapper is a small piece of code surrounding all of the NDIS device drivers. The wrapper provides a uniform interface between protocol drivers and NDIS device drivers and contains support routines that make the development of an NDIS driver easier.
Previous implementations of NDIS required a Protocol Manager (PROTMAN) to control access to the network adapter. The primary function of PROTMAN was to control the settings on the network adapter and the bindings to specific protocol stacks. Windows NT does not need a PROTMAN module because adapter settings and bindings are stored in the registry and configured using the Network icon in the Control Panel.
Because the NDIS wrapper controls how protocols communicate with the adapter, the protocols communicate with the NDIS wrapper rather than with the network adapter card itself. This is an example of the modularity of the layered device model. The adapter is independent from the protocols; therefore, a change in protocols does not require changing the adapter configuration.
Windows NT ships with four protocols: Data Link Control (DLC), Transmission Control Protocol/Internet Protocol (TCP/IP), NWLink, and NetBEUI.
Unlike the other protocols in Windows NT (NWLink,TCP/IP, and NetBEUI), the DLC protocol is not designed to be a primary protocol for use between PCs. DLC only provides applications with direct access to the data link layer, and thus is not used by the Windows NT redirector. Because the redirector can not use DLC, this protocol is not used for normal session communication between Windows NT computers.
The DLC protocol is primarily used for the following two reasons:
Network-attached printers such as the HP® IIIsi use the DLC protocol because the frames received are very easy to take apart and because DLC functionality can easily be coded onto ROM.
DLC only needs to be installed on computers performing the above tasks and not on the other computers on the network. An example would be a print server sending data to a network HP printer. Client computers sending print jobs to the network printer do not need to be using the DLC protocol; only the print server communicating directly with the printer needs the DLC protocol installed.
The registry location for DLC parameters is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DLC.
TCP/IP stands for Transmission Control Protocol/Internet Protocol and is an industry-standard suite of protocols designed for wide-area networking. It was developed in 1969, resulting from a Defense Advanced Research Projects Agency (DARPA) research project on network interconnection.
DARPA developed TCP/IP to connect its research networks together. This combination of networks continued to grow and now includes many government agencies, universities, and corporations. This global area network is referred to as the Internet.
Windows NT TCP/IP allows users to connect to the Internet as well as any machine running TCP/IP and providing TCP/IP services.
Advantages of the TCP/IP protocol include:
The registry location for TCP/IP parameters is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip.
NWLink is an IPX/SPX-compatible protocol for Windows NT. It can be used to establish connections between Windows NT computers and MSDOS, OS/2, Windows, or other Windows NT computers through a variety of communication mechanisms.
NWLink is simply a protocol. By itself, it does not allow a Windows NT computer to access files or printers on a NetWare server, or to act as a file or print server to a NetWare client. To access files or printers on a NetWare server, you must use a redirector, such as Microsoft's Client Service for NetWare (CSNW) or Novell's NetWare Client for Windows NT.
NWLink is useful if you have NetWare client-server applications that use sockets or NetBIOS over the IPX/SPX protocol. The client portion can be run on a Windows NT computer accessing the server portion on a NetWare server or vice versa. NWNBLink contains Microsoft enhancements to Novell's NetBIOS. The NWNBLink component is used to format NetBIOS-level requests and pass them to the NWLink component for transmission on the network.
The registry location for NWLink parameters is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NWLINK.
NetBEUI stands for NetBIOS Extended User Interface, and was first introduced by IBM in 1985. NetBEUI was developed for small departmental LANs of 20-200 computers. It was assumed that these LANs would be connected by gateways to other LAN segments and mainframes.
The version of NetBEUI shipping with Windows NT is NetBEUI 3.0. It contains the following features:
The registry location for NetBEUI parameters is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Nbf.
Strictly speaking, NetBEUI 3.0 is not truly NetBEUI because it is not inherently extending the NetBIOS interface. Instead, its upper level interface conforms to the Transport Driver Interface (TDI). However, NetBEUI 3.0 still uses the NetBIOS Frame Format (NBF) protocol and is completely compatible and interoperable with previous versions of NetBEUI.
The NetBIOS Interface provides the NetBIOS mapping layer between NetBIOS applications and the TDI compliant protocols.
The NetBIOS Interface component can be configured in the Control Panel Network option.
A LANA number can be explicitly assigned to each network route. The network route is the protocol driver and network adapter that will be used for NetBIOS commands sent to its assigned LANA number.
The LANA number is important for MSDOS NetBIOS applications that are hardcoded to use a specific LANA number for communicating on the network.
In distributed computing, the computing task is divided into two sections, a client piece and a server piece. The goal is to move the actual application processing from the client workstation to a server system with the power to run large applications.
The client piece of a client-server application is typically the user interface for the application. It runs on the client's workstation and uses a small amount of computing power, but typically requires a lot of network bandwidth to communicate with the server piece.
The server piece of a client-server application typically requires large data storage, computing power, or specialized hardware. It includes operations such as database lookups and updates, or mainframe data access.
There must be a network connection between the client and the server portions of distributed applications that allows data to flow in both directions. There are a number of different ways to establish this connection. Windows NT provides several different Interprocess Communication (IPC) mechanisms.
Named pipes and mailslots are actually implemented as file systems. Thus, in the Registry there are entries for NPFS (Named Pipe File System) and MSFS (Mailslot File System). As file systems, they share common functionality, such as security, with the other file systems. In addition, local processes can use named pipes and mailslots with other processes on the local computer without going through the networking components. Remote access to named pipes and mailslots, as with all of the file systems, is accomplished through the redirector.
Named pipes provide connection-oriented messaging that allows applications to share memory over the network. Windows NT provides a special application programming interface (API) that increases security when using named pipes. One feature added to named pipes is impersonation. When using impersonation, the server can change its security identifier to that of the client at the other end of the connection. For example, suppose a database server system uses named pipes to receive, read, and write requests from clients. When a request comes in, the database server program can impersonate the client before attempting to perform the request. Thus, if the client does not have the authority to perform the function the request would be denied.
The mailslot implementation in Windows NT is a subset of the Microsoft OS/2 LAN Manager implementation. Windows NT implements only second class mailslots. Second class mailslots provide connectionless messaging for broadcast messages. Delivery of the message is not guaranteed, though the delivery rate on most networks is high. It is most useful for identifying other computers or services on a network. The Computer Browser service under Windows NT uses mailslots.
NetBIOS is a standard programming interface in the PC environment for developing client-server applications. NetBIOS has been used as an IPC mechanism since the introduction of the interface in the early 1980s. From a programming aspect, higher level interfaces such as named pipes and RPC are superior in their flexibility and portability.
A NetBIOS client-server application can communicate over various protocols: NetBEUI protocol (NBF), NWLink NetBIOS (NWNBLink), and NetBIOS over TCP/IP (NetBT).
The Windows Sockets API provides a standard Windows interface to many transports with different addressing schemes, such as TCP/IP and IPX. The Windows Sockets API was developed to accomplish two things. One was to migrate the sockets interface, developed at the University of California, Berkeley in the early 1980s, into the Windows and Windows NT environments. The other was to help standardize an API for all platforms.
The RPC mechanism can use other IPC mechanisms to establish communications between the computers on which the client and the server portions of the application exist. If the client and server are on the same computer, the Local Procedure Call (LPC) mechanism can be used to transfer information between processes and subsystems. This makes RPC the most flexible and portable IPC choice.
NetDDE provides information-sharing capabilities by opening two one-way pipes between applications. NetDDE is an extension of Dynamic Data Exchange (DDE) that can be used between two computers across the network.
By default, the NetDDE services are not automatically started. They can be started using Control Panel Services, Command Prompt, or the Server Manager utility of Windows NT Server.
In a networked environment, applications may be divided into separate processes that run on different computers. The benefit of RPC, and the real reason for using it, is that RPC allows potentially complex functions to execute on remote (and potentially very powerful) computers. The sharing of the computational burden can significantly speed up some applications, particularly database queries.
RPC is the preferred method for developers to write applications for Windows NT because there's more communication control than with named pipes.
The parts of the remote procedure call mechanism are:
The remote procedure call facility provided in Windows NT is compatible with the Open Software Foundation's (OSF) distributed computing environment (DCE) specification. Windows NT workstations can use RPC to interoperate with any other workstations that support this standard.
The sharing and use of file and print services is accomplished primarily by two services: Workstation (Redirector) and Server. Both the Workstation and Server execute as 32-bit services.
All user mode requests go through the Workstation service. This service consists of two components:
The Workstation service receives the user request and passes it to the kernel mode redirector.
The Workstation service is dependent on the following components:
The redirector is a component through which one computer gains access to another computer. The Windows NT redirector allows connection to Windows NT, Windows for Workgroups, LAN Manager, LAN Server, and other MS-Net servers. The redirector communicates to the protocols via the TDI interface.
The redirector is implemented as a Windows NT file system driver. Implementing a redirector as a file system has several benefits:
Allows applications to call a single API (namely the Windows NT I/O API) to access files on local and remote computers. From the I/O Manager's perspective, there is no difference between accessing files stored on a remote networked computer and accessing those stored locally on a hard disk.
Runs in kernel mode so it can directly call other drivers and other kernel mode components such as the Cache Manager. This improves the performance of the redirector.
When a process on a Windows NT computer tries to open a file that resides on a remote computer, the following steps occur:
Windows NT also includes a component called the server that resides above TDI. Like the redirector, the server is implemented as a file system driver and directly interacts with various other file system drivers to satisfy input/output (I/O) requests such as reading or writing to a file.
The server processes the connections requested by client-side redirectors, and provides them with access to the resources they request. Like the Workstation service, the Server service is composed of two parts:
Server - A service that runs in the SERVICES.EXE process. Unlike the Workstation service, it is not dependent on the MUP service, because the Server is not a UNC provider. It does not attempt to connect to other computers, but other computers connect to it.
SRV.SYS - A file system driver that handles the interaction with the lower levels and interacts directly with various file system devices to satisfy command requests, such as file read and write.
When the server service receives a request from a remote computer asking it to read a file that resides on the local hard drive, the following steps occur:
Applications reside above the redirector and server services in user mode. Like all other layers in the Windows NT networking architecture, there is a single unified interface to access network resources, independent of the redirector(s) installed on the system. This is done through two components: Multiple Universal Naming Convention Provider (MUP) and the Multi-Provider Router (MPR).
When applications make I/O calls containing UNC names, these requests are passed to MUP. MUP selects the appropriate UNC provider (redirector) to handle the I/O request.
The Universal Naming Convention is a naming convention for describing network servers and share points on those servers. UNC names start with two backslashes followed by the server name. All other fields in the name are separated by a single backslash. A typical UNC name would appear as:
\\server\share\subdirectory\filename
Not all of the components of the UNC name need to be present with each command; only the share component is required. For example, dir \\server\share can be used to obtain a directory listing of the root of the specified share.
One of the major design goals for networking in the Windows NT environment was to provide a platform upon which other vendors could build networking services. MUP is a vital part of allowing multiple redirectors to coexist in the computer at the same time. MUP frees applications from maintaining UNC provider listings themselves.
Unlike the TDI interface, MUP is actually a driver. TDI simply defines the way for a component on one layer to communicate with a component on another layer. MUP also has defined paths to UNC providers (redirectors).
I/O requests from applications that contain UNC names are received by the I/O Manager, which in turn passes the requests to MUP. If MUP has not seen the UNC name in the past 15 minutes, MUP will send the name to each of the UNC providers registered with it. (This is why MUP is a prerequisite of the Workstation service. One of the first tasks the Workstation service does during initialization is to register with MUP.)
When a request containing a UNC name is received by the MUP, it negotiates with each redirector to find out which one can process the request. MUP looks for the redirector with the highest registered priority response that claims it can establish a connection to the UNC. This connection remains as long as there is activity. If there has been no request for 15 minutes on the UNC name, then MUP once again negotiates to find an appropriate redirector.
Not all programs use UNC names in their I/O requests. Some applications use WNet APIs (which are the Win32 network APIs). The Multi-Provider Router (MPR) was created to support these applications.
MPR is very much like MUP. This layer receives WNet commands, determines the appropriate redirector, and passes the command to that redirector. Because different network vendors will use different interfaces for communicating with their redirector, there is a series of provider DLLs between the MPR and the redirectors. The provider DLLs expose a standard interface so that MPR can communicate with them, and they know how to take the request from MPR and communicate it to their corresponding redirector.
The provider dynamic-libraries ( DLL) are supplied by the network vendor that wrote the redirector and should be installed automatically when the redirector is installed.
Installation and configuration of Windows NT network components is accomplished using the Network option in the Control Panel. Software can be added, configured, updated, or removed. This is also the place to install drivers for additional network adapter cards.
This dialog box can also be used to change the computer name of the system or the workgroup or domain that the system belongs to.
The Windows NT network architecture consists of a series of layers. The components in each layer provide specific functions to the layers above and below it. The bottom of the network architecture ends at the network adapter card, which moves information between computers.
Binding is the linking of network components on different levels to enable communication between those components. You can bind a network component to one or more network components above or below it. The services each component provides can be shared by all other components bound to it.
When adding network software, Windows NT automatically binds all dependent components accordingly.
To configure the bindings, choose the Bindings button in the Networks option. The Network Bindings dialog box shows the bindings of the installed network components as a series of "bound paths," from the upper layer services and protocols to the lowest layer of network adapter drivers.
Bindings can be enabled and disabled, based on your use of the network components installed on your system.
Bindings can also be ordered to optimize the systems use of the network. For example, if a system has NetBEUI and TCP/IP installed on it and the majority of servers that are connected to it are only running TCP/IP, the Workstation bindings should be examined. In looking at the Workstation bindings, the administrator of this system would want to make sure that the Workstation bound to TCP/IP is the first binding listed, with the Workstation bound to NetBEUI at the bottom. This way, when a user attempts to connect to a server, Workstation will first try using TCP/IP to establish the connection.
Windows NT Workstation installs the following network software components by default:
Windows NT Server installs NetBEUI Protocol in addition to the components installed by default on a Windows NT Workstation.
After you install software for additional network services, such as TCP/IP or DLC and choose the OK button to close the Network Settings dialog box, you may, depending on the driver, be prompted to configure the component.
From the application viewpoint, there are two sets of commands that cause network traffic-any I/O command, such as Open, which contains a UNC name-and WNet commands. UNC commands are sent to the MUP, which is in the Microsoft Windows NT kernel, where it finds a UNC provider or redirector that makes a connection to the specified UNC name. WNet commands are passed to the MPR, which passes the request to each redirector in turn until one is found that can satisfy the request. One computer gains access to another computer by a redirector. Microsoft Windows NT ships with a redirector that allows connection to Microsoft LAN Manager, LAN Server, and Microsoft Networks servers. This redirector communicates to the protocol stacks to which it is bound by the TDI layer. The TDI layer is a boundary layer between the file system modules and the network protocol stacks. Boundary layers are used to provide a unified platform for others to develop "plug-and-play" components. Microsoft Windows NT ships with four protocol stacks: TCP/IP, NetBEUI, NWLink and DLC. NDIS 3.0 provides another boundary layer that makes interoperability between components at different layers easier. In addition to providing file- and print-sharing capabilities, Microsoft Windows NT provides five mechanisms for building distributed applications. Named pipes, mailslots, NetBIOS, Sockets, and RPC can all be used. RPC is the most portable mechanism. RPCs use other IPC mechanisms to transfer functions and data between client and server computers.
This section discusses network interoperability with Microsoft Windows NT and Microsoft Windows NT Server. The focus of this section is interoperability with NetWare, UNIX, and Microsoft LAN Manager.
NWLink is an IPX/SPX-compatible transport protocol for Windows NT. It can be used to establish connections between Windows NT computers and either MSDOS, OS/2, Windows, or other Windows NT computers via RPC, Sockets (either Windows Sockets or NetWare® sockets), or Novell® NetBIOS. It does not, however, allow a Windows NT computer to connect to a Novell NetWare server or to act as a server to a Novell NetWare client. To connect to a Novell NetWare server, you need to purchase Novell's NetWare Client for Windows NT or you need the Client Services for NetWare.
NWLink is useful if you have NetWare client applications that use the IPX/SPX API or if you have applications which use NetBIOS or Novell NetBIOS. NWLink can also serve as the protocol used by the default redirector and server for Windows NT and Windows NT Server.
User-mode applications can use RPC, NetBIOS APIs, or Windows Sockets APIs to access the network through NWLink or other IPX/SPX protocol drivers. Both NetBIOS and Windows Sockets are supported in the Windows 32-bit, Windows 16-bit, and MSDOS environments. Programs that run in the OS/2 environment can use NetBIOS but not Windows Sockets APIs. All subsystems and VDMs can use logical drives that are established by the redirector via NWLink.
Microsoft's Client Services for NetWare allows Microsoft Windows NT workstations to access files, directories, and printers on Novell NetWare servers.
Because CSNW uses the IPX protocol, NWLink transport must be installed before you install CSNW.
GSNW is a 32-bit Windows NT service equivalent to the NetWare requestor. It allows Windows NT servers to access files, directories, and printers on Novell NetWare servers, and also to transparently pass those resources on to clients on the Windows Network.
GSNW allows users to connect to what appear to be NT Server resources, but which in reality are resources that exist on a NetWare server connected with the Windows NT network. This capability allows Windows NT Server to act as a nondedicated gateway to NetWare file systems for any SMB (Server Message Block) client (including Windows for Workgroups, Windows NT, and MSDOS clients under LAN Manager).
The next area we look at is interoperability with UNIX servers. There are three flavors of communications with UNIX hosts. There are the "ARPA Services" and the "Berkeley Services." Some may view this as "native" UNIX communications. The other is communicating with UNIX servers running LAN Manager for UNIX. We look at both in the context of the TCP/IP transport protocol. Some UNIX systems can support the NetBEUI protocol stack, but this is not a common installation.
We have already seen some of the components of TCP/IP in our discussion of the Microsoft Windows NT architecture. TCP/IP is made up of a number of different protocols that interoperate to provide network services. Microsoft Windows NT does provide IP support. IP is a "connectionless" oriented protocol with no guaranteed delivery. The ARP protocol is supported for address resolution within the local area network. ICMP (Internet Control Message Protocol) is support for such activities as ECHO (commonly known as PING). Above IP there is support for the UDP protocol. User Datagram Protocol is also a connectionless protocol and is supported by the Sockets interface. TCP (Transmission Control Protocol) is a connection-oriented guaranteed delivery protocol. It too is supported by the Socket programming interface.
Building on the lower-level protocols provided, Microsoft Windows NT also supplies a number of application utilities. The File Transfer Protocol (FTP) utility is a full, 32-bit implementation. Microsoft Windows NT provides the FTP client and FTP server. Thus, Microsoft Windows NT can use FTP to transfer files with a UNIX server, and a UNIX workstation can use FTP to transfer files with a Microsoft Windows NT server. In addition to FTP, Microsoft Windows NT also provides Trivial File Transfer Protocol (TFTP). TFTP copies files but doesn't perform access-control checking, and it uses UDP rather than TCP as the underlying protocol. Telnet provides a virtual terminal service for remote interactive sessions. Basic terminal emulation of TTY (scrolling), VT-100 (ANSI), and VT-52 terminals are supported. This allows a user to make remote connections with UNIX systems that are running the Telnet server component. Microsoft Windows NT does not supply a Telnet server component. Simple Network Management Protocol (SNMP) is supported by Microsoft Windows NT. Management Information Blocks-II (MIB-II) and the LAN Manager extension MIBs are fully supported. MIBs for DHCP and WINS are also included. Here, Microsoft Windows NT is simply an SNMP agent. Finally, Microsoft Windows NT supplies a Domain Name Resolver (DNR) for resolving names.
The Berkeley services are extensions to the ARPA services, which were added by work done at the University of California at Berkeley. Remote Copy (RCP) may be used to copy files to and from remote UNIX systems and between two remote UNIX systems. Local copy through RCP is not supported. Also the -p option (preserve timestamp) is not supported in the Microsoft Windows NT version. Remote Shell (RSH) allows a user to establish a session with a host computer. RSH supplies only the user name for validation on the remote host. Remote Execute (REXEC) allows a user to execute commands on a remote host and prompts for and sends a password in clear text for remote authentication.
Microsoft Windows does provide a sockets programming interface, called Windows Sockets, which is a definition of the sockets' interfaces defined by a committee of TCP/IP on Windows providers (including Microsoft). The programming interface is virtually identical to the existing sockets API set defined by UC Berkeley. Modifications allow for the nonblocking activities needed to support the Microsoft Windows messaging paradigm. Windows Sockets is supported in all sub-systems, thus an MSDOS, Win16, Win32, or POSIX program can all make Windows Sockets calls and reach the TCP/IP protocol stack. XTI (X/Open Transport Interface) is an up-and-coming API interface for applications to access the transport layer of protocol stacks. Microsoft Windows NT does not currently support the XTI API set, however, it is identified as a future enhancement.
From a networking standpoint, Windows NT Server provides the domain security components on top of the existing resource-sharing facilities of Microsoft Windows NT. The domain concept of Microsoft® LAN Manager has been expanded to allow domains to "trust" each other. In addition to the additional network components, fault-tolerance features needed by servers have been included. These features include support for the UPS service, disk mirroring and duplexing, and parity-stripped volumes.
Microsoft Windows NT Server can be added to LAN Manager for OS/2 environments. In a domain situation, the Microsoft Windows NT Server computer must be the primary domain controller. The LAN Manager for OS/2 servers is able to receive security database changes. In addition, the LAN Manager for OS/2 servers will be able to receive file replication from information from the Microsoft Windows NT Server computer. MSDOS, Windows, Microsoft Windows™ for Workgroups, and LAN Manager for OS/2 workstations continue to use the LAN Manager server for logon services.
This section discusses the concept of domains and trusted domains. A domain is a group of Microsoft Windows NT Server computers (and LAN Manager 2.x servers) that work together to form a single security image. The user and group accounts within the domain is handled as a single entity. The concept was initially introduced with LAN Manager and has been carried forward into Microsoft Windows NT. Trusted domains are a new concept added to domains. Microsoft Windows NT Server has the ability to link domains to create even larger user and group structures for large enterprise deployments.
At least one Microsoft Windows NT Server computer is required to establish a domain. A domain may be a mixture of Microsoft Windows NT Server computers (configured as domain controllers or file/print/application servers), Microsoft Windows NT Workstation computers, LAN Manager 2.x servers, and workstations. There are three types of servers within a domain: the primary domain controller (PDC), the backup domain controllers (BDC), and file/print/application servers. In a mixed Microsoft Windows NT and LAN Manager environment, a Microsoft Windows NT Server computer must be the PDC. The identity of the PDC is not important because the User Manager for Domains administration tool locates the PDC automatically. The PDC holds the master copy of the user database and security policies. The BDCs hold copies of this security information which can be configured to update at regular intervals. Both the PDC and BDCs are used to validate users logging on to the network. The allocation is done on a load-balancing arrangement.
Each valid user within a domain has a User Account in the user account database. Accounts can be collected into larger structures called groups. Within a Microsoft Windows NT domain there are two types of groups: local groups that give access to resources on the domain servers and global groups that allow users to access resources in this and other domains. The "scope" of each type of group is a key concept to understand. The name of the group refers to where the group is used. Global groups can be thought of as export groups as these can be exported to other domains. Local groups can be thought of as import groups as these can include global groups from other domains and define permissions for resources only within the domain it is defined in. The type of network and the account's role in the network determine which type of account the administrator should create.
Many networking solutions have incorporated varying forms of user accounts as a method of providing logon access to resources. However, as the complexity of local area networks has increased, it has become increasingly difficult to manage these user accounts. Even today, some networking environments force the administrator to establish separate user accounts on each server where a user needs access. To simplify user administration, Windows NT Server provides group accounts. Adding a user to a predefined group provides the user with all access rights and privileges of that group. Changing access rights becomes a very simple task because changing the rights of the group will automatically change the rights of all group members. Contrasting this with an administration model where each individual account needs to be changed shows how groups provide a very flexible and easy-to-use tool for administrators.
A global group may only contain user accounts that are locally defined in the domain in which the global group exists. Using trust relationships (discussed below) users within a global group can access resources outside their locally defined domain. Global groups are therefore suitable for large, multidomain networks. They are a programmatic method of providing an inclusive list of all user accounts within a domain that require a particular type of access to resources that exist within another domain.
As mentioned previously, local groups can be considered as import groups, which define permissions to resources only within the domain in which the local group exists. Hence the term "local" defines the scope of the resource permissions granted to users within the group. Local groups may contain users and global groups from the local domain (but not other local groups), as well as users and global groups from trusted domains. However, a local group can only be assigned permissions and rights in its home domain.
Not only are local groups an effective way of collectively assigning user rights and permissions for a set of users within the home domain, but they can be used to gather numerous global groups and users from other domains. This allows an administrator to globally change access to domain resources with a single modification to the local group permissions.
Domains provide a centralized method of administering groups of workstations and servers, thus simplifying the administrator's management tasks. But if an environment requires multiple domains, a user needing access to a broad range of resources would require a separate user account in each domain. This would also force the user to log on separately into each domain where the required resources existed. All of these additional user accounts would greatly add to the complexity of the administrator's job of maintaining appropriate user access and privileges. Windows NT Server has resolved this problem with "trust relationships."
Trust relationships are an administration and communications link between two domains. A trust relationship between two domains enables user accounts and global groups to be used in a domain other than the domain where these accounts are actually defined. Domains use established trust relationships to share account information and validate the rights and permissions of users and global groups residing in the trusted domain. Trusts therefore simplify administration by combining two or more domains into a single administrative unit.
The design of the trust relationships between domains should be planned before the deployment of Microsoft Windows NT Server to ensure that it is done correctly the first time. There are four domain models that can be implemented as is or modified to suit specific needs. The first is the single domain model; here, there is only one domain with no other domains and so no trust relationships. The size of such a domain should be kept relatively small, in hundreds of workstations, for example.
The next deployment strategy is called the master domain model. Here, a single domain is trusted by all other domains in the enterprise. Users and groups are created on the master domain and permissions are granted in the smaller domains. This strategy works best in an environment with a strong centralized security or operations group. It should, however, be limited to about 15,000 users and groups in the enterprise for performance and capacity reasons.
For more than 15,000 users, the multiple master domain model can be created. With this model, there are multiple master domains trusting each other. Departmental domains have a trusting relationship with each of the master domains.
The final strategy is the complete trust model. Here there are no centralized master domains, and each departmental domain has a two-way trust relationship with each of the other domains. This works well when no centralized authority exists in the enterprise. The number of relationships can grow very quickly, however-20 domains requires 380 trust relationships.
The correct strategy for your environment greatly depends on the number of computers and users, geographic layout of the computers, and the internal infrastructure available to support it. The key is to plan your strategy.
There are some special considerations when building mixed LAN Manager and Microsoft Windows NT domains. As stated earlier, the Microsoft Windows NT Server computer must be the PDC in the domain. The user security information is replicated on the LAN Manager servers, and they can continue to validate user logons. However, the LAN Manager does not support the concept of local groups, only global groups. Thus, any local group definitions defined in the Microsoft Windows NT Server computer will be lost when replicated to the LAN Manager servers.
Remote accounts allow for greater access in mixed Microsoft Windows NT domains and LAN Manager environments. First, it allows users from other Microsoft Windows NT domains (trusted) to gain access to resources on LAN Manager servers in a domain. It allows users whose home domain is a LAN Manager domain to gain access to resources in this domain. Remote accounts can participate in global groups, however, they are not part of the trust relationship. This means that the remote access user ID must be defined in each domain that contains resources it wishes to access.
To grant privilege to a file on a LAN Manager 2.x server within a Microsoft Windows NT domain to a user in a trusted domain, a remote account for that user is first created in the domain containing the LAN Manager 2.x server. The remote account is then placed in a global group (this is optional but makes migration to an all-Windows NT environment easier later on). The file permission is then granted to the global group.
To grant privilege to a file on a Microsoft Windows NT server in a Microsoft Windows NT domain to a user defined in a LAN Manager 2.x domain, a remote account for that user is first created in the Microsoft Windows NT domain. The remote account is then placed in a local group (this is optional but makes migration to an all Microsoft Windows NT environment easier later on). Then the privilege to the file is granted to the local group.
There are five different mechanisms available to provide fault tolerance: UPS services, tape backup, disk mirroring, disk duplexing, and striping with parity. In addition to the disk mechanisms for fault tolerance, there are two additional disk organizations available to Windows NT, volume sets and striped without parity sets. All of these mechanisms are discussed in this section.
There is an old Canadian folk song that says: "... you don't know what you got 'til its gone." This is the value of a file. What will it cost your organization if the file is lost? This is the flip side of the security question: What is the cost if a file is read or manipulated by the wrong person? The costs may be tangible or intangible. For example, if a word processing file containing a memo about the company picnic five years ago is lost, the cost could be zero. If the memo was for this year's picnic, the cost would be the labor cost of re-entering. If the memo was a response to a bid that is due tomorrow, the cost becomes time-sensitive. The momentary cost is the cost of labor, but the real cost is the profits of the contract, if the file cannot be re-entered in time to make the bid closing. Fault tolerance and data recovery is about minimizing the cost of lost data, while attempting to limit the cost of resources needed.
Many tools can be used to minimize the cost of lost data. These tools are UPS, tape backup, disk mirroring, disk duplexing, and striping with parity.
Unlike LAN Manager for OS/2, uninterruptible power supply (UPS) services are supported by both Microsoft Windows NT Workstation and Microsoft Windows NT Server. UPS systems allow the computer to continue to function from battery reserves for a short period of time in the event of a power failure. They also protect from both power sags (brown outs) and spikes (typically experienced when the power returns). The UPS services provided with Microsoft Windows NT is sensitive to signals from the UPS unit and performs orderly shut downs of applications, services, and file systems if the UPS power is depleted. The UPS services is built into the base operating system itself. This allows it easier access to the file systems in the event of a power problem.
UPS provides two levels of protection. First, it keeps the computer active during power outages of short or medium durations. This allows the computer to continue processing data without loss of time. It also allows the computer to be shut down in an orderly fashion before the battery power is fully depleted. The main advantages is to allow the file system to flush its internal cache buffers to the disk before the power to the computer is lost.
As with other components in a distributed system, connectivity during a power outage is only as good as the weakest chain. Placing a UPS unit on a computer keeps that computer up and active. If the computer is a server, then the server remains up. If the computer is a workstation, it remains active. However, if there are no UPS devices on hubs, concentrators, routers, or bridges, the workstation and the server may still be unable to communicate. Planning which pieces of the environment should be protected by a UPS device depends on the expectation of its use. If the UPS is used only to prevent data lost at the server, then placing a UPS system only on the server is enough. If the expectation is to be able to continue with business at some level, then having some number of workstations and printers on UPS may also be needed. If there are electrically active components in the network, they too may have to be on a UPS to accomplish the business goals during power outages.
All power is run through the UPS system, where the battery is constantly being charged. When there is a sag or a power failure, the battery automatically begins providing power to the computer and the appropriate communications line is raised. This alerts the UPS Service to take the appropriate action based on the configuration. Within the UPS industry there is a standard for connecting UPS units to a Com port on a computer; this connection has 3 pins. The actual pin depends on the type of connector used (DB-25 or DB-9). Pins are "signaled" when a problem is detected. Signaling can be either setting the pin high (from its normal low state) or setting the pin low (from its normal high state) depending on the needs of the UPS device being used. The CTS pin (five on a DB-25 or eight on a DB-9) is used to signal a power failure. When the power coming into the UPS device is lost or sags below a threshold, this pin is signaled. The DCD pin (eight on a DB-25 or one on a DB-9) is signaled when the battery is about to run out of power. When this pin is signaled, Microsoft Windows NT expects to have two minutes to perform the needed shutdown activities. Finally, the UPS service can communicate with the UPS device through the DTR pin (20 on a DB-25 or four on a DB-9). This pin is signaled to inform the UPS device to shut down. Two other pins provide for support of contact-closure type UPSs.
The UPS control panel controls the configuration of the interface between the UPS device and the UPS service. The UPS service is selected for execution by the check box at the top of the screen. It says "installed," but it is always installed, and is really marked for automatic startup during the boot sequence. The Com port is selected from the list box. The signals generated by the UPS and the values on those pins to indicate signaling is provided. If the UPS device can generate the power failure signal, then certain additional characteristics can be entered. First is the life expectancy and the battery recharge time. This informs Microsoft Windows NT of the time the battery can be expected to keep the system up. This also informs it of the amount of time it takes to recharge the battery to that level. These fields are not enabled if the UPS has a low battery signal because the UPS device can inform the UPS service directly. If the UPS can signal immediately that there was a power failure, it is advisable that someone be alerted to the problems. The time between the power failure and the initial alert can be set. Thus, if the power failure is of a short duration, no error messages are generated. If the power failure is persistent, the frequency of additional warning messages can be set.
The first time the UPS service is activated, it is marked as an automatically started service. The UPS service does not start the UPS at that time. The UPS control panel prompts the user to start the service by way of the service manager control panel. The system does not have to be rebooted to start the service. Once the service is marked as automatic, it is started during subsequent system boots.
The actual UPS service itself runs as a background task. When the power failure pin is signaled, the initial warning timer is started. If the pin is not "unsignaled," the timer expires and the initial warning message is sent. This message tells the user a failure has occurred and it is now running on backup. When the low battery pin is signaled, or when the life expectancy of the battery has expired, the system automatically begins shutdown procedures.
The first line of defense for fault tolerance is a good tape-backup scheme. Microsoft Windows NT provides a full-function, tape-backup system based on the Maynard tape system. This is a departure from the Sytos OS/2 tape system due to internal limitations imposed by the Sytos system. However, tapes prepared by the Sytos system are readable by Windows NT.
Many tape strategies are available; the correct one for you depends on the volume of data you backup and the frequency of modifications made to the files. There are three types of schemes. Normal backups always copy the selected files and mark each file as having been backed up. This gives you the ability to restore files quickly from the most recent tape. However, this increases the time to make the backups, since even files that have not changed since the last backup are written to the tape. Incremental backups only back up files that have been changed since the last normal or incremental backup. Each file is marked as backed up once copied. This saves time during the backup process. If you combine normal backups with incremental backups, restoring requires starting with your last normal backup and working forward through all the incremental tapes. The last scheme is differential backups. Differential backups back up only those files that have been changed since the last normal or incremental backup. The difference is that the files are not marked as backed up. Combining normal backups with differential backups means that restoration needs only the last normal backup and the last differential.
Rotating sets of tapes used during the backup process is a common practice. It helps reduce the cost of tape backup by reusing tapes over and over again. One of the most popular tape rotation schedules is one that uses 19 tapes over the course of one year. This schedule uses four tapes Monday through Thursday. These are incremental or differential backups. Every Friday a normal backup is created. The tapes used Monday through Thursday are used over and over again. The Friday tapes are kept during the month. On the last Friday of each month, two normal backups are created. One stays in the monthly rotation, the other goes to off-site storage. The tapes in off-site storage stay for one year and rotate back into the cycle to backup the same month they were used for last year. Rotation schemes are as individual as the needs of the organization. Compared to the cost of recovering data, tapes are inexpensive.
With the new tape system there is some new terminology. A backup set is the set of files, directories, or drives selected for a single backup operation. The family set is the set of tapes the backup set resides on. The term is functional for backup sets that require one or more tapes, though usually it is not used unless more than one tape is involved. Information describing the backup set is stored in the catalog. The catalog is always stored on the last or only tape in the family set.
Tape backup and restore are special events with special permissions. Users with read and write permissions may certainly back up and restore certain files. Quite often, however, there is a special user known as the tape operator or backup operator who is called on to interact with the tape. The tape operator (known in Microsoft Windows NT as the Backup Operator) has the privilege to back up and restore files that they do not have read or write permissions to. Users are designated as tape operators by adding their user ID to the Backup Operators group.
Peer services greatly ease the burden of backing up remote computers. If the computer is Microsoft Windows NT or Microsoft Windows for Workgroups, a centralized backup server can backup up remote computers simply by establishing a net use session and backing up the files using the redirected drive letter. The shared directory on the remote computer may be either an entire drive or a subdirectory. If the remote computer does not have sharing capabilities, then the workstation must establish a relationship with either the backup server or some other server. Once the net use has been established, the workstation copies the data to the server. Once on the server, the backup server may either back up the data from a local disk or establish a relationship with the intermediary server and back up the data.
All the tape backup activities are done through the tape backup utility. This is a very simple user interface. Simply click the files you wish to have backed up and select the backup options. The backup dialog screen allows you to specify a tape name, backup set description, and the type of backup. The type corresponds to normal, incremental, or differential options described earlier. The backup can also produce a log of all tape activities.
After selecting which tapes, backup sets, or files to restore, choose the Restore command to open the Restore Information dialog box. The first section provides information about the backup sets. For each backup set you must specify the drive to which you want the information restored. You may also specify an alternate directory path. As with backup, a log is maintained.
Tapes not only make good backup and recovery media, they also make excellent data-transfer facilities. Consider the following problem: Your organization has two sites across town or in adjacent towns. On a daily basis site A has 500MB of data to send to site B. The low-entry cost solution would be to use switched-line modems, say 19,200 bps. It would take (assuming the line stayed up) 7.6 hours a day to transfer the data. A courier with a tape could be across town in an hour in even the worst traffic.
Depending on your organizations, electronic data processing (EDP) auditing requirements or laws and the regulations of your industry, you may be required to keep a set of backups off-site. This allows your organization to pick up the pieces in the event of a catastrophe such as a fire, earthquake, or severe weather. In addition, tapes will most likely play a key roll in re-establishing a disaster recovery site. Here, a site away from a normal operational site is prepared with the equipment needed to run the organization. In the event of a disaster, which cripples the normal operational site, the last tape backups are loaded at the recovery site and the organization continues processing. If disaster recovery procedures are mandated or expected, they should be practiced regularly to ensure the current staff is well-trained.
Before we get into disk fault tolerance, there are some key terms to know. RAID stands for Redundant Arrays of Inexpensive Disks. Initially put forth in 1987 by Patterson, Gibson, and Kratz of the University of California at Berkeley, their research attempted to draw together various options for building virtually large drives from smaller inexpensive drives. This is counter to the SLED (Single Large Expensive Disk) concept commonly used on mainframe and mini computers. The paper establishes five different schemes for deploying disks. It is a common mistake to think one builds on top of another. Each has their advantages and disadvantages. RAID 0 has since been added by the industry to represent striping without parity, known in Microsoft Windows NT as striped sets. RAID 1 represents disk mirroring. RAID 5 represents striping with parity. Microsoft Windows NT supports RAID 0, 1, and 5 with an additional variant of RAID 1 in disk duplexing.
We also want to make the differentiation between a disk, a drive, and a partition. A disk is a physical component of hardware. It may be divided into one or more partitions that are logical subsections of the disk. A drive is one or more partitions logically associated to a single system identifier (drive letter). A drive may also be the logical association of a single system identifier (drive letter) to a network share point. This is a redirected drive. A fair number of computers have one hard disk with one partition and a single drive C:. Microsoft Windows NT can still do this, but it can do so much more.
There are two special types of partitions in Microsoft Windows NT: the boot partition and the system partition. The system partition is the partition that the ROM BIOS selected to begin loading the computer's operating environment from. This is also referred to as the active partition in programs such as Fdisk. The boot partition is the partition containing the Microsoft Windows NT system being booted. This is the partition BOOT.INI file points to. This file is sometimes called the SYSROOT in reference to the internal environment variable, which points to this path. In Microsoft Windows NT, the boot partition and the system partition can be the same, on different disks, and on different controllers. They may be FAT, HPFS, or NTFS. However, they may be mirrored or duplexed. They may not be striped, parity striped, or volume sets.
Disks are handled differently in Microsoft Windows NT than in other system. In Microsoft Windows NT, each disk is given a unique signature. This signature is stored in the Master Boot Record area on the disk (physical sector 0) and used by Microsoft Windows NT to identify disks. It allows disks to be moved from controller to controller or within a SCSI chain without problems. The signature is used to look up the disk and the partitions on those disks in the Registry. In the Registry there is an entry called DISK, which informs Microsoft Windows NT of the participation of each partition on each disk. This eliminates reliance on hidden information on the disk. It does, however, present a minor problem.
The DISK information is stored in the Registry. But the Registry is overwritten when a new version of Microsoft Windows NT is installed. The Disk Administrator has provided a simple solution to this problem. Under the Partition menu option is an entry called Configuration with three sub-options: Save, Restore, and Migrate. Save allows you to save the DISK information to a floppy disk. It does this by saving a current copy of the system component of the Registry. Restore allows the DISK information to be restored from this disk. Migrate is used if the SYSTEM file from the previous version of Microsoft Windows NT is available on disk. The current disks are scanned for previous version(s) of Microsoft Windows NT, and the user is allowed to select from which director to load the DISK information. Only the DISK information is loaded from the old SYSTEM file.
A quick comment on Disk Administrator. Activities done in the Disk Administrator such as creating or deleting partitions, breaking mirrors, and building sets, are not committed to the disks until you attempt to exit Disk Administrator. The user is given one last chance at this point to confirm that the modifications are correct.
Disk mirroring protects against hard disk failure by using two partitions on different drives connected to the same disk controller. All data on the first (primary) partition is mirrored automatically onto the secondary partition. Thus if the primary disk fails, no data is lost. The partition on the secondary disk is used. Mirroring does not have to be done at the drive level. Thus, unallocated space on the primary drive can be allocated into a logical drive, as can any unallocated space on the secondary drive. With disk mirroring both partitions have the same drive letter. The user should not be aware of the mirrored disk. Disk mirroring is supported in Microsoft Windows NT Server.
Any file system can make use of disk mirroring, FAT, HPFS, or NTFS. Mirroring is not restricted to a partition of identical geometry to the primary partition (size, number of heads, cylinders, tracks, sectors). This eliminates the problem of acquiring an identical model drive to replace a failed drive when an entire drive is being mirrored. For practical purposes the mirrored partitions are usually created to be the same size as the primary partition. The mirrored partition can't be smaller. If the mirrored partition is larger than the primary, the extra space is wasted.
Disk duplexing is simply a mirrored pair with an additional adapter on the secondary drive. This provides fault tolerance for both disk and controller failure. The use of multiple adapters connecting to one drive is not supported. In addition to providing fault tolerance this also has the potential to improve performance. Duplexing is also performed at the partition level. From the standpoint of Microsoft Windows NT, there is no difference between mirroring and duplexing. It is simply a matter of where the other partition can be found.
Creating mirrored sets and duplex sets is identical. The Disk Administrator utility is used. Select the partitions that you want to duplicate and an area of free space of the same size or greater on another hard disk. This is done by selecting the partition to be mirrored, and then selecting the free space on another disk while holding down the Ctrl key. From the Disk Administrator menu, select the Fault Tolerance menu option. Then choose Establish Mirror. The Disk Administrator creates an equal-size partition in the free space for the mirror and assigns the drive letter to the set.
Disk Striping with parity is based on concepts put forth in RAID 5. Here a number of different partitions on different disks are combined to make one large logical drive. The partitions are used and arranged to ensure multiple single points of failure in the array. Disk striping with parity is only supported in Microsoft Windows NT Server. There must be at least three disks and no more than 32 disks in a striped set. A partition of approximately the same size must be selected from each disk. The disks may be on the same or on different controllers. Small computer system interface (SCSI) disks are best, because advanced recovery features, such as bad block remapping, can be used during the recovery process. Data is written in stripes across all partitions in the set. In addition to the data, a parity stripe is interleaved with the data stripes. The parity stripe is simply a byte parity of the data stripes at a given stripe level or row. Assume you have five disks in the striped set. At level 0, you have stripe block 0 on disk 0, 1 on 1, 2 on 2, and 3 on 3 and the parity (exclusive OR) of the stripe blocks on disk 4. The size of the stripes (striping factor) is currently 64K. The size of the parity stripe is the size of the data stripes. On the next row, the parity stripe is on disk 0. Data is on the rest of the disks. Because the parity stripes are not all on the same disk (as in RAID 4) there is no single point of failure for the set.
When using any of the fault-tolerant disk schemes, Microsoft Windows NT uses a device driver called FTDISK.SYS to receive commands and respond appropriately, based on the type of fault tolerance that is being used. Thus, when the file system generates a request to read a given section of a file, the normal disk system receives the request from the file system and passes it to the FTDISK.SYS driver. This driver then determines the stripe the data is in. From this and the information on the number of disks in the set the disk and location on the disk is located. The data is read into memory. Striping can actually increase read performance because each disk in the set can have an outstanding read at the same time.
Writing to a parity-striped set is a little more difficult. First, the original data from the stripe that is to be written must be read along with the parity information for that stripe level. The differences to the parity information are calculated and added to the parity stripe. Finally, both the parity and the new information are written to disks. The reads and the writes can be issued concurrently since they must be on different disks by design.
There are two general cases of fault tolerance with parity striping. A data stripe is no longer readable. Even though the data stripe is no longer readable, the system may still function. When the bad data stripe is to be read, all of the remaining good data stripes are read along with the parity stripe. Each data stripe is subtracted (XORed) from the parity stripe, and the order isn't important. The result is the missing data stripe! Writing is a little more complicated but works very much the same way. All the data stripes are read and backed out of the parity stripe, leaving the missing data stripe. The modifications to the parity stripe can now be calculated and made. Because the system knows the data stripe is bad, it is not written-only the parity stripe.
The other general case is the loss of a parity stripe. During data reads, this does not present a problem. The parity stripe is not used during normal reads. Writes become much less complicated as well. Because there is no way to maintain the parity stripe, the writes behave as a data stripe without parity. The parity stripe can be recalculated during regeneration.
Error detection and recovery are similar both for mirrored sets and for parity-striped sets. The exact system response to the problem depends on when the problem occurred. A broken set occurs any time a partition in a mirrored or duplexed set cannot be written or any time a stripe cannot be written. When an I/O error is first detected, the system attempts some things to keep the set from breaking. The primary function is to attempt to reassign the sector that failed. This is done by issuing a command to remap the sector to the disk. This is why SCSI works better for fault-tolerant devices. Some ESDI devices also support the concept of remapping, but there is no standard for the command. Microsoft Windows NT attempts remapping only if the disk is supported by a SCSI controller. If the disk does not support sector mapping, or if the other attempts to maintain the set fails, a high-severity error is logged to the event log. The failed partition is called an orphan. It is important to note that the process of orphaning a partition does not occur during a read, only during writes. This is because the read can't possibly affect the data on the disks, so performing orphan processing would be superfluous.
During system initialization, if the system can't locate each partition in a mirrored set, a severe error is logged in the event log and the remaining partition of the mirror is used. If the partition is part of a parity striped set, a severe error is logged in the event log and the partition is marked as orphan. The system continues to function using the fault-tolerant capabilities inherent in such sets. If all of the partitions within a set cannot be located, the drive is not activated, but the partitions are not marked as orphans. This saves the recovery time of simple problems like disconnecting the SCSI chain from the computer.
The system continues processing until a replacement disk or partition is available to recover from the problem and to ensure fault tolerance again. A set with an orphan is not fault tolerant. Another failure in the set can likely cause the loss of data. Recovery should be done as soon as the problem has been discovered.
Recovery of a orphan mirror is done in a number of steps. First, break the mirror set relationship using the Break Mirror option within the Disk Administrator utility. This converts the remaining active partition of the set into an "normal" partition. This partition receives the drive letter of the set. The orphan partition receives the next available drive letter. You can then create a new set relationship with existing free space on another disk in the local computer or replace the orphan drive and re-establish the relationship with space from this disk. Once the relationship has been established, the system can be restarted. During the system initialization, the data from the original good partition is copied over to the new mirrored partition.
When a member of a parity-striped set is orphaned, it can be regenerated from the remaining data. This uses the same logic (discussed earlier) for the dynamic regeneration of data from the parity and remaining stripes. Select a new, free space area that is as large as the other members in the set, and then choose the Regenerate command from the Fault Tolerance menu. When the system is restarted, the missing stripes are recalculated and written to the new space provided.
Disk volumes (disk spanning) are not a fault-tolerance strategy. It is simply a way of combining multiple partitions into a single, logical disk. This does not increase disk performance. Volume sets are created using the Disk Administrator utility. Select the first free partition, then hold down the Ctrl key and select the others. Then select the Create Volume Set option from the Partition menu. Once a volume set has been created, it can also be extended using the Create Extended Volume Set. Only volume sets formatted with NTFS can be extended. A volume set cannot contain mirrored or striped components in it composition.
Disk Striping (Raid 0) is exactly like disk striping without the parity stripe. Because the parity stripe is not present, the set is not fault tolerant. Once a stripe has been lost, there is no way to recover it. Some disk drivers do provide in-drive, hot-fix capabilities that can help ensure the safety of the data. Disk striping can, however, increase both read and write performance, because multiple I/O commands can be active on the drives at the same time. A striped set must have between two and 32 disks. If the disks are different sizes, the smallest is used as the common partition size. The remaining free space may be used individually or in a volume set. Creation of a striped set is done via the Disk Administrator utility. Select the disks for the set and select the Create Stripe Set option under the Partition menu.
Volume and striped sets are not fault tolerant. Once an error is detected, the set is not recoverable. If the problem is detected during system initialization, a severe error is logged to the event log and the volume set or striped set is not available for use by the system.
© 1995 Microsoft Corporation.
THESE MATERIALS ARE PROVIDED "AS-IS," FOR INFORMATIONAL
PURPOSES ONLY.
NEITHER MICROSOFT NOR ITS SUPPLIERS MAKES ANY WARRANTY, EXPRESS
OR IMPLIED WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE
ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO
NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION
MAY NOT APPLY TO YOU.
NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR
ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL INCIDENTAL, DIRECT,
INDIRECT, SPECIAL, AND LOSS PROFITS. BECAUSE SOME STATES/JURISDICTIONS
DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES
THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT'S
AND ITS SUPPLIERS' ENTIRE LIABILITY IN ANY MANNER ARISING OUT
OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE SHALL
NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |