Windows NT is, first and foremost, a general-purpose computer operating system for business use. Although this book concentrates on the networking features of Windows NT Server 4.0, Windows NT is equally at home running heavy-duty workstation applications, such as computer-aided design of aircraft components or non-linear video editors and animated graphics applications for producing broadcast television programs.
The Workstation and Server versions of Windows NT 4.0 share a common source code base; the network management and application server features of Windows NT Server 4.0 are modular components added to the basic operating system modules of Windows NT Workstation 4.0. Thus, the underlying architecture of Windows NT differs markedly from dedicated network operating systems, such as Novell NetWare and Banyan VINES, that concentrate on file and printer sharing.
Windows NT was designed from the ground up as an application server for 32-bit Windows programs; this contrasts with NetWare, which initially gained application services in the form of an add-in to support custom-programmed NetWare Loadable Modules (NLMs). The architecture of Windows NT closely resembles that of UNIX, with some added features derived from Digital Equipment's VMS operating system.
Unlike other versions of Windows (including Windows 95), Windows NT isn't encumbered with the baggage of backward compatibility obligations to the installed base of low-end PCs designed to run 16-bit Windows and DOS applications. Windows NT 4.0 doesn't accommodate 16-bit device drivers for adapter cards and other hardware accessories, nor does it support the Plug-and-Play hardware standard of Windows 95.
Windows NT 4.0 also isn't optimized for mobile PCs and isn't designed to run computer games; Microsoft has positioned Windows 95 as the operating system of choice for laptop and notebook PCs, as well as personal entertainment applications. Microsoft explicitly designed Windows NT from the ground up for use in corporate and institutional computing environments ranging from small-business LANs to global WANs.
This chapter covers the following topics:
An understanding of the internal complexities underpinning the Windows NT operating system isn't an absolute necessity in order to plan, budget, set up, and administer a Windows NT network. Windows NT's server-related application programming interfaces, as an example, primarily are of interest to programmers writing specialized server-based applications, such as tape backup utilities. On the other hand, gaining a working knowledge of Windows NT architecture is quite useful when evaluating tradeoffs between software and hardware implementations of Windows NT Server functions, such as Remote Access Services and Multiprotocol Routing. If you're familiar with Windows NT architecture and terminology, you're also better prepared to discern between facts and propaganda in vendor specifications and consultant recommendations. Thus, this chapter appears immediately before the chapters related to choosing network protocols and buying networking hardware.
Windows NT is the result of a schism between Microsoft and IBM in their joint development program for OS/2 Presentation Manager. In October 1988, Microsoft hired David N. Cutler, the architect of Digital's VMS operating system for its VAX minicomputer, to create a 32-bit portable operating system to replace DOS. Coincidentally, IBM and Microsoft introduced OS/2 Presentation Manager in October 1988 (see fig. 3.1). Underlying the "sweetness and light" in the joint press releases of the day was Microsoft's desire to exercise control over the future direction of the design of OS/2. Dave Cutler put together a team to develop a "New Technology" operating system, while Microsoft continued to work with IBM to improve OS/2, which was required to run Microsoft's LAN Manager network operating system and the PC version of Sybase's SQL Server relational database management system, introduced in 1988 as Microsoft SQL Server.
3.1
The development timeline for Windows NT.
Microsoft's LAN Manager and IBM's LAN Server products derived from Microsoft's original MS-NET peer-to-peer networking product for DOS, sold by IBM as PC-NET. LAN Manager, which used the NetBEUI protocol, never became a major player in the network operating systems (NOS) market. Industry reports in the early 1990s indicated that LAN Manager then had about a 10 percent share of the NOS market; NetWare was the undisputed NOS leader with 60 percent to 70 percent of the installed base.
Microsoft launched Windows 3.0 on May 22, 1990. Windows 3.0 was an instant success, overwhelming IBM's nascent market for OS/2 on the desktop. On September 17, 1990, Microsoft and IBM announced a division of responsibility for the continued development of OS/2. IBM alone would work on the 1.x and 2.x versions, while Microsoft was to be responsible for the advanced 3.x versions. OS/2 3.0 was specified to be a 32-bit, portable, multiprocessing, preemptive multitasking operating system with advanced security features.
In the fall of 1991, with Windows assured a dominant role on the world's desktop PCs, Microsoft played its Windows NT hand. Steve Ballmer, Microsoft's vice president of marketing, stated that OS/2 "was dead" if IBM didn't agree to use the Windows NT kernel as the foundation for OS/2 3.x. IBM, which even in 1991 was calling its beta version of OS/2 2.0 "better DOS than DOS, better Windows than Windows," wasn't about to adopt the kernel of a Windows-centric operating system for OS/2 3.0. On its own, IBM began to develop what ultimately became the first version of OS/2 Warp, a 32-bit operating system that primarily ran 16-bit (only) Windows applications and offered neither portability nor multiprocessing capabilities.
Microsoft released Windows NT 3.1 and Windows NT 3.1 Advanced Server for Intel and MIPS processors in August 1993. The version number came from Windows 3.1, whose graphical user interface (GUI) Microsoft grafted to Windows NT. The Advanced Server version, designed to replace LAN Manager running under Microsoft's OS/2, supported the NetBEUI protocol and included a primitive TCP/IP stack.
Prospective users were put off by what were then considered to be Windows NT's humongous resource requirements: 16M of RAM and 100M or so of fixed-disk space just to run the operating system. Windows NT required hardware vendors to write new 32-bit device drivers for their products, which limited support for existing adapter cards and peripherals. Sales of Windows 3.1 continued to boom, but the market for Windows NT 3.1 failed to meet Microsoft's optimistic projections. According to industry reports, total sales of both versions of Windows NT 3.1 were in the low hundred thousands, most of which were for evaluation, not production use.
The Windows NT driver dilemma for hardware vendors isn't over yet. At the Windows Hardware Engineering Conference (WinHEC) in April 1996, Microsoft announced the Windows Driver Model (WDM), which lets Windows NT and Windows 95 share common 32-bit drivers. Windows NT 4.0 and Windows 95 are expected to be updated to support the WDM in late 1996 or early 1997.
The cost of PCs capable of running Windows NT declined dramatically during 1994. The price of dynamic RAM (DRAM) plummeted, as did the price per megabyte of fixed-disk storage, minimizing the hardware cost penalty for adopting Windows NT. During this period, Dave Cutler's Windows NT development group labored to reduce the minimum RAM requirement, enhance networking features, improve overall performance, and port Windows NT to Digital's Alpha AXP RISC (Reduced Instruction Set Computing) processor. The result of this effort was the September 1994 introduction of Windows NT 3.5, which reduced RAM requirements by about 4M.
The most significant improvements in version 3.5, however, were the addition of NWlink (Microsoft's IPX/SPX stack for NetWare), and substantial improvements to the TCP/IP stack and TCP/IP administration tools. Microsoft changed the default network protocol from NetBEUI to IPX/SPX, but it was the inclusion of TCP/IP features, such as WINS (Windows Internet Naming Service), DNS (Domain Name Service), DHCP (Dynamic Host Configuration Protocol), and support for PPP (Point-to-Point Protocol) and SLIP (Serial Line Internet Protocol) over RAS (Remote Access Service) that made corporate network administrators take Windows NT 3.5 seriously as a production network server, as well as a database server. Windows NT 3.5 also included remote server administration tools that ran under Windows for Workgroups 3.1.
Microsoft announced its BackOffice 1.0 suite simultaneously with the release of Windows NT 3.5. BackOffice 1.0 included Windows NT Server 3.5, SQL Server 4.21a, SNA Server 2.1, System Management Server 1.0, and Microsoft Mail Server 3.2. Like the Microsoft Office productivity software suite, the BackOffice bundle offered a substantial discount on the license fees for the individual server components. The chapters in Part V, "Windows NT Server and Microsoft BackOffice," discuss Microsoft's licensing policies and describe the individual BackOffice components.
Microsoft announced the Windows NT Workstation and Server 3.51 update on June 12, 1995. The primary objective of version 3.51 was to support Windows 95's common controls and common dialogs in order to run forthcoming 32-bit "Designed for Windows 95" applications under Windows NT. Windows NT 3.51 also supplied selective NTFS data compression and limited support for PC Card (then PCMCIA) adapters. Windows NT 3.51 added minor enhancements to OLE, including support for "NetworkOLE 0.9" (the precursor of Windows NT 4.0's Distributed COM), which lets developers with the Visual Basic 4.0 Enterprise Edition deploy Remote Automation Objects (RAOs) for three-tier client/server database applications.
Press hoopla surrounding the release of Windows 95 relegated Windows NT to bit-player status during the latter half of 1995. Windows 95 greatly enhanced usability and made network installation a snap, but required at least 8M to run most applications reasonably well and 16M for 32-bit mega-apps, such as Access 95. (Microsoft recommends 12M for Access 95, but you need 16M to achieve satisfactory performance with large applications.) Direct-mail and retail PC suppliers preinstalled Windows 95 on virtually all of their systems destined for the home and small-business markets.
Most corporate and institutional buyers, however, shunned Windows 95 for a variety of reasons, not the least of which were the costs of adding needed RAM, user training, 32-bit software upgrades, and lost productivity during the migration to a new operating system. The perception that Windows 95 was a 16-bit/32-bit kluge and was less robust than Windows NT contributed to lack of short-term success of Windows 95 in the corporate environment. The vast majority of people who tried Windows 95, however, agreed that the Windows 95 UI was a substantial improvement over that of Windows 3.1+.
Microsoft correctly assumed that after a person used Windows 95 for any length of time, he or she would consider the Windows 3.1+ UI of Windows NT Workstation 3.51 to be klutzy, at best. To answer this problem, Microsoft released an unsupported alpha version of the Shell Update Release (SUR) for Windows NT 3.51 in late 1995. The alpha SUR had a variety of problems but demonstrated the feasibility of grafting the Windows 95 UI to Windows NT 3.51. (Fortunately, you could uninstall the UI update easily.) Microsoft's initial plan was to provide the SUR in the form of a Service Pack (maintenance release) for Windows Workstation and Server 3.51+. Even though a 4.0 version number appeared when the alpha SUR was installed, Microsoft representatives insisted that version 4.0 was reserved for the "next major release of Windows NT" (a.k.a. Cairo).
It's relatively uncommon for administrators to work at the server console, which usually is located in a closet or other confined and secure space, unless absolutely necessary. You can perform the most common server administrative duties remotely from Windows NT 4.0 or Windows 95 clients. Thus, the Windows 95 UI currently is of more importance to users of the Workstation version than to administrators responsible for the Server version of Windows NT 4.0. Grafting the Windows 95 UI to Windows NT Server 4.0 is a necessity for the transition to a common object model for future versions of Windows NT and Windows 95.
Microsoft released the first beta version of the SUR-now officially named Windows NT 4.0-in early 1996. Beta 1 had the Windows 95 UI in place but lacked many of the promised features described in Chapter 1, "Placing Windows NT Server in Perspective." Microsoft distributed Beta 2, a full-featured version, to more than 200,000 testers in late May 1996. According to Microsoft, the Windows NT 4.0 beta program was the most widespread in the firm's history of Windows NT beta testing. The final version of Windows NT 4.0 was released to production on July 31, 1996. The first recipients of Windows NT Server 4.0 were to manufacturers for preinstallation on server PCs.
See "What's New in Windows NT Server 4.0," (ch 1)
Microsoft's early 1995 goals for Cairo centered primarily on substitution of the Object File System (OFS) for NTFS. OFS was to be a distributed, object-oriented file system that incorporated a directory repository. (A directory repository is a database that contains records for the directory trees of all the servers in a domain. The repository provides a logical view of the network that doesn't depend on its physical implementation.) Entries in the directory repository were to be based on the OFS file-naming system using object names and property values (such as author and creation date), rather than on conventional Uniform Naming Convention syntax (\\Servername\Sharename\Filename).
Files created by today's 32-bit Windows applications, such as Microsoft Word 7.0, let you add property values as attributes of documents (see fig. 3.2). The objective is to enable searching not only by file name, but on property values and indexed file content. The plan was to use OLE DB (an OLE Automation database interface) and OLE DS (OLE directory services) to query and manipulate the repository entries. The Windows 95 UI also was scheduled for the Cairo release, originally planned for release in early 1996.
Windows 95, Explorer, and the Macintosh use the term folder in place of directory. Elsewhere in the book, use of folder predominates. This chapter uses the term directory when it's part of a specific compound term, such as directory repository or directory services.
3.2
Setting property values in Word 7.0 for an OLE document file.
Setting property values of document files becomes increasingly important as Windows NT Server moves toward an object-oriented file system. The property sheets for files created with members of the Microsoft Office suite let you add custom properties to files in the Custom page of the File Properties sheet. For example, a magazine publisher might add Issue (date or number format) and Section (text format) properties for article manuscripts. By querying custom property values, the Cairo Explorer would display only those files meeting specified criteria.
Microsoft's December 1995 "Internet initiative" resulted in a change of plans for the implementation of OFS and the directory repository. At the March 1996 Windows Professional Developer's Conference (PDC), Microsoft announced that OFS features will be incorporated within NTFS and that the repository (directory services) will be implemented in a database derived from the message store architecture of Exchange Server 4.0. Also, Cairo will support DNS naming conventions, allowing the use of DNS names (such as marketing.com) to specify directory trees and to enable inclusion of intranet and Internet URLs in the repository.
See "Embracing and Extending the Internet," (ch 1)
The upshot of Microsoft's change of strategy for Cairo and OFS means a further delay in the release of the next major version of Windows NT. Microsoft, however, is incrementally adding features originally planned for the Cairo version, such as the Windows 95 UI and Distributed COM. Although Cairo probably won't arrive until very late 1997 or (more likely) early 1998, you're likely to find many new Internet-related features added to Windows NT 4.0 in the form of periodic Service Packs, rather than in point releases such as Windows NT 3.51.
Dave Cutler's Windows NT development team achieved Microsoft's basic objectives of 1988 in the first release of Windows NT. These objectives were as follows:
POSIX is a specification for an interface to an operating system, which need not be (but usually is) UNIX. Microsoft has contracted with a third-party developer, Softway Systems, Inc. to develop a POSIX.2 shell and utilities, which Softway markets as OpenNT. OpenNT replaces the POSIX.1 subsystem of Windows NT and provides case-sensitive file naming (files named File1 and file1 can coexist), file links (a single file can have multiple names), background processing, and job control, plus file user and group access, and file ownership. Additional information on OpenNT is available at http://www.softway.com/OpenNT/datasht.htm.
See "Forging Alliances for Scalable Windows NT Server Hardware," (ch 1)
Windows NT universally receives high marks for reliability, extensibility, portability, and security. However, many DOS and 16-bit Windows applications-particularly those that write directly to hardware-don't run under Windows NT, and Windows NT requires specially written 32-bit device drivers for adapter cards and peripherals. Windows NT's scalability has limitations; although Windows NT 4.0 supports up to 32 processors, you begin to receive diminishing returns when you install more than four to six processors in a single server.
See "Server Scalability," (Ch 1)
See "Deciding on a Multiprocessor System," (Ch 5)
You have little or no reason to run 16-bit Windows or any DOS applications on a Windows NT 4.0 server. Furthermore, the vast majority of the hardware devices that you need to implement servers are supported by 32-bit Windows NT drivers, either built into Windows NT 4.0 or available from the hardware manufacturer. Software and hardware incompatibilities-especially with sound cards, digital video capture boards, and other multimedia equipment-are barriers to use of Windows NT Workstation 4.0, not the Server version.
The "Designed for Windows 95" logo on a product doesn't guarantee that it works with Windows NT. Microsoft removed the Windows NT compatibility requirement for the Windows 95 logo about the time Windows 95 reached the market. Many industry experts question the wisdom of this decision, which apparently was motivated by Microsoft's desire to gain a large number of third-party Windows 95 applications as quickly as possible.
The following sections describe the basic elements of the Windows NT operating system from a bottom-up perspective.
The Windows NT executive consists of a collection of system (also called native) services, the kernel, and a hardware abstraction layer (HAL), organized as shown in figure 3.3. Operations that run entirely within the Windows NT executive are called kernel mode services. The HAL, plus code in the kernel and the Virtual Memory Manager, is specific to the category of processor used; Windows NT 4.0 has HALs for Intel 80486 and higher CISC (Complex Instruction Set Computing) processors, and for three RISC processors: MIPS, Alpha AXP, and PowerPC. A replacement HAL is supplied by a computer manufacturer whose design departs from the reference design for a particular processor. In addition to creating a new HAL for each processor family and implementation, Windows NT and 32-bit Windows applications must be recompiled for each processor family. Thus, for example, there are separate versions of the 32-bit Microsoft Office applications for Intel, MIPS, Alpha, and PowerPC systems. Existing 16-bit Windows and DOS applications run on an 80x86 emulator unique to each RISC processor.
3.3
The components making up the Windows NT executive.
The Windows NT executive consists of the following components:
The Security Reference Monitor (SRM) provides basic security features, such as tracking user account privileges, managing ACLs, auditing, protecting objects, and limiting access to system resources. User logon is directed to the SRM, which creates an access token for each authenticated user. An access token is an object whose properties include the user's Security ID (SID), the SIDs of groups to which the user belongs, and special privileges of the user. Object Manager (OM) is responsible for creating objects to represent (abstract) system resources, such as files, hardware devices, and shared memory. Objects expose to the operating system a consistent interface to properties (data) and methods (behavior) of the particular resource. OM manages objects during their lifetime and destroys (deletes) an object when it's no longer needed. The Local Procedure Call (LPC) Facility, which provides communication between applications (clients) and protected subsystems (servers), is a localized version of the Remote Procedure Call (RPC) feature of Windows NT. RPCs are the subject of the later section "Calling Remote Procedures." Process Manager (PM) is responsible for managing processes (executable applications) and threads (executable subcomponents of applications). PM handles the allocation of threads to processors when Symmetric Multiprocessing is in use. Virtual Memory Manager (VMM) allocates protected memory to each process. When memory requirements exceed the amount of available RAM, VM stores part of the RAM contents to the fixed-disk paging file, and then retrieves the contents when needed (a process also called swapping). Paging is very slow compared to direct RAM operations; servers ordinarily have large amounts of RAM (64M or more) to minimize paging operations. Some vital operating system objects and data structures are held in a non-paged pool that's never swapped to disk. Input/Output Manager (IOM) acts on files and devices that manipulate files, including networking components. A description of each IOM component follows this list. The kernel is a low-level component responsible for processor interrupt and software exception handling, synchronizing multiple processors, and scheduling threads for execution. The system services of the executive rely on a variety of low-level objects supplied by the kernel. The Hardware Abstraction Layer (HAL) consists of a layer of code between the processor and the kernel that translates processor-specific features-such as stack operations, input/output handling, and interrupt controller functions-to a uniform set of interfaces for kernel functions. The HAL (Hal.dll) is relatively small; for example, Windows NT 4.0's HAL for Intel processors is 52K in size.
The Windows NT executive is a self-contained, low-level operating system, lacking only a user interface. The UI for the executive is provided by the Win32 subsystem that's discussed in the next section.
For Windows NT network administrators, the Input/Output Manager is the most important component of the executive, because most network operations occur within the IOM. IOM implements device-independent input/output services for all hardware components except the processor(s). The I/O system of Windows NT is asynchronous-that is, when an I/O request is issued, the operating system continues with other tasks until the device involved completes the requested operation. (Protected subsystems also can request synchronous I/O but usually pay a performance penalty for doing so.) The IOM is unique among the executive components, because IOM communicates with the kernel, with the HAL, and directly with hardware components through device drivers (refer to fig. 3.3).
The IOM is comprised of these elements:
File systems support multiple file architectures through layered drivers-thus, new or improved file systems can be added to Windows NT. Windows NT 4.0 supports 16-bit FAT and NTFS file systems; OS/2's HPFS, which was supported in prior versions of Windows NT, can't be used with Windows NT 4.0. For servers, the FAT file system is used only for accessing diskettes and CD-ROMs. (You can use the FAT file system for a Windows NT server, but doing so is strongly discouraged.) Windows NT 4.0 does not support the 32-bit FAT file system included with Service Pack 2 for the OEM (original equipment manufacturer) version of Windows 95 that computer assemblers preinstall on their PCs. NTFS is the subject of the later section "Handling Files with NTFS." Cache Manager stores the most recently accessed fixed-disk data in system memory to improve the performance of sequential reads. Cache Manager supplements the built-in cache of high-performance SCSI fixed-disk and CD-ROM/WORM drives. Cache Manager also improves write performance by using VMM to perform asynchronous writes in the background. Network drivers consist of the network server and network redirector. The server receives network I/O requests, and the redirector transmits network requests. The term redirector, which originated in the early days of MS-NET and PC-NET, is derived from the process of intercepting file operation requests on the local PC (interrupt int13h for Intel processors) and rerouting (redirecting) the operations over the network to the server. Device drivers consist of a 32-bit code layer between the preceding three elements and hardware, such as SCSI host adapters for drives, network interface cards (NICs), keyboards, mice, and graphic adapter cards. Windows NT treats network drivers as device drivers.
As noted earlier in this chapter and elsewhere, the lack of device drivers for the wide variety of hardware devices used with 16-bit Windows and Windows 95 has hampered the acceptance of Windows NT Workstation. All of today's hardware devices that are designed for use with production servers have Windows NT drivers. These devices are listed in the current version of the Windows NT Hardware Compatibility List (HCL) that's included with the Windows NT 4.0 documentation and periodically updated by Microsoft. You can obtain the current HCL from http://www.microsoft.com/backoffice.
The layers above the Windows NT executive provide user-mode services. These layers consist of the environmental subsystems (servers) for 32-bit and 16-bit Windows applications, DOS, OS/2, and POSIX applications, plus client applications in each of these five categories. The Win32 subsystem provides the user interface (graphic display, mouse, and keyboard handlers) for all servers and for those system services of the executive that involve interaction with the user via, for instance, the User Manager for Domains, Server Manager, and the Virtual Memory settings in the Performance page of the System Properties sheet. Thus, the Win32 subsystem is the only component of Windows NT that's visible to the user.
There's a distinction between the user-mode and kernel-mode services that are components of Windows NT and the term services used elsewhere in this book. Unless otherwise noted, services refer to executable applications that are startable when Windows NT boots. These services appear in the Service list of Control Panel's Services tool, and may be started automatically or manually, or be disabled. The members of Microsoft BackOffice, for example, run as services under Windows NT, as do the Server and Workstation services. (Microsoft implemented Windows NT's Server services as a device driver for various reasons, a description of which is beyond the scope of this book.)
Figure 3.4 shows the relationship of the environmental subsystems and client applications. Local procedure calls (solid lines) provide all communication between subsystems and between clients and subsystems. Subsystems also can request native services by a system trap, shown as a dashed line in figure 3.4. Each subsystem has its own protected memory space.
3.4
The environmental subsystems and client applications that provide user-mode services.
Messages between client applications and environmental subsystems pass through the Windows NT executive, which establishes a separate message queue for each instance of a client application or virtual DOS machine (VDM). For clarity, the trip to and from the executive doesn't appear in figure 3.4.
Figure 3.4 shows these environmental subsystems:
Virtual DOS machines (VDMs) provide a protected environment for individual 16-bit DOS applications. The Win32 subsystem provides a character-based window (called a console) for interaction with the user. One VDM is created for each instance of a DOS application. Windows on Win32 (WOW) runs all 16-bit Windows 3.1+ applications in a single instance of a VDM with common protected memory. Thus, if one unruly Windows 3.1+ application crashes the VDM, all other running 16-bit Windows applications crash with it. Each 16-bit Windows application is assigned its own thread of execution to provide multitasking capability. The OS/2 subsystem runs character-based OS/2 applications in a console. The paucity of character-based OS/2 applications that don't have Windows NT equivalents means that system and network administrators seldom need be concerned with using the OS/2 subsystem. The POSIX.1 subsystem can run POSIX-compliant applications, which is required for government purchase of "open systems." Windows NT survived a recent appeal by UNIX bidders of an award of a Coast Guard workstation contract to Unisys that proposed to use Windows NT as the operating system. Microsoft's funding of development of the POSIX.2 shell and utilities of OpenNT, mentioned earlier in this chapter, is related to one of the Coast Guard contract requirements. It's likely that Cairo will substitute POSIX.2 for the POSIX.1 subsystem.
One of the most important new features of Windows NT 3.1 was NTFS, an outgrowth of HPFS that Microsoft and IBM developed for OS/2. Following are Microsoft's design objectives for NTFS, with a brief description of how the objectives were achieved:
Support for large fixed-disk drives. The original version of HPFS had a maximum volume size of 4G. Windows 95's 16-bit FAT file system is limited to 2G volumes with 64K clusters; the large cluster sizes makes storing small files very inefficient because each file requires a minimum of one cluster. Windows NT uses 64-bit addresses for clusters of physical storage sectors that range from 512 bytes to 4K, depending on the size of the disk and its sector size. (Most fixed disks have a sector size of 512 bytes.) The maximum volume size for NTFS is 264 bytes (16,777,216 terabytes) and files can be up to 264 bytes long. Large volume and file sizes are especially important for storing full-screen, full-motion video for editing and broadcast applications. Recoverability. NTFS stores two copies of its equivalent of DOS's file allocation table (FAT), called the master file table (MFT). Thus, if the original version of the disk's system data becomes corrupted due to a hardware failure (typically, a bad disk sector), the copy automatically is used on bootup, and the operating system creates a new original from the copy. NTFS uses a transaction log to maintain file consistency in the event of a hardware problem (such as a power failure) or system failure during the write process. NTFS uses the transaction log to return the disk to a consistent state during the next disk access. Fault-tolerance through redundancy. Windows NT Server can create a software RAID (Redundant Array of Inexpensive Disks) for NTFS volumes. If you choose RAID 1 (disk mirroring or duplexing) or RAID 5 (disk striping with parity), you store two copies of all server files. In case of disk hardware failure, NTFS uses the file copies. If the system detects a bad disk sector, NTFS marks the sector as bad, and then creates a replacement sector from data stored on the other disk. Chapter 7, "Setting Up Redundant Arrays of Inexpensive Disks (RAID)," describes RAID levels and the tradeoffs between implementing RAID arrays in hardware or by software. Security. Windows NT treats disk files, like processes, as objects. A NTFS file object has properties (also called attributes) such as name, creation date, date last updated, archive status, and a security descriptor. A file object also has a set of methods, including open, read, write, and close. A user, including networked users, can't invoke a method of a file object until the Security Reference Monitor determines that the user has permission for a particular method. Data compression. Selective data compression made its first appearance in Windows NT 3.51. Data compression saves disk space at the expense of somewhat slower file access. Unlike the DriveSpace compression utility of DOS 6+ and Windows 95, NTFS lets you selectively compress a folder (and its subfolders) or individual files. On servers, compression usually is reserved for infrequently accessed files or very large files, such as large Windows bitmap (.BMP) files, that aren't already compressed. Compressing and decompressing frequently accessed files reduces server performance by a significant margin. Multiple data streams in a single file. NTFS permits subdividing the data in a file into individual streams of data. The most common application of multistream files is for storing Macintosh files on Windows NT servers. Macintosh files have two streams (called forks): the data fork and the application fork. The application fork contains information on the program that created or can edit the file. (In Windows NT and Windows 95, the Registry associates applications with file extensions, serving a purpose similar to that of the Macintosh's application fork.) The default data stream has no name; additional streams have names. Developers address a particular stream in a file by a suffix preceded by a colon, as in Filename.ext:streamname. Localization with Unicode. NTFS supports Unicode file names. Unicode uses 16 bits to specify a particular character or symbol, rather than the 7 or 8 bits of ASCII and ANSI characters. 16 bits accommodate 64K characters and symbols, so Unicode doesn't depend on changing code pages for national language support (NLS).
One recurrent theme in this book is, "Use NTFS, not FAT, for servers." In the early days of Windows NT, some network administrators were reluctant to abandon FAT in favor of NTFS because they wanted to be able to boot a server with a DOS diskette and gain access to files in case of a problem booting Windows NT. The emergency repair disk you create when you install Windows NT and the Windows NT Setup program's Repair facility is much more effective than booting from DOS to recover from a system failure.
See "Repairing the Windows NT Server Operating System Installation," (Ch 6)
The next two sections describe the features of NTFS that are of the most significance to Windows NT Server 4.0 network administrators.
The structure of DOS's FAT is relatively simple-FAT stores the DOS 8.3 file or folder name, a set of standard attributes (read-only, hidden, system, and archive bits), size of the file in bytes, and a pointer to (physical location of) the cluster that holds the first byte of file data. The master file table (MFT) of NTFS is much larger and more complex than the FAT for a drive having the same directory structure and file complement. The MFT, and its mirror-image redundant copy, is similar in structure to a table of a database, with fixed-length and variable-length records. (The boot sector contains pointers to the location of the MFT and its mirror copy; file control blocks, or FCBs, point to a particular record in the MFT.)
The MFT of a volume that contained only directories and very small files would comprise the entire contents of the volume. Storing the data of small files within a MFT record makes access much faster and minimizes unused cluster space (slack). If the data won't fit in the MFT record, the NTFS driver creates pointer(s) to non-resident data stored in runs. A run, also called an extent, is a contiguous block of disk space; non-resident data may be stored in one or more runs, which are a maximum of 16 disk clusters.
Microsoft provides only a small amount of "official" information on the MFT in the Windows NT Resource Kit and in Helen Custer's Inside the Windows NT File System monograph. Figure 3.5 is a simplified diagram of the MFT record structures for files and folders. (The HPFS Extended Attributes field isn't shown in fig. 3.5, because Windows NT 4.0 doesn't support HPFS volumes.) The first 16 records of the MFT contain what Microsoft calls "special information," also called metadata.
See "Print and CD-ROM Publications," (Introduction)
3.5
The simplified structure of the file and directory records of the Master File Table for an NTFS volume.
Custer's monograph states that MFT is a relational database, apparently because the MFT consists of records with attributes in columns. The rules of normalization for relational databases, however, require that all records in a table represent a single entity set and have a consistent set of attributes (columns). Mixing of records for files and directories isn't, in itself, a serious violation of relational database theory because NTFS treats directories as files. However, the Index Root, Index Allocation, and Bitmap attributes of directory records aren't consistent with the Data attribute of file records. Further, the first 16 records contain metadata in fields that vary from the file and index records. Relational database theorists wouldn't consider MFT a properly normalized relational table.
Table 3.1 lists the attributes (fields or columns) of the MFT and describes the content of each attribute, including three attributes that don't appear in figure 3.5. The terms attribute, property, field, and column are interchangeable in discussions of database tables. Similarly, row and record refer to the same element of a table. A volume is a collection of fixed-disk clusters that's identified by a single logical drive letter; an NTFS volume may consist of contiguous clusters on two or more drives, which need not be elements of a RAID array. NTFS lets you combine contiguous free space on two or more disks into a single volume.
Table 3.1 Attributes of the NTFS Master File Table (MFT)
Attribute (Field) Description Standard Attributes (Standard Information) Contains standard file attributes, such as time stamps, archive status, and linkage data, plus an attribute list for large files. Filename Contains the Unicode file name (up to 255 characters) and the DOS 8.3 file name, created from the Unicode file name. For POSIX, contains additional names for the same file (called links or hard links). Security Descriptor Contains information on ownership, access rights, and other security-related information used by the Security Reference Monitor. Data Contains file data for files up to about 1.5K long; otherwise, a pointer to the data. The default data is an unnamed stream; NTFS provides for additional named streams. Index Root Contains relative location of directory information (index records only). Index Allocation Contains the size and location of directory index (index records only). Bitmap Contains a bitmapped image of the directory structure (index records only). Volume Information Contains the version number and name of a volume (volume system record only, not shown in fig. 3.5). Extended Attributes Previously used for HPFS files, which are no longer supported in Windows NT 4.0 (not shown in fig. 3.5). User-Defined Attributes Will contain special attributes for custom searches (not shown in fig. 3.5); reserved for implementation in future versions of Windows NT and NTFS, presumably Cairo.
For additional details of the low-level organization of MFT records, check out http://www.c2.org/hackmsoft/ntfs/doc/.
Bitmaps are a very efficient way to index records in tables, especially where indexes on multiple fields are required. An index dramatically speeds the location of an individual record in a table with a large number of records. Bitmapped indexing, not to be confused with bitmapped graphics, speeds access to the index itself. FoxPro was the first desktop database to take full advantage of bitmapped indexing in its Rushmore technology. After acquiring FoxPro, Microsoft adapted the Rushmore indexing method to Access .mdb files (commencing with Access 2.0). The Windows NT 4.0 version of NTFS indexes only the file name field. Cairo is expected to include the capability to create indexes on user-defined attributes for faster searching.
Relational database management systems, such as Microsoft SQL Server and Access, use transactions when adding, updating, or deleting records from tables. A transaction assures that all operations affecting records of related tables take place; if a problem prevents completion of the entire transaction, the database tables are restored to their original status before the transaction. For example, if an orders database contains Orders and LineItems tables, adding or deleting an Orders record requires simultaneous addition or deletion of the related LineItems record(s). LineItems records without a corresponding Orders record are called orphan records, which you don't want in a database. SQL Server uses the reserved words COMMIT TRANS(ACTION) and ROLLBACK TRANS(ACTION) to attempt and reverse a transaction, respectively. Records in a temporary transaction log record the progress of the transaction; information in these records is used to roll back the transaction, if necessary.
A temporary transaction log, such as that used by Microsoft Access, varies from the persistent transaction log maintained by client/server RDBMSs, such as Microsoft SQL Server. The persistent transaction log records all successful database transactions since the last backup of the database. After restoring the backup copy of a damaged database, the transaction log is executed to bring the restored copy of the tables back to the status of the instant when the damage occurred, less any transactions in progress at that point.
See "Setting Up Transaction Logging,"(ch 22)
NTFS uses a similar transaction logging process to recover from a system failure during a disk write operation. Following is a brief description of the process of recoverable writing to an NTFS file:
The NTFS file I/O driver initiates the write process, including an instruction to the Log File Service to log the transactions involved. The data is written to cache memory under control of Cache Manager. Cache Manager sends the data to the Virtual Memory Manager for background writing to the disk file, a process called lazy writes, achieved by periodic flushing of the cache to the disk drive. The Virtual Memory Manager sends the data back to the NTFS driver, which passes the data through the Fault Tolerant driver (when using a software RAID array) to the disk driver. The disk driver sends the data to the host controller (usually a SCSI host controller for servers), which passes the data to the destination fixed disk(s). If write caching is enabled on the fixed-disk drive(s), the data is written to on-drive memory, and then transferred locally to the disk. Otherwise, the data is written directly to the disk. If the write operation proceeds without an error, the transaction log record is deleted. If an error occurs, the transaction log record remains in the transaction table. On the next disk access, the Log File Service detects the log record and restores the corresponding MFT record to its original condition before the write attempt.
This transaction logging process takes care of problems associated with operations that affect the directory structure-such as creating, copying, and deleting files-to maintain directory consistency. Errors that occur only when altering the data in the file aren't recoverable unless you have a RAID 1 or RAID 5 array. Contents of the self-contained write cache of a disk drive that aren't written to the disk before a power or hardware failure are lost, and the failure may not be reflected in transaction log records. For this reason, most SCSI drives with read/write caches are shipped with write caching turned off.
Remote Procedure Calls (RPCs) permit applications to be executed by individual components that reside on other networked PCs, a process often called distributed computing. The RPC facility of Windows NT conforms to the Open Software Foundation's RPC standards incorporated in its Distributed Computing Environment (DCE) specification, with which virtually all flavors of UNIX comply.
Figure 3.6 is a diagram of a 32-bit Windows application that uses RPCs to connect to functions contained in three Windows DLLs (dynamic link libraries) that reside on three PCs running Windows NT Server or Workstation 4.0. If the library functions perform very processor-intensive tasks (such as rendering 3-D animated computer graphics for movies), using RPCs for distributed processing rivals the performance of Symmetrical Multiprocessing with two or more processors. Fast network connections, such as 100BaseT or Fiberchannel, are needed if large amounts of data must be passed between the executable program and the library function.
3.6
Calling three library functions on remote computers with RPCs.
Following is a brief description of each layer shown in figure 3.6:
Application is the program that calls library functions. Data sent to and returned by the function are implemented as function call arguments, as in RenderFrame(DrawingOut, FrameIn). RenderFrame is the name of the function, DrawingOut is an output parameter, and FrameIn is an input parameter. Client function stubs have parameters that correspond to the function call arguments. The client stubs marshal the parameter values over the network; marshaling processes the parameter values for transmission over the network. Client function stubs take the place of the corresponding functions that ordinarily would be contained in local DLLs. RPC client runtime is responsible for determining the network location of the called function and the transport protocol required, and connects to the appropriate network driver of the I/O manager. RPC server runtime receives RPCs and directs each call to the appropriate server function stub. Both the server and client runtime use Windows NT's transport provider interface (TPI) to communicate with the network driver. Server function stubs unmarshal the function parameters and call the corresponding functions of the local DLL(s). Library function contains the code that does the work. Remote DLLs are identical to local versions.
Using conventional RPCs requires the developer to create and compile an interface definition language (IDL) file, which creates the client and server stubs for the function. The IDL file also creates header files (function prototypes), which must be added to the calling client application. Thus, C and C++ applications that use RPCs must be recompiled to incorporate the RPC header information.
RPCs running over NetBEUI networks use the named pipes interface for transferring data. Named pipes is an extension to NetBIOS that provides a persistent data conduit between networked processes. Microsoft and IBM first implemented named pipes, which provide a self-contained security mechanism, in LAN Manger. SQL Server, as an example, uses named pipes for receiving SQL statements from clients and returning query result sets and other database information to clients. Named pipes, implemented as a file I/O device, primarily are used for streaming data transport. In addition to named pipes over NetBEUI, Windows NT provides built-in RPC facilities for TCP/IP, IPX/SPX, and DECnet.
Distributed COM (DCOM), a new feature of Windows NT 4.0, adapts the RPC facility to permit communication between Microsoft COM (Common Object Model) objects over networks. DCOM makes distributed computing simpler by eliminating the need to rewrite client applications to accommodate RPCs through the use of OLE Automation techniques. (Microsoft's Object Linking and Embedding is built on COM.) DCOM substitutes OLE client and OLE proxy stubs for client and server function stubs, respectively. For example, a 32-bit OLE Automation client application written in Visual Basic 4+ easily can be adapted to use Remote Automation Objects (RAOs), which are out-of-process OLE servers (executable OLE applications). The Automation Manager supplied with the Enterprise Edition of Visual Basic 4+ takes the place of the RPC client and server runtimes.
See "Distributed Component Object Model (DCOM)," (ch 1)
In early 1996, with its "Internet incentive," Microsoft began substituting the term ActiveX for OLE in situations where linking and embedding of objects within other objects either wasn't involved or was only of minor importance. OLE Controls, for instance, became ActiveX controls. Now you're likely to see OLE Automation replaced by Automation. Microsoft didn't change OLE Automation to ActiveX Automation, because COM's Automation interface also is used for ActiveX objects, as well as linked and embedded OLE objects. The use of the term OLE for linking and embedding documents created with the components of Microsoft Office is expected to continue.
Windows NT networking processes make extensive use of the RPC facility, which provides a consistent set of methods by which local processes and remote processes communicate. The Server and Workstation versions of Windows NT 4.0 both support RPC networking, allowing users of the Workstation version to share files, printers, and other peripherals. A group of Windows NT Workstation users that share files and peripherals among one another (usually on an ad hoc basis) usually is called a workgroup. The workgroup (also called peer-to-peer) networking capabilities of Windows NT Workstation 4.0 are quite similar to those of Windows 95, except that there's a limit of 10 simultaneous inbound connections to a PC running Windows NT 4.0. (There's no limit on outbound connections.)
Helen Custer's 1993 book, Inside Windows NT, describes NetBEUI as "Windows NT's primary local area network transport protocol." The book contains many references to LAN Manager, which was then Microsoft's only network operating system offering. Microsoft designed Windows NT 3.1 to be fully compatible with LAN Manager servers running OS/2 and LAN Manager clients running on DOS/Windows, Macintosh, and UNIX platforms. LAN Manager compatibility was essential for integrating Windows NT 3.1 into the existing Microsoft networking infrastructure. NetBEUI remains the most common protocol for workgroup networking with Windows NT 4.0 and Windows 95, because it's simple for users to set up and is fast.
Peer-to-peer networking isn't limited to NetBEUI; you also can set up workgroups that use TCP/IP or IPX/SPX network transports. You don't need client licenses for Windows NT 4.0 peer-to-peer networking. Peer-to-peer networking receives only cursory coverage in this book because of the limited number of connections permitted to a client running Windows NT Workstation 4.0. You can't use members of the BackOffice server suite on peer-to-peer networks; with the exception of the single-user Workstation (Developer) version of SQL Server, BackOffice applications must be installed on Windows NT Server.
The primary difference between the Server and Workstation versions of Windows NT 4.0 (other than price) is the capability to create and manage network domains. LAN Manger 2.x provided an early version of domain-based networking. (Microsoft originally planned to supply domain networking features to Windows NT as an add-on called LAN Manager for Windows NT.) The most important advantage of the use of domains is the capability to use a single-user logon to multiple servers and services (such as SQL Server and Exchange Server). Network administrators need to create only a single account for the user in his or her primary domain. Trust relationships between domains determine whether secondary domains accept the authentication provided by the user's primary domain.
See "Understanding Domain Architecture and Security," (Ch 16)
The use of multiple domains in large networks allows distributing management of the network among individual facilities. Setting up and administering Windows NT domains is the subject of Chapter 16, "Distributing Network Services with Domains." The downside of domains is that you must license Windows NT Server 4.0 and purchase a client license for each client (called a per-seat license) or for a specific number of simultaneous clients connecting to a server (a per-server license.)
This chapter briefly overviewed the history and the features of Windows NT, with emphasis on Windows NT networking capabilities. The history of Windows NT included a discussion of the relationship between Microsoft's LAN Manager and IBM's LAN Server, both of which are based on OS/2, and Windows NT Server. A full description of all the unique features of the Windows NT operating system would require a multivolume set of books, so only brief coverage of the topics of primary interest to network administrators appears in this chapter. The chapter concluded with a discussion of Windows NT's implementation of RPCs and the differences between the Server and Workstation versions of Windows NT 4.0.
The following chapters provide detailed explanations of the topics discussed in this chapter:
Chapter 4, "Choosing Network Protocols," explains how to select one or more of the three principal networking protocols supported by Windows NT based on your network configuration. Chapter 12, "Managing User and Group Accounts," describes how to use Windows NT Server 4.0's User Manager for Domains, take advantage of the new Add User Accounts and Group Management Wizards, and utilize Windows NT's built-in user groups. Chapter 16, "Distributing Network Services with Domains," covers Windows NT Server's trusted domains and other distributed networking features that allow single-user logon for multiple network servers and server-based applications running on LANs and WANs.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.