Operating System

File and Print Services Technical Overview

White Paper

Abstract

File and print servers are the workhorses of every network. That does not mean, however, that they can be taken for granted—on the contrary, successful network operating systems must incorporate the latest technological advances into these fundamental services. To retain the competitive position established by Microsoft® Windows NT Server 4.0, Windows 2000 Server has updated its file system, indexing and search capabilities, storage services, and printer functions using state-of-the art technology. In addition, file and print operations are now integrated with an organization’s internal intranet and with the external Internet. You gain new functionality when you add Windows 2000 file and print servers to an existing network environment, and then gain more features when you upgrade—at your own pace—to a Windows 2000 network.

All of the changes to file and print services have been made with both network administrators and application developers in mind. Windows 2000 makes managing file and print services more efficient, and the open architecture of Windows 2000 Server is designed to facilitate third-party developers’ efforts to provide additional functionality in response to evolving business needs.

© 1999 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, Active Directory, ActiveX, MSN, Windows, and WindowsNT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

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

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

12/99

Contents

Introduction

File Services

Managing Shares, Connected Users, and Open Files

Distributed File System

Dfs Topology

Dfs Replication and FRS Synchronization

Dfs Intelligent Client Caching

Dfs Uses Standard Security

IIS Can Use Dfs

Windows 2000 Improvements to Dfs When Compared to Dfs 4.x

NTFS and Related Enhancements

NTFS Reparse Points and File System Filter Drivers

Encrypting File System

NTFS Volume Mount Points

NTFS Sparse File Support

Native Property Sets

SID Searching and Bulk ACL Checking

NTFS Change Journal

Distributed Link Tracking

Other Supported File Systems

FAT16 and FAT32

Compact Disk File System

Universal Disk Format (UDF)

Indexing Service

Indexing Service Structure

Catalogs

Both Data and Property Search

Search and Retrieval

Indexing Control and Speed

Detecting Changes Using NTFS Change Journal

Index Storage Using Sparse Streams

Integrating Searches into Applications

Remote Storage and Retrieval Integration

Mount/Dismount Tracking

Storage Management Services

New Disk Architecture

Disk and Volume Management Features

Disk and Volume Management Tasks

Defragmentation Utility

Remote Storage

Managing Remote Storage

Premigration, Truncation, and Placeholders

Remote Storage Interoperates with Related Tools

Security

Removable Storage

Removable Storage and Client Applications

Removable Storage Database

Using Removable Storage

Security

Disk Quotas

The Single Instance Store

System File Protection

Code Signing and Catalog Files

Storage Support for Hardware Innovations

Printing Services

More Printers Supported

Easier Installation of Local Printers (Plug & Play)

More Types of Clients

Enhanced Printing Features

Simplified Print Configuration and User Interface

Standard TCP/IP Port Monitor

Remote Port Administration

Easy-to-Find Network Printers Using Active Directory

Print Queue Monitoring

User Permissions and Group Policies

User Settings

Enhanced Print Server Clustering

Enhanced Printer Drivers

Better Color Output Quality

Better Halftone and Image Processing Technologies

Internet Printing

Existing NT File & Print Servers

Incremental Deployment

Deployment of Windows 2000 Server Network

SUMMARY

For More Information

Introduction

File and printer sharing, information retrieval, and data storage are among the most frequently used network services. They are therefore crucial factors to consider when choosing a network operating system.

Microsoft built the Windows® 2000 Server operating system from the ground up as an integrated, multipurpose operating system. The operating system design responds to customer demands for sophisticated but easy-to-manage file and print services, for integration of Web and media content with file and print information sharing, and for meeting exponential growth in storage requirements while lowering storage cost. In addition, its open architecture lets third-party developers provide additional functionality in response to ever-changing business requirements.

Microsoft developed specific file and print features to meet widespread customer needs:

  • Reduced cost. Remote Storage migrates infrequently used files to lower-cost secondary storage, yet keeps that data available if needed. Removable Storage helps reduce costs by letting multiple client applications share local libraries and tape or disk drives while ensuring that client applications do not corrupt each other’s data.
  • Better manageability. The improved NTFS file system, distributed file system (Dfs), and Indexing Service make it easier to find and access files across expanding networks. New interfaces make operating system services easier to manage; for example, the new printer interface makes it simpler for both administrators and end-users to configure and manage their printing needs.
  • Increased availability and reliability. Dfs replication and File Replication service (FRS) synchronization help keep data available to users, even if a server or disk drive fails or a shared folder or file becomes corrupted. Dynamic volumes formatted with NTFS 5 allow fewer reboots when adding disks and creating, extending, or mirroring a volume.
  • Scalability. The Windows 2000 NTFS version 5 file system and the Windows 2000 storage subsystems let users efficiently store and retrieve ever-larger quantities of data.

Organizations that install Windows 2000 file and print servers in their existing network can take advantage of several new features. When they upgrade to a Windows 2000 network, additional file and print capabilities become available.

This overview focuses primarily on the Windows 2000 Server implementation of the standard file and print services components. However, it includes mention of several Web-related features where they are inextricably bound up with file and print services.

File Services

The majority of network servers provide file service; that is, they offer centralized file storage that lets users easily share files. File servers often store private files as well as shared files, and provide a single point of backup for both. File servers let users access their files even when they move to different workstations.

Windows 2000 Server introduces new and improved file services, including changes to the management of network shares and users and to the NTFS file system. In addition, Windows 2000 Server supports several other on-disk file system formats. Windows 2000 Dfs extends the capabilities present in Windows NT 4.0 Dfs. Not technically a file system driver, Dfs provides what appears to users as a unified hierarchical file system, although the data actually resides on different servers across the network.

Network administrators typically install systems whose primary role is providing file service as member servers rather than as domain controllers. All file service features described in this paper, except for domain-based Dfs and the FRS, are also available on standalone servers.

Windows 2000 Server file-system related features include:

  • Managing shares, connected users, and open files
  • Distributed File System (Dfs)
  • NTFS and related enhancements
  • Other supported file systems

Each of these topics is covered in the following sections.

Managing Shares, Connected Users, and Open Files

The Shared Folders snap-in[1] is a file–system-related tool in the Windows 2000 Server collection of System Tools. An updated version of capabilities found in Windows NT Server 4.0 in Server Manager in the Control Panel, Shared Folders enables the creation of shares, manages the connections on local or remote computers, and displays open files. To open it, click Start, click Programs, click Administrative Tools, and then click Computer Management. Figure 1 shows Shared Folders among the System Tools available in the Computer Management console.


Figure 1. Shared Folders tool manages shares, connected users, and open files

For Windows 2000 Server, members of the Administrators, Server Operators, or Power Users groups can use the Shared Folders snap-in. (For Windows 2000 Professional, only members of the Administrators or Power Users group can use Shared Folders.)

The Shared Folders snap-in lets you perform the following tasks:

  • Shares. Create, view, and set permissions for network shares, including shares running Windows NT 4.0.
  • Sessions. View (and disconnect) users connected to the computer over the network.
  • Files. View (and close) files opened by remote users.
  • Mac Shares. Configure Services for Macintosh so that Windows and Macintosh users can share volumes, files, and printers through a Windows 2000 Server. Mac clients can access Macintosh volumes and printers using an Apple networking protocol. From the file server, you administer Mac shares from the Services and Applications node of the Computer Management console tree[2].

For Windows 2000 Server, the Shared Folders snap-in also enables publishing a share as a Volume Object in the Active Directory™ directory service. Publishing an object in Active Directory lets users query available resources and shares.

Distributed File System

The Microsoft distributed file system (Dfs) for Windows 2000 Server is a second-generation technology built on and improving the earlier Windows NT Server 4.0 Dfs. Dfs presents to users a logical view of distributed physical storage, making both managing and finding network data easier. Dfs is not a new file system but software that gives users a view of what looks like a unified hierarchical file system, even though the data is in reality distributed in different locations. For example, you can use Dfs to make marketing files scattered across multiple servers in a domain appear as if all these files reside on a single server. This eliminates the need for users to go to multiple locations on the network to find the information they need. Dfs can connect hundreds or thousands of published shares in a single logical system.

You use the Dfs Administrator snap-in to administer Dfs volumes. Implementing Dfs is not mandatory in Windows 2000 Server, but network administrators should consider doing so if:

  • The users accessing shared resources are distributed across multiple sites.
  • Most users require access to multiple file servers.
  • Network load balancing can be improved by redistributing shared resources.
  • Users require uninterrupted access to file servers.
  • The organization uses either internal or external Web sites (see the section “IIS Can Use Dfs” later in this paper for how Dfs can help simplify Web management).

Dfs is protocol independent, which means that both Windows and non-Windows servers can be included in the Dfs namespace. The Dfs client and server use the Common Internet File System (CIFS) to determine which file server will be accessed by the client. When the client then accesses the target file server, it uses the native protocol to access the file server. If the server uses a NetWare-based operating system, the client uses NetWare Core Protocol (NCP); if the server is Unix, the client uses network file system (NFS). That is, clients use NCP or NFS to connect to the file share after Dfs has directed them to it.

The purpose of Dfs is to let users and applications access files. Dfs is not designed to perform operations such as indexing, virus scanning, or backup, because accessing very large numbers of files in a highly sequential/repetitive manner using Dfs would substantially increase network traffic. In addition, when using Dfs replicas you do not know which particular file server in a replica set is being accessed, which means that Dfs is not suitable for backup and restore operations.

These Dfs topics are covered in the following subsections:

  • Dfs topology
  • Dfs replication
  • Dfs intelligent client caching
  • Dfs uses standard security
  • IIS can use Dfs
  • Windows 2000 improvements to Dfs compared to Dfs 4.x

Dfs Topology

The Dfs topology is the physical layout depicted in the Dfs Administrator console that consists of a root, links, shared folders, and replicas. The Dfs topology is not the same as the Dfs namespace, which provides the view of shared resources on the network as seen by users.

Dfs topology begins with the root of the Dfs tree. An administrator maps a Dfs root, which is the top of the logical hierarchy, to a physical share. Currently, you can assign several thousand Dfs links to a Dfs root. A Dfs link—the point where a physical machine boundary is crossed—maps a Domain Name System (DNS) name to the standard universal naming convention (UNC) name of the target shared folder (or target Dfs root). When a Dfs client accesses a Dfs shared folder, the Dfs root server uses this mapping of a DNS name to a UNC name to return a referral to the client so that it can locate the shared folder.

Mapping the DNS name to the UNC name makes the physical location of data transparent to users, who no longer have to remember on which server a folder is stored. If you move a file or folder to another physical location, the user’s view of it remains unchanged.

When a client machine requests a referral to a Dfs share, the Dfs root server uses the Partition Knowledge Table (PKT) to direct the client to the physical share. The PKT is stored in Active Directory for domain-based Dfs and stored in the registry for stand-alone Dfs (more about domain-based Dfs and stand-alone Dfs later). In a network environment, the PKT maintains all information about Dfs topology, including its mappings to the underlying physical shares. After the Dfs root server refers the client to a list of replica shares that correspond to the requested Dfs link, the client then uses Active Directory site topology[3] to contact a replica within the same site or, if one is not available, a replica outside the site.

Figure 2 shows an example of how an administrator can set up Dfs composed of links from multiple servers, and it shows how an end-user would see the result:


Figure 2. Dfs topology from the point of view of the administrator and the end-user

Only Windows 2000-based machines can host Dfs roots and Dfs links (Dfs shared folders). Non-Windows 2000-based machines can be the target of a Dfs link but cannot contain additional Dfs links (although of course they can host file-system subfolders). Dfs shared folders on down-level volumes (volumes on computers running an earlier operating system than Windows 2000) include those published on Windows NT 4.0 Workstation and Server, Windows 95, Windows 98, Windows for Workgroups, and all non-Microsoft shared folders for which client redirectors are available. If duplicates of a shared folder exist, each copy is a replica in a replica set (see the section “Dfs Replication” for more about this).

The Dfs root can be one of two types:

  • Domain-based Dfs root. A domain-based Dfs root must be hosted on a domain member server or domain controller. Such servers, called root replicas, provide referrals to the Dfs namespace for client machines. Domain-based Dfs stores its configuration information in Active Directory. If you have more than one domain controller (to keep the Dfs configuration information available) and if you establish more than one Dfs server in the domain, domain-based Dfs can provide high availability for any Dfs file or folder in the domain.
  • Stand-alone Dfs root. A stand-alone Dfs root can be hosted on three types of Windows 2000 servers: on a stand-alone server, a member server, or on a domain controller. A stand-alone Dfs server does not use Active Directory, cannot have root-level replicas, and can have only a single level of Dfs links. Stand-alone Dfs stores its configuration in the local registry. Its purpose is to provide backward compatibility with earlier versions of Dfs. During an upgrade of Windows NT 4.0 to Windows 2000, any Dfs 4.x roots are converted automatically to Windows 2000 stand-alone Dfs roots. You can manage Dfs 4.x implementations with the Windows 2000 Dfs Administrator. You can migrate stand-alone Dfs roots at your own pace. Some roots can remain as stand-alone; others can be migrated to domain-based. Both can coexist in a Windows 2000 domain.

Each server that hosts a domain-based Dfs root obtains the PKT from the Active Directory[4]. Thus, each of these servers must stay in sync with the Active Directory. This synchronization of the Dfs root and Active Directory (not the same as synchronization among Dfs replicas, described below) is triggered in three ways: