File and Print Services Technical Overview

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.


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 both 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.

On This Page

File Services
Indexing Service
Storage Management Services
Printing Services
Existing NT File & Print Servers


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-in1 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 tree2.

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

Dfs root. The share at the top of the Dfs topology, which is the starting point for the Dfs links and shared folders that make up the Dfs namespace.

Dfs link. Located under the Dfs root, a Dfs link forms a connection to one or more domain-based volumes or shared folders, or to another Dfs root. (In Dfs 4.x in Windows NT terminology, a Dfs link is called a child node or junction point.)

Dfs shared folder. Files or folders in the Dfs namespace that can be accessed by users who have proper permissions.

Replica set. Two or more Dfs roots or Dfs shared folders that participate in replication.

Replica. A folder within a replica set.

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 topology3 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 Directory4. 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:

  • Startup. When a server hosting a domain-based Dfs root boots, the booting server obtains the PKT from an active domain controller.

  • Changes. When changes are made to the PKT (changes are made in Active Directory itself), all participating Dfs root servers are notified that changes have occurred that the servers must retrieve from the directory.

  • Set interval. Domain-based Dfs root servers poll the directory service for current PKT information every 24 hours.

Dfs Replication and FRS Synchronization

Users access certain files frequently over the network. When only one copy of a file exists on a single file server, if that server goes down, no one can access the file. A different problem arises if many users access a single file simultaneously—the server experiences a heavy processing load, resulting in slower access to files on that server. Using Dfs replication helps solve these problems of availability and load. The following subsections describe how Dfs uses replication to accomplish these tasks:

  • Replica sets provide high availability

  • FRS keeps replicas that change synchronized

  • Replica sets help reduce file server load

  • Replica sets make file server maintenance easier

Replica Sets Provide High Availability

High availability refers to keeping important data available, even if a server or disk drive fails or a shared folder or file becomes corrupted. To ensure that the Dfs root server itself remains available, you can use Dfs Administrator to create two kinds of replica sets. A replica set is two or more copies of a Dfs root or Dfs shared folder that participate in replication. Here are the two types of replica sets:

  • Dfs root replicas replicate Dfs "knowledge." In domain-based Dfs, you can create Dfs root replicas, that is, two or more copies of the Dfs root, each on a different server. As stated above, a Dfs root replica uses the PKT (which contains the Dfs topology, including mappings from the Dfs logical namespace to the underlying physical shares) to provide referrals to clients. This is why replication of Dfs roots is also referred to as replication of Dfs knowledge.

  • Dfs link replicas replicate Dfs "content." When you create a Dfs link, you can create a replica set by specifying multiple shared folders for that link. Each copy must be located on a separate computer, but all share the same logical Dfs name. The fact that more than one copy (which can be read-write copies) exists is transparent to users. You can specify hundreds of shared folders in a replica set. Just as Dfs root replicas support high availability for Dfs roots, Dfs link replicas support high availability for a portion of the Dfs namespace.

In Figure 3, below, the box labeled "Replicating Dfs Root" shows two Dfs root servers. The two shares hosting the root are a replica set. (Any new content local to those roots is kept consistent by FRS; see the next subsection, "FRS Keeps Replicas That Change Synchronized.") The box labeled "Replicating Dfs Links" shows two shares published as a single Dfs link. Content on these two shares is also held consistent by a separate FRS replica set.

Figure 3: File replication of Dfs roots and Dfs links.

As already explained, you create Dfs root replicas to provide high availability for a Dfs root server. However, because the Dfs root uses the PKT, providing high availability for Dfs root replicas is a more complicated issue than providing high availability for Dfs links. For Dfs links, simply establishing replica set replication provides high availability. For a domain-based Dfs root, the PKT is stored in and must be fetched from Active Directory. Because each participating Dfs root server sends its PKT changes to Active Directory, all other participating Dfs root servers must periodically obtain the updated PKT from the directory. Therefore, although you can establish Dfs replication for your network without also setting up Active Directory replication5, without Active Directory replication it is not possible for Dfs replication to optimally ensure high availability of Dfs data. Active Directory replication is required to ensure the availability of the PKT—if one domain controller fails, Dfs can obtain the PKT from another domain controller.

Establishing replica sets and keeping them synchronized are related but separate issues. For information on when and how to implement synchronization, see the next sub-section.

FRS Keeps Replicas That Change Synchronized

Windows 2000 Server introduces the File Replication Service (FRS) to provide full two-way file replication for NTFS 5 volumes. This replication is implemented with NTFS Change Journal update sequence numbers (USNs) (see also the section "NTFS Change Journal" later in this paper). FRS is a multimaster file-based replication service6 and uses remote procedure call (RPC)-based connections. FRS lets you adjust the schedule for file replication and specify what gets replicated and which replica sets need to be kept synchronized.

FRS is used—for different purposes—by both Dfs and by Active Directory:

  • FRS & Dfs roots. Domain-based Dfs root replicas are always dynamic because (at the least) they need to keep updating the PKT (recall that the PKT, which contains the Dfs topology, is stored in Active Directory). Therefore, by default, FRS is always activated for domain-based Dfs root replicas.

  • FRS & Dfs links. By default, FRS is not enabled for Dfs replica sets because data contained in them could be static. In most cases, however, you do want to ensure that the underlying shared folders for Dfs links are kept synchronized to present the same data to users regardless of the folder they access. Microsoft strongly recommends using FRS for automatic replication of Dfs shared folders.

    An example of when it is not necessary to activate FRS for Dfs link replicas is if you keep read-only shares of site-licensed software on servers for employees to install when needed. These applications can be replicated to Dfs share points in multiple sites so that users can install up-to-date versions from nearby servers, but it is not necessary to activate FRS because the applications are read-only.

    Whether or not to implement FRS for shared folder replica sets also depends on whether the network has sufficient bandwidth to handle the traffic generated by automatic file replication.

  • FRS & Active Directory. In an Active Directory environment (that is, on a Windows 2000 domain controller), certain system files are not stored in the Windows 2000 directory information tree (DIT) database and are therefore not replicated by Active Directory object replication. These system files are stored in a shared folder called the system volume (SYSVOL). SYSVOL is installed as a part of the domain controller promotion process (Dcpromo.exe). FRS replicates the SYSVOL folder among participating domain controllers and keeps the replicas synchronized. (FRS replication of SYSVOL is an activity that is entirely independent of Active Directory object replication. Note also that, although Active Directory uses FRS to replicate SYSVOL, Active Directory replication does not use FRS because FRS has its own replication engine.)

Figure 4 summarizes features of Dfs and FRS:

Figure 4: Dfs and FRS features

Replica Sets Help Reduce File Server Load

Load sharing automatically distributes file access across multiple disk drives or servers, thus improving server response time to client requests during peak usage periods. Dfs provides a degree of load sharing by taking advantage of the share redundancy provided by replica sets just described in the preceding section.

Replica Sets Make File Server Maintenance Easier

Using Dfs replicas, you can often perform file server maintenance, software upgrades, and other tasks without disrupting user access. When two or more root replicas exist on two or more servers, you can take one server offline for maintenance without disrupting users because the Dfs share remains available on the replica(s).

Dfs Intelligent Client Caching

When you add a Dfs link, in addition to specifying a name and path for the link, you also specify the duration for which a reference to this Dfs link will be cached locally on a Dfs client. The first time a client machine requests a referral for a Dfs link, the client contacts the Dfs root server, which uses the PKT stored in Active Directory to direct the client to the share. However, subsequent requests for the same referral are handled from the client's cache. Therefore, the client does not need to access the Dfs server after the first referral unless the cache entry has expired. Caching thus allows quick access to frequently used network volumes, improving performance by reducing the processing load on the Dfs server.

Dfs Uses Standard Security

Windows 2000 Dfs saves time for administrators because, other than creating the necessary administrator permissions, the Windows 2000 Dfs service does not require the implementation of any additional security measures.

Only administrators can make changes to the Dfs topology (enterprise and domain administrators for domain-based Dfs; local administrators for stand-alone Dfs). All other security is enforced by the file system underlying the network share referenced by Dfs. That is, when a user tries to access a Dfs shared folder or the files inside it, whether or not that access succeeds depends on the underlying file system. A volume formatted with FAT is protected by share-level security; a volume formatted with NTFS has both share-level and file-level (NTFS) permissions.

IIS Can Use Dfs

Internet Information Services 5.0 (IIS), which installs as a networking service of Windows 2000 Server, can take advantage of Dfs to make management of a Web site easier. If all the data for a website is stored on a single machine, Dfs has no role to play. However, if the HTML files backing a Web server are stored on multiple machines, using Dfs can simplify Web site management by grafting the multiple network shares into a unified namespace.

A Webmaster can now build a logical Dfs directory that includes the default Web pages of each department's Web server as a subdirectory of the main Internet or intranet Web. If a Web page is physically moved from one server to another, the HTML links to other pages stored in Dfs do not have to be updated, provided an administrator reconfigures Dfs accordingly (using the Dfs Administrator tool). This means that if the server hosting a user's Web page is removed and the page is republished on a different server, the links pointing to that page do not have to be reconfigured.

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

Dfs server enhancements7 include the following:

  • Windows 2000 installs the Dfs service automatically during installation of (or upgrade to) the Windows 2000 operating system.

  • You can pause or stop the Dfs service, but you cannot remove it from the administrative console.

  • The Dfs topology is stored in Active Directory for domain-based Dfs.

  • Dfs is integrated into the Active Directory namespace for domain-based Dfs.

  • Replicated Dfs roots eliminate the root as a single point of failure.

  • Support for FRS permits automatic replication of file changes between Dfs replicas.

  • The Dfs administrative tool is now graphical.

  • Status flags indicate the availability of replicas.

  • Dfs links can connect to other links on other Windows 2000-based servers without a fresh referral.

  • The expiration of referrals that are cached by Dfs clients is configurable on an individual link basis.

  • Dfs now supports dynamic configuration of the Dfs topology.

  • Dfs now supports Cluster service.

Microsoft first introduced the NTFS file system (NTFS), a 64-bit advanced file system for storing data on hard disk, with Windows NT® 3.1 and now adds significant enhancements to NTFS in Windows 2000 Server. Windows NT 3.51 and Windows NT 4.0 both use NTFS version 4. Windows 2000 uses NTFS version 5 (during setup, NTFS 4 partitions are automatically converted to NTFS 5). The minimum size for an NTFS volume is 10 megabytes (MB); the recommended practical maximum is 2 terabytes. The maximum theoretical file size is 16 exabytes.

Windows 2000 Server continues to support the advanced features NTFS provided to earlier versions of the operating system, including:

  • File-level access control. NTFS governs which users and groups can access individual files and directories, and it can provide varying levels of access for different users. This is then enforced by the core operating system. The NTFS file permissions are No Access, List, Read, Add, Add and Read, Change, Full Control, Special Directory Access, and Special File Access (which provides an even greater degree of granularity). File-level access control does not include file encryption; for Windows 2000 file encryption, see the section "Encrypting File System."

  • Compression. NTFS compression allows for the compressed storage of files and directories so that less physical space is required. Compression is configurable on a volume, directory, or file basis. With NTFS, if anything goes wrong physically with a portion of data in a compressed file, only that file is affected. This differs from earlier FAT compression on Windows 95 and Windows 98, which could lose an entire volume of data if even one sector became corrupted.

  • Recovery log. NTFS logs all changes to the file system so that every file or directory update can be redone or undone to correct discrepancies caused by system failure or power loss. NTFS cluster remapping—called sector/cluster hot fixing—repairs hard disk failures on the fly without returning error messages to the calling application. If the data is corrupt, NTFS flags that part of the hard disk as defective, and then rewrites the data to another location. Recovery log operations are fast and transparent to users.

  • POSIX support (available only when running the POSIX subsystem). NTFS file names support the Portable Operating System Interface for UNIX (POSIX) standard for network naming conventions, such as case sensitivity, last-access timestamping, and hard links.

New features in Windows 2000 Server—its directory service (Active Directory), the IntelliMirror™ set of management features, and many new storage improvements—require an update to the on-disk format for NTFS. Windows 2000 Server requires the use of the updated NTFS format on all domain controllers. Among the storage-related improvements that use the new NTFS format are volume mount points, remote storage, file system encryption, sparse files, disk quotas, and Microsoft Indexing Service (all described later).

For existing NTFS volumes, the upgrade to the NTFS 5 on-disk format occurs automatically at the volume's first mount time; for volumes that setup uses, this conversion occurs during installation. In addition, setup asks if you want to convert your FAT and FAT32 volumes, but doing so is optional. You can manually convert FAT and FAT32 volumes to NTFS 5 at any time. Servers that dual boot Windows 2000 Server and Windows NT Server 4.0 must install Windows NT 4.0 Service Pack 4 or higher in order to access local NTFS 5 volumes when running Windows NT 4.0. All network clients can remotely access NTFS volumes on Windows 2000 file and print servers. Whether a volume is formatted with NTFS 4 or NTFS 5 is transparent to the network client.

Applications that assume knowledge of a volume's on-disk format must be updated. To learn more about how to do this, see the section "For More Information."

Enhancements that Windows 2000 Server adds to NTFS include:

  • NTFS reparse points and file system filter drivers

  • Encrypting File System (EFS)

  • NTFS volume mount points

  • NTFS sparse file support

  • Native property sets

  • Security ID (SID) searching and bulk access control list (ACL) checking

  • NTFS Change Journal

  • Distributed Link Tracking

The following subsections describe each of these topics.

NTFS Reparse Points and File System Filter Drivers

Windows 2000 Server introduces reparse points and installable file system filter drivers into its storage subsystem to provide additional features and to give independent software vendors (ISVs) a consistent mechanism for extending storage functionality.

Reparse points are NTFS file system objects that have a special file attribute called a reparse tag. One reparse point is allowed per file or directory. Input/output (I/O) calls use these tags to differentiate types of reparse points. ISVs must apply to Microsoft for a reparse point tag value.

Installable file system filters are kernel-level device drivers that let ISVs intercept file system calls. When used in conjunction with ISV-provided file system filter drivers, reparse points offer a mechanism for providing file and directory enhancements to existing storage applications and enable new types of storage management applications, such as Remote Storage.

The Windows 2000 Server implementation of reparse points and installable file system filter drivers frees ISVs from the need to write proprietary system functionality. They can instead concentrate on responding directly to customers' business needs. Besides developing reparse points and installable file system filter drivers for third-party developers to use, Microsoft introduces several Windows 2000 Server services of its own based on these features. These include:

  • Encrypting File System (EFS)

  • NTFS volume mount points

  • Remote Storage

This paper covers the first two of these features in the immediately following two subsections and the last one in the "Storage Management Services" section.

Encrypting File System

With the Encrypting File System (EFS), Windows 2000 Server provides protection for sensitive user data stored on the NTFS 5 file system. EFS is not a file system, but rather a service that provides file-level encryption for locally stored data on an NTFS 5 volume. EFS uses cryptography to complement the existing access control security model on NTFS. This provides a new level of protection for data stored on disk. The encryption technology uses a combination of public key technologies for key management and symmetric cryptographic algorithms for data encryption.

In the past, someone with physical access to a computer could bypass earlier NTFS access control security. Therefore, to provide complete file system security it was necessary to ensure that the machine was not physically accessible to unauthorized people. In Windows 2000 Server, EFS addresses this problem. EFS strengthens NTFS's existing security by providing local file and directory encryption on NTFS volumes8. (EFS is intended to protect only data that you access locally. Data sent across the network is in clear text. If it were possible to access an encrypted file across the network, that would defeat encryption because a network sniffer could be used to read the data packets.)

Users can use Windows Explorer, administrative interfaces, or command-line tools to encrypt and decrypt files and directories they are authorized to use. Users do not need to decrypt a file before using it—the file is stored encrypted on the disk, and all reads and writes to it are decrypted and re-encrypted transparently. To see whether the file is encrypted, users can check the file properties to see if the encrypted attribute bit is on. Unauthorized users trying to open an encrypted file get an access denied error because they don't possess a key to decrypt the file.

To read more about EFS, see the section "For More Information."

NTFS Volume Mount Points

As an alternative to assigning a drive letter to a mounted drive, Windows 2000 can assign a drive path. This means you are no longer limited to 26 drive letters for mounting and accessing volumes. For example, if you have a CD-ROM drive currently assigned to the D: drive and you have an NTFS-formatted C: drive, you can mount the CD-ROM drive at an empty folder with the following path: C:\CD-ROM. You can then remove the drive letter D: (or use it for something else) and can access the CD-ROM through the mounted drive path.

This is made possible by NTFS volume mount points, which are new file system objects. Placing a mount point (which is implemented as an NTFS reparse point) on a directory maps one disk volume under a directory of another volume. Because volume mount points are based on NTFS 5 reparse points, they work only on NTFS 5 volumes. Multiple volume mount points can target any volume. Windows automatically prevents resolution problems due to changes in the internal device name of the target volume (for example, changes due to hardware device reconfiguration).

Say a laptop user has two logical volumes: he or she uses one to store operating system and personal files and the second to store work-related data. Most personal productivity tools are set to open/save work at a common directory (such as C:\My Documents). It would be convenient not to have to change drives depending on whether personal or work-related data is being used. The user can use the Disk Management utility to place an NTFS volume mount point in the C:\My Documents\Work directory so that it and its subdirectories will use physical disk space on drive 2. Changing directories to C:\My Documents\Personal, however, would access drive 1. Figure 5 depicts this situation.

Figure 5: Example of volume mount points

Although this simple example demonstrates the use of an NTFS volume mount point, the real power of NTFS volume mount points is in enterprise server environments where volumes are frequently added in response to data growth.


  • You cannot mount a network drive with an NTFS volume mount point; instead, you can use Dfs to do this.

  • The system does not check for loops in the namespace. Although it is possible to mount a drive underneath itself to create a loop, doing so is not recommended because applications that do recursive opens against directories (using FindFirst/FindNext) will go into an infinite loop.

NTFS Sparse File Support

A very large file without a lot of data is said to contain a sparse data set (sparse data has large consecutive areas of 0 bits). Applications that use sparse data sets include image processors and high-speed databases. In versions of NTFS prior to version 5, the portions of the file that did not contain useful data occupied valuable disk space.

The file compression introduced in NTFS 3.51 was a partial solution to the problem. The portions of the file that do not contain useful data were set to zero, creating large consecutive areas of 0 bits, and file compression compacted the non-data portions. However, file compression has its own drawbacks: access time may increase due to data compression and decompression.

NTFS 5 introduces another solution to the problem of sparse data, which both conserves disk space and improves disk performance. An administrator or application can use a new user-controlled file system attribute to mark files containing large consecutive areas of 0 bits as sparse, and NTFS will then allocate physical space for only the meaningful data (that is, to only those portions of a sparse file that are actually written to). NTFS stores only range information that indicates where the sparse data would be if it were allocated. On file access, the file system returns allocated data as actual and deallocated data as zeros. APIs let application developers bypass file expansion and read the allocated ranges directly. This enables applications to avoid processing large streams of zeros yielded by the file system and to copy or move potentially huge files with sparse data streams in an efficient manner.

For example, if data is written to the first 64 KB and last 64 KB of a 42 GB file that is marked as a sparse file, NTFS uses only 128 KB of disk space, although in other respects the file functions as if it were 42 GB.

Native Property Sets

Native property sets let any file or folder on an NTFS 5 volume have descriptive metadata associated with it. NTFS 5 supports native property sets on any file or folder. For example, Component Object Model (COM)9 documents, such as Microsoft Word or Microsoft Excel files, have associated properties, including Author, Title, Subject, and Comment. With NTFS 5, any file can have associated properties, even single-stream text files.

The new Indexing Service feature in Windows 2000 can index all properties on a file, including both NTFS native properties and COM document properties. The result is that users can quickly search the index not only for files containing specified words in the file contents but also for properties of the files—for example, they can search on properties such as document author. (To see the properties for a file or directory, right-click on it and select Properties.)

SID Searching and Bulk ACL Checking

In Windows 2000 (and Windows NT) a security ID, or SID, is a unique number that identifies each user, group, or computer account to the Windows security systems. Windows issues a SID to every account on the network when the account is first created. Internal processes in Windows 2000 refer to an account's SID rather than to its user, group, or computer name.

NTFS 5 can perform a volume-wide scan for files using the owner's SID. This feature lets administrators perform such tasks as finding all files that a given user owns and cleaning up a user's files.

An access control list (ACL) allows or denies permissions (also called access rights) on a file or folder to specific users or groups. File permissions include Full Control, Modify, Read and Execute, Read, and Write. Folder permissions include Full Control, Modify, Read and Execute, List Folder Contents, Read, and Write.

Windows 2000 offers substantially improved storage for ACLs. Because Windows 2000 uses an ACL index, unique ACLs are stored only once. Any files that use the same ACL share an index entry, unlike Windows NT 4.0, which stored ACLs on each file. That is, NTFS stores unique ACLs only once even if ten objects share the ACL; in Windows NT 4.0, the ACL would be stored ten times.

Indexing Service uses the Bulk ACL Checking feature to efficiently check security on all files returned by a search. Using Bulk ACL Checking ensures that a reference to a file the user cannot read is not returned. In addition, NTFS 5 uses Bulk ACL Checking to test for authorization against multiple files at once. This lets you perform tasks such as determining what a given user can do with given files or checking multiple ACLs simultaneously for file access.

NTFS Change Journal

Windows 2000 Server introduces the volume-wide Change Journal10 to track modifications to NTFS 5 files over time and across system reboots. The Change Journal itself is a sparse stream, which means that only a small active range of the file uses any disk allocation (see the earlier section "NTFS Sparse File Support"). As files, directories, and other NTFS objects are added, deleted, and modified, NTFS enters records into the Change Journal in streams, one record for each volume on the computer. Each record indicates the type of change (read, write, move, and so on) and the object that was changed. The offset from the beginning of the stream for a particular record is called the update sequence number (USN). New records are appended to the end of the stream.

The Change Journal logs the fact of the change to a file and the reason for it. However, it does not record enough information to reverse the change.

ISV developers of system-level applications such as file system indexing engines, content replication engines, and storage archiving and migration can make use of the Change Journal to provide enhanced functionality: Applications that periodically scan the file system for changes can now, instead, use the Change Journal without resorting to namespace traversal. For large volumes, this can reduce the time for scan operations from hours to seconds. For example, a backup application can consult the Change Journal to build its list of files before performing an incremental backup.

Distributed Link Tracking

Distributed Link Tracking lets client applications track link sources that have been moved. NTFS 5 implements a volume-wide indexed unique object identifier (OID) for each file. This OID lets the new Distributed Link Tracking feature preserve shortcuts and object linking and embedding (OLE) links—such as a Microsoft Excel worksheet embedded in a Microsoft Word document—to NTFS files that have undergone a name and/or path change, including a move to a different volume or computer. For example, a client application can continue to access a linked database, even if the database location has changed.

Other Supported File Systems

Windows 2000 Server supports multiple file systems. Some provide backward compatibility and others offer access to the latest storage media.

FAT16 and FAT32

To provide backward compatibility, Windows 2000 Server continues to support the FAT16 file system used originally in MS-DOS®, Windows 3.1, early Windows 95, and OS/2. Today, almost all computers and operating systems can read FAT16 volumes. FAT16 volumes range from floppy disk size to a maximum of 4 GB. Maximum file size is 2 GB. However, for best performance, volumes that are 2 GB in size or larger should be formatted using FAT32.

Windows 2000 Server introduces support for the FAT32 file system used until now only by Windows 95 OEM11 Service Release 2 (OSR2) and Windows 98. FAT32 supports volumes from 512 MB up to 2 terabytes (TB) in size. Maximum file size is 4 GB. For performance reasons, Windows 2000 will not let you create FAT32 volumes larger than 32 GB (to create volumes larger than 32 GB, use NTFS). However, an existing FAT32 volume of any size (created by Windows 95 OSR2 or Windows 98) can be mounted. FAT32's smaller cluster size gives a 20 to 30 percent increase in disk space efficiency over FAT16.

To dual boot Windows 2000 and another non- Windows NT–based operating system, the system partition must be formatted with either FAT16 or FAT32, whichever is appropriate:

  • FAT16. Format the partition using FAT16 if the installation partition is smaller than 2 GB, or if you are dual booting Windows 2000 and MS-DOS or Windows 3.1.

  • FAT32. Format the partition using FAT32 if the installation is 2 GB or larger and you are dual booting with Windows 95 OSR2 or Windows 98.

Compact Disk File System

Windows 2000 Server continues to support the Compact Disk File System (CDFS), which lets data be read from CD-ROM devices. The Microsoft implementation of CDFS meets the ISO12 9660 specification.

Universal Disk Format (UDF)

Windows 2000 Server introduces support for the Universal Disk Format (UDF) file system defined by the Optical Storage Technology Association (OSTA)13. UDF is compliant with ISO-13346; Windows 2000 supports version 1.5. UDF is the successor to CDFS (ISO 9660), and is also used for data interchange between operating systems and for digital versatile disk (DVD)14.

Currently, Windows 2000 Server supports read-only operations for UDF, but will support write operations in the future.

Indexing Service

Under Windows NT Server 4.0, Content Indexing Server shipped as part of the Microsoft Internet Information Server (IIS), giving customers full text indexing and searching of documents located on their Web sites. However, Windows 2000 Server ships Microsoft Indexing Service as part of the base operating system. This development extends the indexing and searching services to locate information on file servers as well as on Web sites.

Windows 2000 Server (and Professional) Indexing Service indexes file system objects and intranet and Internet Web sites across volumes and machines so that they can be searched by network, intranet, and Internet users alike. Making these search activities look similar to the user saves an organization time and money in training and supporting employees. All Indexing Service operations are automatic, including index creation, index updating, and crash recovery in the event of a power failure.

To access Indexing Service in the Computer Management console, click Start, point to Settings, and then click Control Panel. Double-click Administrative Tools, and then double-click Computer Management. Figure 6 shows Indexing Service under the Services and Applications node of the Computer Management console.

Figure 6: Indexing Service snap-in.

These Indexing Service topics are covered in the following sections:

  • 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

Indexing Service Structure

The Indexing Service feature itself consists of two types of data: the actual index server and the catalog or index data structures:

  • The index server can exist on any Windows 2000 computer and consists of binary files and registry entries similar to many other Windows services. The server's components are backed up with all other components on the volume.

  • The catalog files can be on any volume local to the index server service. You can also back up and restore catalog files using the Windows 2000 backup utility. (For more about catalogs, see the next subsection.)


Indexing Service builds and maintains catalogs of the contents of local and remote disk drives. A catalog consists of index information and stored properties for a particular group of directories.

At installation, Indexing Service creates the following two catalogs by default:

  • System catalog. When Indexing Service is installed with Windows 2000 Server, it automatically builds the System catalog, which, by default, lists all directories on all permanently attached disk drives. It contains an index for all file system documents (except certain system and temporary files).

  • Web catalog. If Internet Information Services (IIS) is installed, Indexing Service also creates a Web catalog, which contains an index of the content of IIS, the default virtual server of the World Wide Web for Web pages stored on a Windows 2000 Server server.

Using the Indexing Service snap-in, you can configure existing catalogs and can add and remove additional catalogs at any time. After you add a catalog, you must add the directories to be included within the catalog's scope. This is the set of directories that the catalog covers, both those to be indexed and those specifically excluded from being indexed. For each included or excluded directory, all of its subdirectories are also included or excluded.

Indexing Service is tightly integrated with NTFS 5 and makes use of the new NTFS feature Native Property Sets (described earlier in the "NTFS and Related Enhancements" section). The index includes all words in the content of each document and all properties. Document properties are items of information about the document, such as file name, date created, date modified, author name, number of characters, and, for Windows 2000 NTFS documents, all the Microsoft Office summary information properties as well. Many property values are set automatically by the application that creates the document. In addition, users can create custom properties for any file on an NTFS 5 volume.

Users can search for documents that contain specific words or phrases or for properties. For example, you can search for all documents containing the word "product" or for all Microsoft Office documents written by Kyle. Indexing Service can index the following types of files:

  • Text

  • HTML

  • Microsoft Office 95 and later

  • Internet mail and news

  • Any other file for which a document filter is available

Search and Retrieval

Users can perform searches using the Windows Explorer search pane, the Start menu's Search function, the Indexing Service MMC snap-in query form, or a Web browser (using a Web page created by the Webmaster or administrator). If the indexed results are stored on a local NTFS volume, access privileges determine whether a document is returned in the result set. In other words, a user who does not have at least Read access will not know that the document exists because NTFS will not return even a reference to the document.

When results are returned on a Web page, Indexing Service can rank hits according to how well they fit the query criteria, and it can sort results on multiple levels according to the value of any document property. When results are returned in the regular Windows user interface, the user can sort the documents by rank. The administrator can limit the maximum number of hits returned to the user.

Indexing Control and Speed

You can control what content is indexed and can set indexing on a per-file and/or per-directory basis. No background indexing occurs when you are performing a server management task. Better tracking of user activity and input/output make faster indexing and query results possible. You can also set the priority of the indexing task by stopping the Indexing Service, selecting All Tasks, and then selecting Tune Performance.

Detecting Changes Using NTFS Change Journal

Indexing Service uses the NTFS volume Change Journal to detect file additions, deletions, and modifications, even when the service is not running. This eliminates costly file rescans and improves performance. (The NTFS Change Journal is described earlier, in the section "NTFS and Related Enhancements.")

Index Storage Using Sparse Streams

Indexing Service uses NTFS sparse streams for index storage, which lets index optimization occur using the existing allocated disk space. (NTFS sparse files support is described earlier, in the section "NTFS and Related Enhancements.")

Integrating Searches into Applications

In Windows 2000 Server, programmers and script writers can take advantage of the native indexing and search features using Microsoft ActiveX® Data Objects (ADO) and OLE-DB interfaces. (Both interfaces provide a consistent way to access data regardless of how the data is structured). This lets ISVs integrate full text and property searching into their applications.

Remote Storage and Retrieval Integration

Indexing Service includes Remote Storage content in its searchable index. Remote Storage, which is the Windows 2000 version of Hierarchical Storage Management (HSM), stores content remotely, retrieving it only when needed. Indexing Service lets users search for files in both the local volume and in remote storage. Archived data can be indexed and searched without users knowing that it is no longer stored on the local volume, thus freeing up storage without having to buy additional hard disks. (See the subsection "Remote Storage" in Storage Management Services).

Mount/Dismount Tracking

This feature lets indexing interact invisibly with the CHKDSK and format utilities. More important, it lets you index and store catalogs on removable disks, such as Jaz and Zip cartridges.

Storage Management Services

The quantity of data stored on distributed systems has increased exponentially over the last decade. As the number of client/server systems increases in an organization, so does the number of storage subsystems. Up to 25 percent of a typical computing budget is spent on storage. The kind of data stored on client/server systems is changing as well—growth in Internet/intranet usage and in 32-bit/64-bit architectures are major contributors to the changes in types of data found in the distributed network. These developments are accelerating the creation of large volumes of data and resulting in increased storage requirements at proportionately increased cost.

Windows 2000 Server offers several new or improved features that improve storage and reduce its cost. These include:

  • New disk architecture

  • Defragmentation utility

  • Remote Storage service

  • Removable Storage service

  • Disk quotas

  • The Single Instance Store (SIS)

  • System File Protection

  • Storage support for hardware innovations

Each of these features is described in the following subsections.

In addition, Windows 2000 Server includes many enhancements that provide ISVs the infrastructure they need to write enterprise-class storage applications and features. Also new in Windows 2000 Server is the Microsoft Management Console (MMC), which lets administrators and ISVs create the administrative tools called snap-ins that manage Windows 2000 components and services. ISVs should plan to write an MMC snap-in as part of the administrative user interface for their storage solution.

New Disk Architecture

Windows 2000 Server supports two types of disk storage:

  • Basic disks, divided into partitions, are the type of disk used by Windows before the introduction of the Windows 2000 operating system. The Fault Tolerant Disk manager (FT Disk), present in Windows NT 4.0, manages Windows 2000 basic disks and legacy FT Disk volume sets from Windows NT 4.0. A basic disk is characterized by the placement of a few kilobytes of data (a signature) at the beginning of the disk. Basic disks can by partitioned with and recognized by Microsoft MS-DOS, Windows 95, Windows 98, and Windows NT.

  • Dynamic disks, divided into volumes, are unique to Windows 2000. The new Logical Disk Manager (LDM) manages dynamic disks and all new volume sets. (Dynamic disks do still have partitions at the disk level, but these partitions are not shown in the user interface.) LDM places a 4 MB soft volume database for storing metadata at the end of any physical disk containing an LDM volume in addition to the few kilobytes of data at the beginning of the disk that are characteristic of basic disks. The 4 MB database is replicated among all dynamic disks in the system. Dynamic disks can contain simple volumes, spanned volumes, stripe volumes, mirrored volumes, and redundant array of independent disks level 5 (RAID-5) volumes.

Figure 7 shows the new Windows 2000 disk architecture.

Figure 7: Basic and dynamic disks in Windows 2000 Server

New disks are installed as dynamic disks. By default, existing system disks are installed as basic disks, which you can convert to dynamic disks. Both basic and dynamic disks can be formatted with FAT, FAT32, or NTFS. If you don't do so at installation, you can upgrade from basic storage to dynamic storage at any time. When you do so, existing partitions are converted into volumes, as shown in the following table:

A basic disk partition, logical drive, or set

… becomes a dynamic disk volume

A partition (including system, boot, primary, and extended partitions) becomes…

…a simple volume (can be extended if NTFS 5; has a single dynamic disk partition, but cannot contain NT4 and earlier partitions or logical drives)

A logical drive becomes…

… a simple volume

A volume set becomes…

… a spanned volume

A mirror set becomes…

… a mirrored volume

A stripe set becomes…

… a striped volume

A stripe set with parity becomes…

… a RAID-5 volume

Disk and Volume Management Features

The Disk Management MMC snap-in (which replaces the Windows NT Server 4.0 Disk Administrator utility) displays disks and volumes in either a graphical view or a list view. It offers the following features:

  • New user interface. The Disk Management feature's shortcut menus show which tasks you can perform on the selected object, and wizards guide you through initializing or upgrading disks and creating partitions or volumes.

  • Fewer reboots. With dynamic volumes formatted with NTFS 5, you can often add disks and create, extend, or mirror a volume without rebooting, letting users work without interruption and saving administrators' time.

  • Self-describing disks. The operating system keeps disk configuration metadata on each disk and replicates it. This is a change from Windows NT Server 4.0 and earlier, which stored configuration metadata in the registry. Self-identification of managed disks ensures that disk controller and other disk reconfigurations or cluster disk ownership transfers are error-free.

  • Volume mount points. You can use Disk Management to connect to, or mount, a local drive at any empty folder on a local NTFS-formatted volume (see the subsection "NTFS Volume Mount Points").

  • Volume GUIDs support Plug and Play. Unique disk signatures identify both basic partitions and dynamic volumes. Disk signatures associate partitions or volumes with their assigned logical names. The disk signature lets FT Disk or the LDM accurately identify a partition's or volume's presence or absence in environments that implement Plug and Play storage devices.

Disk and Volume Management Tasks

The following table lists the specific operations you can perform with the Disk Management snap-in:


Same for basic and dynamic disks

Same for basic disks and dynamic volumes

Manage disks on a remote computer.
Add a new disk.
Move disks to another computer.
View disk properties.
Update disk information.
Reactivate a missing or offline disk.
Upgrade a basic disk to a dynamic disk.
Change a dynamic disk back to a basic disk. (Note: This destroys all data on the disk.)
Restore disk configuration information from previous versions of Windows NT.

View properties.
Assign, change, or remove a drive letter (you cannot change drive letter of system or boot volume)
Create a mounted drive (partition or volume is assigned a drive path, not a drive letter)
Format a partition or volume.
Delete a partition or volume (you cannot delete system volume, boot volume, or volume that contains the active paging file).


Dynamic Volumes

Basic Disks

Manage spanned volumes (correspond to volume sets in Windows NT 4.0).
Manage mirrored volumes (correspond to mirror sets in Windows NT 4.0; provide fault tolerance).
Manage striped volumes (correspond to stripe sets in Windows NT 4.0).
Manage RAID 5 volumes (correspond to stripe sets with parity in Windows NT 4.0; provide fault tolerance).

The management tasks listed in the left column are the same on basic disks, except that:
You cannot create new spanned, mirrored, or striped sets on basic disks, and you cannot extend a spanned volume.


Dynamic Volumes Only

Basic Disks Only

Create, extend, and delete simple volumes. Simple volumes are the dynamic storage equivalent of Windows NT 4.0 (and earlier) primary partitions. When you have only one dynamic disk, the only kind of volume you can create is a simple volume.

Create and manage primary partitions, extended partitions, and logical drives.
Mark a partition as active on an Intel-based computer.

Defragmentation Utility

The disk defragmentation utility is another Windows 2000 Server enhancement that improves storage management. The utility tells the file system to move the data from one sector to another. The fact that the file system—rather than the defragmentation utility—moves the data makes the system far more robust.

Administrators or users can defragment volumes formatted for FAT, FAT32, or NTFS, which improves performance if the fragmentation is extensive. This utility can operate while the system is up and running and disks are in active use. You can defragment only local volumes and only one volume at a time.

Remote Storage

The Remote Storage service, which is the Windows 2000 version of Hierarchical Storage Management (HSM), helps manage the cost associated with large quantities of data that must be kept accessible. The Remote Storage hierarchy consists of two layers:

  • Local storage refers to the NTFS volumes local to the Windows 2000 file server15 hosting the Remote Storage software.

  • Remote storage refers to data moved from the local hard disk to a remote storage device (such as tape) that can be recalled whenever needed.

If a file has not been used in the past thirty days, there is a high probability that it will not be accessed again. These infrequently used files consume the majority of disk space, and it is these files that Remote Storage typically migrates to secondary storage. Remote Storage automatically moves data back and forth between high-cost, faster disk drives and low-cost, high-capacity storage media (tape library). Remote Storage monitors the amount of space available on local NTFS volumes, and when the amount of free space dips below the needed level, eligible files are transferred from the hard disk to secondary storage. Yet, the user still sees and can still access these archived files. This frees up storage on the file server without requiring the purchase and installation of additional hard disks.

Remote Storage storage media are not a substitute for primary backup media. Remote Storage is typically used to migrate infrequently used data, so frequently used data, which is more likely to be urgently needed, is less likely to be stored on Remote Storage media. The purpose of Remote Storage is to ensure free space on file server volumes, not to protect enterprise data.

Applications running on NTFS volumes that regularly open many files can cause a great deal of data to be recalled, and thus reduce the efficacy of Remote Storage. For best results, use Remote Storage-aware applications.

Managing Remote Storage

The Remote Storage service is not installed by default when you run Windows 2000 Server setup, but you can choose to install it during setup or afterwards. Before setting up Remote Storage, you must ascertain that remote storage media are available for it to use. The local disk volumes on the file server that are under Remote Storage control, called managed volumes, must be non-removable. Administrators who intend to use data compression on managed volumes should compress the volumes before installing Remote Storage. Administrators who intend to use content indexing must also first set up Microsoft Indexing Service.

The Remote Storage snap-in is comprised of four components, all of which run on both Windows 2000 Server and Windows 2000 Professional (the Remote Storage service runs only on Windows 2000 Server computers, not on Windows 2000 Professional machines, but the Remote Storage user interface runs on both):

  • Recall Notification user interface. This interface lets an administrator cancel a recall of remote data, if the recall is invoked before the data transfer has started.

  • Windows Explorer component. Remote Storage adds a new page to the file and directory property sheets accessible through Windows Explorer to represent storage management properties. These pages provide information on migration status, premigrated file data location in remote storage, premigrated date and time, and so on. Users have read-only access to the new Remote Storage property pages; however, they can force immediate premigration of individual files or entire directories by setting a Premigrate Now option on the Remote Storage page. (For an explanation of premigration, see next subsection).

  • Disk Management component. This component includes a property sheet showing total used space, free space, premigrated file space, truncated files (placeholders), untruncated file disk usage, premigration space savings, truncated file compression ratio, percent of files that are placeholders, and other volume report information. (For an explanation of premigration, truncation, and placeholders, see the next subsection).

  • Remote Storage snap-in. You can use the Remote Storage snap-in (one of the Administrative Tools, once it is installed) to establish the following two administrator-defined guidelines for a managed volume:

  • Desired Free Space. This specifies the amount of free space to be kept on the managed volume and triggers an automatic file truncation when the free space is too low.

  • File Selection Criteria. This specifies which files can be migrated to secondary storage. These settings include minimum file size and time elapsed since the file was last accessed. You can also specify file inclusion and exclusion rules. For example, you might specify that only files not accessed for at least three days should be migrated, and that executable files should be excluded from migration. Remote Storage cannot copy hidden, system, extended attribute, encrypted, or sparse files to remote storage. The selection criteria decision engine is extensible using a Component Object Model (COM) interface.

Premigration, Truncation, and Placeholders

Remote Storage scans a managed volume periodically for eligible data, premigrates (copies) eligible files to secondary storage, and attaches an NTFS reparse point to each copied file, but it does not otherwise modify the file at this point. More frequently than the scan that results in the copying of eligible files, Remote Storage also checks whether free space on the volume is at or above the specified threshold. If it drops below the threshold, Remote Storage then creates free space by truncating files that have already been premigrated to secondary storage. Before each file is truncated, Remote Storage uses the NTFS Change Journal to determine whether the data in secondary storage still represents the data in primary storage (primary storage refers to the NTFS volume local to the server running Remote Storage or mapped locally to that server by Dfs). If the primary data has changed, the file is not truncated—it is no longer considered premigrated and is returned to normal status.

After a file is truncated, what remains on the primary storage device—so that migrated files can be viewed in directories and recalled as needed—is an NTFS file, called a placeholder. The placeholder points to the complete copy now in remote storage. A placeholder has the system-defined $REPARSE POINT attribute set with information that can identify and retrieve the data from remote storage. The placeholder is marked FILE_ATTRIBUTE_OFFLINE. Although Remote Storage has changed the physical size of the file on local storage, the file's logical size and the date/time (create, last modified, last accessed) remain unchanged.

When a user or application reads, writes, or makes a memory map request for a truncated file, Remote Storage recalls the removed data from secondary storage and reconstructs the primary data stream. This operation is transparent to users and to applications (for example, it does not affect the Windows 2000 disk quotas feature, which monitors and limits disk space), except that I/O operations are blocked for several minutes until the requested data has been restored from tape.

Remote Storage initiates Automatic File Truncation whenever a managed volume's free space level goes below the specified Desired Free Space setting. You can also force the truncation of premigrated files to placeholders using Schedule File Truncation. In this case, premigrated files that have not been modified, and that meet the File Selection Criteria, are truncated regardless of the volume's free space level. You might do this in advance of a volume-intensive event, such as the installation of a large application.

In addition, you can use Validate Managed Files to ensure that all files on your managed volumes point to valid data in remote storage. Validation also detects files that have been moved from one local volume to another, or that have been modified. Validation is automatically performed two hours after a backup program is used to restore a remote storage file. You should also perform validation on a regular basis to correct inconsistencies, especially after restoring files on a local volume or after disk errors have occurred on a volume.

You can rename premigrated files and placeholders only on the same volume. Renaming does not cause the data to be recalled. If you copy or move placeholders between volumes, the data is recalled and the entire file (including the migrated data) is copied. At the completion of a move operation, the original placeholder file is deleted. You can also move a placeholder to another volume on the same system by using Windows 2000 Backup to backup the placeholder and then restore it to another volume. In this case, the moved placeholder correctly points to remote storage and can initiate a recall.

Remote Storage Interoperates with Related Tools

Remote Storage has been designed to work with the following software:

  • Job Scheduler. Remote Storage uses the Windows 2000 Job Scheduler to schedule Remote Storage jobs. Job status can be monitored from within the Remote Storage snap-in. Using the Job Scheduler, you can specify a job window that limits the amount of time spent in a single scan, which is useful if the system has a large amount of data to manage and the scan might take too much time. A bookmark is kept where the scan stopped, so the scan can continue from that point the next time it is run.

  • Removable Storage. Remote Storage uses Removable Storage to access the library tapes used for remote storage (see next section for more about Removable Storage). All tapes used by Remote Storage exist in a single application media pool that is automatically created during Remote Storage Setup. You use Removable Storage to verify that sufficient media have been moved to a free media pool, so that Remote Storage can use tapes from that pool if needed. You cannot move tapes from the Remote Storage application media pool to another application media pool. Remote Storage can support only a single tape type for use as remote storage. You specify which type is supported when you run the Remote Storage Setup wizard. You cannot change this type later.

  • Backup. Remote Storage interoperates with the updated Windows 2000 Backup utility to correctly handle data recovery. To prevent legacy backup applications from backing up Remote Storage files, set the registry value HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \RSFilter \Parameters \SkipFilesForLegacyBackup to 1.

  • Third-party applications. In addition to the cost savings in storage media that Remote Storage provides within a company, third-party developers also benefit from Remote Storage integration with the operating system. Instead of developing proprietary solutions, developers of applications such as backup programs, content indexing, and anti-virus agents can now easily create solutions by calling common APIs. However, because file recall involves latency (the delay experienced during data retrieval, when I/O operations are blocked until the requested data has been restored), developers of storage applications must be aware of possible interactions with Remote Storage.


Remote Storage supports NTFS security features and thus recalls a file only if the user has valid access to the placeholder pointing to the data in remote storage.

Removable Storage

The new Windows 2000 Removable Storage service manages removable storage media (tapes and optical disks) and robotic storage libraries attached to a computer running Windows 2000 Server (or Professional). Removable Storage moves media around within and between libraries and controls access to that media. Removable Storage consists of a user interface implemented as an MMC snap-in, a Windows 2000 service with API, and a database.

Removable Storage lets administrators perform the following tasks:

  • Create media pools (groups of media) and set media pool properties.

  • Insert and eject media in a robotic library.

  • Mount and dismount media.

  • View the operations state of media and libraries.

  • Perform library inventories.

  • Set security parameters for users.

Figure 8 illustrates the components of Removable Storage, managed devices, and Windows 2000 Server. Windows 2000 Removable Storage components are shown in white.

Figure 8: Removable Storage components

To ascertain which of the many drives and robotic libraries available are supported for Removable Storage, see the "Microsoft Windows 2000 Hardware Compatibility List (HCL)" entry in the "For More Information" section at the end of this document. Also consult the HCL for the proper configuration settings for all supported drives and robotic libraries.

You can create command scripts using the Removable Storage command-line program Rsm.exe. Use this program to perform routine or automated activities, such as ejecting tapes, creating media pools, and so on.

Removable Storage and Client Applications

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. Removable Storage gives applications access to storage devices through an API that lets applications catalog all removable media (except floppy disks), whether housed online in robotic libraries or offline on shelves. This API and the services it provides hide the details of the various drives and libraries. Because an application does not need to know what specific hardware is being used, media support provided by Removable Storage lets ISVs that create storage applications concentrate on customer features rather than on hardware issues.

Managing media content is handled by Removable Storage client applications (called data-mover applications), such as backup applications. For example, Removable Storage mounts tapes when needed by a backup application, but the backup application itself tracks the backup sets stored on that media.

For information about writing Removable Storage-aware applications, see the section "For More Information."

Removable Storage Database

Removable Storage uses its database to track media-related system components. It stores the properties of managed objects (such as libraries, drives, and media) and updates the database whenever an administrator or an application makes a change in a computer running Removable Storage. This database is used internally by Removable Storage and is not directly accessible to administrators or client applications. Administrators should back up the database on a regular basis.

Using Removable Storage

The Removable Storage snap-in, shown in figure 9, is located beneath the storage node in the Computer Management snap-in. You can also start it directly by running Ntmsmgr.msc. You use it to add Removable Storage objects, view and modify properties of Removable Storage objects, insert and eject media, perform inventories, mount and dismount media, and check status information.

Figure 9: Removable Storage is located under Computer Management

The four Removable Storage nodes shown in the screenshot in figure 9 are described in the following four sub-sections:

  • Physical Locations: Libraries and Offline Media

  • Media Pools: Logical Media Collections

  • Work Queue

  • Operator Requests

Physical Locations: Libraries and Offine Media

Removable Storage manages two classes of physical locations:

  • Libraries. Removable Storage libraries include both media and the means to read and write to them. A CD-ROM drive with a disk inserted is a stand-alone library with one drive, no slots, and no transport (a transport is a robotic device that moves a medium from its slot to a drive and back again). A stand-alone library is one in which the medium must be manually placed in the drive. A more complex example is a robotic-based tape library, which holds several (up to several thousand) tapes, has one or more tape drives, and has a mechanical means to move tapes into and out of the drives (a transport). A robotic library, also called a changer or a jukebox, has either a door or an insert/eject (IE) port. The physical location of media in an online library is the library in which it resides.

  • Offline media. Removable Storage offline media are media that are not in an online library but are physically located elsewhere, such as on a shelf. When a tape or disk is taken out of an online library, Removable Storage records that it now resides in the offline media physical location.

Media Pools: Logical Media Collections

Removable Storage organizes all the media in a library into logical groups called media pools. A media pool is a collection of removable tapes or disks. The tapes or disks in a media pool have the same management properties (that is, administrators define the properties that apply to a set of media). A given media pool can hold only one type of tape or one type of disk. Data management applications use media pools to gain access to specific tapes or disks within libraries managed by Removable Storage.

Media pools control the selection of media and media type, let media be shared across applications (Removable Storage moves media between media pools to provide the amount of data storage an application requires), and track such sharing. Four types of media pool exist—three types of system media pool and one type of application media pool. Removable Storage creates system media pools for its own use. Applications create application media pools to group media, a feature that is especially important when several applications are sharing the libraries attached to a system.

Access permissions associated with each media pool control access to the media that belong to that pool. These permissions control the manipulation of the media; they do not control access to the data on the media.

The functions of each type of media pool are as follows:

  • System: Unrecognized media pools are a temporary holding place for new (blank) but unrecognized media. If Removable Storage does not recognize the media's format, it adds the media to the unrecognized pool. You should move a new medium from an unrecognized media pool to a free media pool so that the medium can be used by applications, or remove it from the library if placed there in error.

  • System: Import media pools are a temporary holding place for media newly added to the system for which Removable Storage can identify the format or associated application. They contain media that Removable Storage recognizes in the database but that have not been used before in a particular Removable Storage system. For example, if you put a tape written by Backup on one system into a library attached to a second system, the instance of Removable Storage on the second system recognizes that the tape was written using Microsoft Tape Format (MTF) and places it in the proper media type import pool.

  • System: Free media pools contain media that are not currently in use by applications and are therefore available to any application.

  • Application: Application media pools are created by administrators or by data management applications. Applications that use media managed by Removable Storage create application pools to hold media for their own use. For example, the Windows 2000 Server Backup utility and its Remote Storage service each creates its own application pool.

Applications move media from the import or unrecognized media pools into either the system free pool or into an application pool.

A media pool can contain media, or it can contain other media pools. Removable Storage uses this hierarchical capability for its system pools. For example, within the free pool is a media pool for each media type. An application can group media of several types into one collection by creating an application media pool for the whole collection and additional media pools within it, one for each media type.

Work Queue

When applications make a library request, Removable Storage places these requests in a queue and processes them as resources become available. For example, a request to mount a tape in a library results in a mount work queue item, which, if necessary, waits until a drive is available to process the request.

Operator Requests

Even with robotic libraries, manual assistance is sometimes required to complete a request or to perform maintenance. For example, if an application requests that a medium in the offline media physical location be mounted, Removable Storage generates a request to the operator to enter the cartridge.


To provide security for itself, media pools, and libraries, the Removable Storage service contains an access control list (ACL) that controls who can connect to the services and who can work with operator requests. In addition, each library and pool has an ACL that governs who can perform specific tasks.

For detailed information about Removable Storage, see "Data Storage and Management" in the section "For More Information."

Disk Quotas

Disk quotas, a new feature for NTFS 5 volumes, provide enhanced control of network-based storage in a distributed environment. Disk quotas give administrators a powerful tool for managing storage growth.

Members of the Administrators Group can see a Quota tab on the Properties dialog box of an NTFS-formatted volume. You can use this tab to set disk quotas to monitor and limit disk space use on NTFS volumes on a per-user basis. You can set disk quotas on both local and remote volumes. Quotas are tracked independently for different volumes, even if the volumes are different partitions on the same physical drive. However, if you have shares on the same volume, the quotas assigned to that volume apply to all of these shares collectively, and users' utilization of the shares cannot exceed the assigned quota on that volume.

Disk quotas apply only to volumes and are independent of folder structures. That is, if a user moves a file from one folder to another on the same volume, volume space usage does not change. But if the user copies the file to a different folder on the same volume, the volume space usage doubles.

Within the NTFS file system, volume usage data is stored by user security ID (SID), not by user account name. Administrators can set two values: a warning threshold and a hard quota.

Using the warning threshold is useful when tracking disk space use on a per-user basis is the goal rather than limiting disk space usage. In this case, once the warning level is reached, you can have the system generate a system log file entry without sending an error message.

Once the hard quota limit is reached, the user cannot move or copy any more data onto the storage device, just as if the user had really run out of disk space. You can configure the system to log an event and return an "insufficient disk space" error when the user has hit his or her quota limit. When this happens, the user cannot write additional data to the volume without first deleting or moving files.

When you enable disk quotas, you can set both the disk quota limit and the disk quota warning level.

When you enable disk quotas for a volume, volume usage is automatically tracked for new users (a new user receives the default quota unless you establish a quota specifically for that user), but existing volume users have no disk quotas applied to them. You apply disk quotas to existing users by adding new quota entries in the Quota Entries window on an NTFS volume.

Besides being able to implement the quota on an individual user basis, you can use group policy to set the disk quota globally. For where to find information about using Windows 2000 group policy settings, see the section "For More Information."

On a computer configured to dual boot Windows NT Server 4.0 and Windows 2000 Server, users can exceed their limit when running Windows NT Server 4.0. However, when the user subsequently runs Windows 2000 Server, he or she must then move files to a different partition or delete files to accommodate the quota limitation.

Windows system files are included in the volume usage of the person who installed Windows on the local computer. If a non-administrator user has installed Windows on his or her machine, an administrator setting a disk quota for that user should take into account the disk space used by the Windows files. This is not a concern if an administrator installed Windows, because administrators cannot be denied disk space use even if they surpass their disk quota limit.

Setting disk quotas can cause a slight reduction in the performance of the file server, so you may choose to periodically enable and then disable quotas. After enabling disk quotas for a period of time, you can contact users who are using more disk space than they should.

The disk quota feature includes other storage features—such as Remote Storage and sparse files—in its calculations. File compression does not affect quota statistics.

The introduction by Windows 2000 Server of Dfs, NTFS directory junctions, and volume mount points means that logical directories do not necessarily belong to the same physical volume. For administrators and application developers, this means that disk space should not be assumed based on space queries made in directories other than the current one.

The Single Instance Store

The Single Instance Store (SIS), a new base operating system component in Windows 2000 Server, helps manage disk space by eliminating duplicate files on a volume. SIS replaces duplicate files with links to a single common store file that contains the actual file data. The SIS service is used by internal Windows 2000 Server components, such as the Remote Installation Services.

SIS consists of a base tracking service, a kernel-mode file system filter driver, reparse points, and sparse files. SIS replaces the duplicate file(s) with a sparse file and an SIS-specific reparse point. The file containing the actual data is renamed with a 128-bit globally unique identifier (GUID) when it is migrated to the common store.

System File Protection

The new Windows 2000 Server feature, System File Protection (SFP), is a system service that protects special operating system files. If one of these files is deleted or over-written, SFP replaces the file with the original from a cache that it maintains.

In earlier Windows operating systems, shared system files were sometimes overwritten when a new application was installed. The most commonly affected files were dynamic link libraries (DLLs) and executable files (EXEs). When this happened, the user experienced problems such as application errors or operating system crashes.

SFP prevents the replacement of monitored system files through a background mechanism that runs inside WINLOGON.EXE. By preventing the replacement of essential system files, file version mismatches are avoided. SFP protects all SYS, DLL, EXE, and OCX files that ship on the Windows 2000 CD-ROM. It also protects the True Type fonts Micros.ttf, Tahoma.ttf, and Tahomabd.ttf as well as bitmap fonts FIXEDSYS.FON, DOSAPP.FON, MODERN.FON, SCRIPT.FON and VGAOEM.FON.

SFP protects system files by detecting when a file replacement is attempted on a protected system file. SFP is triggered when it receives a directory change notification on a file in a protected directory. After this notification is received, SFP determines which file was changed. If the file is protected, SFP looks up the file signature in a catalog (.cat) file (see the next subsection, "Code Signing and Catalog Files") to determine if the new file is the correct Microsoft version. If it is not the correct version, then SFP replaces the newly installed file with either a copy of the protected version stored in the dllcache directory (where SFP-protected versions of system files are kept) or with a copy from the distribution media (if the file is not located in dllcache). SFP then presents the following dialog box to an administrator (on Server products) or to all users (on Professional):

"File replacement was attempted on the protected system file file name. This file has been restored to the correct Microsoft version to maintain system stability. If problems occur with your application, please contact the application vendor for support." <OK>

When <OK> is selected, SFP attempts to locate the installation source (for example, a CD-ROM or network share) by itself. If SFP fails to find the installation source, it prompts the administrator or user for a location to find the installation files. SFP also logs an event to the system event log, noting the file replacement attempt.

Note: You can suppress the above dialog box using the SFCDisable registry setting.

The only installation mechanisms that do not trigger SFP are:

  • Windows 2000 Service Pack installation (Update.exe)

  • Hotfix distributions installed via Hotfix.exe

  • Operating system upgrade (Winnt32.exe)

In addition, you can scan all SFP-protected files to verify their versions by using the command-line utility System File Checker (Sfc.exe). If the dllcache directory becomes corrupted or unusable, you can also use SFP to check and repopulate the %systemroot%\system32\dllcache directory.

Code Signing and Catalog Files

SFP works with another Windows 2000 technology called Code Signing. Together, these two features give greater security to the Windows 2000 operating system by providing a means to verify the source of a system file before it is installed.

Code Signing uses the existing Digital Signature cryptographic technology. A hash of the driver binary and relevant information are stored in a catalog file (.cat file), and the .cat file is signed with a Microsoft digital signature. SFP uses the file signatures and catalog files generated by Code Signing to verify whether a protected system file is the correct Microsoft version. Code Signing is the means of tracking a file's version and creator. SFP is the enforcement mechanism that uses Code Signing signatures and .cat files to keep system files at their correct versions.

Storage Support for Hardware Innovations

Windows 2000 Server supports new storage hardware innovations, including the following:

  • I20 relieves the host of interrupt-intensive I/O tasks, greatly improving I/O performance in high bandwidth applications, such as networked video, groupware, and client/server processing. I20 features include base support, specialized board support for storage cards, and redundant array of inexpensive disk (RAID) cards.

  • Fibre Channel, a 1-gigabit per second data transfer technology, maps common transport protocols such as Small Computer System Interface (SCSI) and Internet Protocol (IP), merging networking and high-speed I/O into a single connectivity technology. An open standard defined by American National Standards Institute (ANSI)16 and Open System Interconnection (OSI)17, Fibre Channel operates over copper and fiber-optic cabling at distances of up to 10 km. Windows 2000 Server implements Fibre Channel storage support by layering it into the SCSI stack.

  • IEEE 1394 is a standard for high-speed peripheral interconnect, which combines simple connectivity with bandwidth for multimedia. IEEE 1394 provides a single connection for audio/visual (A/V) data and control.

Printing Services

A print server can be any computer running Windows 2000 Server (or Windows 2000 Professional) that manages printers, or it can be a specialized print server unit. A printer can be connected to a server, a client computer, or directly to the network. However the printer is connected, it is software on the print server that makes the physical printer visible to the network and that accepts print jobs from client computers.

As with file servers, administrators typically install print servers as member servers rather than domain controllers to avoid the administrative overhead associated with the logon and security roles performed by a domain controller. Often, one server acts as both file and print server.

With Windows 2000 Server, organizations can share printing resources across their entire network. Clients on a variety of platforms can send print jobs to printers attached locally to a Windows 2000 print server, across the Internet/intranet, or to printers connected to the network using internal network interface cards, external network adapters, or another server.

Printing features that Windows 2000 Server carries over from Windows NT include:

  • Printer pools. One logical printer (printing software component on the print server, represented by the print icon) is set up to send a print job to the first available member of this group of identical physical printers.

  • Printer priority. When several logical printers are set up to send print jobs to one physical printer, an administrator can establish which print jobs take precedence.

Printing improvements introduced by Windows 2000 Server include the following:

  • More printers supported

  • Easier installation of local printers (Plug and 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

  • Internet printing

Each of these improvements is described in the following sections.

More Printers Supported

Windows 2000 Server supports more than 3,000 printer models.

Easier Installation of Local Printers (Plug & Play)

The Windows 2000 Server Plug and Play capability—the automatic configuration of a computer to work with various peripheral devices—includes a simpler setup process for printers. A user installing a printer does not need to know about drivers, printer languages, or ports. Most printers in the market today are Plug and Play and can be detected by Windows 2000. However, the way Windows 2000 detects printers and the level of user intervention required varies with the way the printer is connected to the computer. (Windows NT Server 4.0 did not include a Plug and Play capability; users may be familiar with Plug and Play from Windows 98.) Here is a list of printers and the level of user intervention each requires (if any):

  • Universal Serial Bus (USB) and IEE 1394 printers. Printers using the latest connectors technology, including printers with a USB port or an IEEE 1394 Serial Block Protocol (SBP) 2 port, are detected instantly. When the user inserts the jack into the port, Windows 2000 immediately detects the USB port or IEEE 1394 connection and starts the installation process. By design, USB and IEEE 1394 support hot swapping (also called hot plugging), which is the ability to add devices to or remove them from a computer while the computer is running and have the operating system recognize the change.

    Parallel (LPT port) printers. Printers that connect through a parallel (LPT) port are not immediately detected when the physical connection is made. (This is the same as Plug and Play support in Windows 95/98.) After a user connects the parallel cable and turns on the printer it is necessary to restart the system, at which point the Windows 2000 startup process detects the printer and starts the New Found Hardware wizard. Other considerations for parallel printers include the following:

    • Alternatively, it is possible to avoid rebooting by initiating hardware detection from the Add/Remove Hardware wizard. This starts the Plug and Play process and causes Windows 2000 to detect all new hardware, including the printer.

    • The manual installation of parallel, serial, or network attached printers is also supported in the Printers Folder.

    • You can also initiate automatic detection by starting the Add Printer wizard, selecting Local Printer, and selecting the Automatically detect my printer check box.

    • To avoid having to reboot the computer when you connect a parallel printer, use a printer manufactured to include hot swapping technology.

  • Infrared-enabled (IR port) printers. Infrared-enabled printers are also Plug and Play installed, assuming the printer and computer are within one meter of the infrared transceiver in the computer. If the system is not infrared-enabled, you can add the infrared transceiver from the Add Hardware wizard. Once that is done, the IR port automatically appears in the list of printer ports, and Plug and Play installation of printers triggers automatically.

  • Non-Plug and Play printers. Printers connected through a serial port (COM port) and printers connected directly to the network with a Network Interface Card are not Plug and Play and are not detected or installed automatically. You must install these printers using the Add Printers wizard.

More Types of Clients

Clients can access a printer immediately after an administrator adds the printer to a Windows 2000 print server. The types of clients that a Windows 2000-based print server supports include the following:

  • Windows 2000, Windows NT, and Windows 95/98 clients require no additional configuration after the administrator has installed the non-Windows 2000-based drivers on the server. (Alternatively, the appropriate driver can be installed directly on each client.)

  • Windows 3.x, Windows for Workgroups, and MS-DOS clients require 16-bit printer drivers on each client.

  • NetWare clients require Microsoft File and Print Services for NetWare installed on the Windows 2000-based print server and IPX/SPX-compatible transport on the print server and on each client.

  • Macintosh clients require Microsoft Print Services for Macintosh installed on the Windows 2000-based print server and the Appletalk transport on the print server and on each client.

  • UNIX clients require Microsoft Print Services for UNIX installed on the Windows 2000-based print server. UNIX clients that support the line printer remote (LPR) specification connect to a Windows 2000 print server using the Line Printer Daemon (LPD) service.

  • Any client that supports Internet Printing Protocol (IPP) 1.0 can print to a Windows 2000-based print server using HTTP. The clients that support IPP are Windows 9x-based and Windows 2000-based clients. You must first install Internet Information Services (IIS) or Microsoft Peer Web Services (PWS) on the Windows 2000 Server server.

Enhanced Printing Features

Users can now choose advanced printing features on most printers to perform the following tasks:

  • Print multiple pages on one page. This feature saves paper by shrinking several pages and printing them on the same page.

  • Print multiple copies. This capability is supported even for printers that can ordinarily handle only one copy.

  • Print pages in the correct order. Some printers print pages in reverse order. Windows 2000 now automatically corrects this.

Simplified Print Configuration and User Interface

For the administrator, Windows 2000 Server provides improved setup tools for common network configurations (including the new Standard TCP/IP Port for TCP/IP printers connected directly to the network—see next subsection). The new printer interface makes it easier for both administrators and end-users to configure and manage their printing needs. The new interface includes:

  • Common dialog box combining printer properties and document printing.

  • Simplified Add Printer wizard.

  • Simplified device settings.

  • Per user printer preferences.

  • Web views of the Printers folder and of the queues for each printer (browse http://Win2000 ServerName/printers).

Standard TCP/IP Port Monitor

The new standard port monitor connects a Windows 2000-based print server to network interface printers that use the TCP/IP protocol. It replaces the LPRMON protocol for TCP/IP printers connected directly to the network through a network adapter. The new standard port simplifies installation of most TCP/IP printers by automatically detecting the network settings needed to print. In addition, it is 50 percent faster than traditional LPR printing methods. This is because LPRMON uses double spooling, whereas the standard TCP/IP port monitor uses only one spooling. (Printers connected to a UNIX or VAX host might still require LPRMON.)

Remote Port Administration

Windows 2000 Server lets you remotely manage and configure printers (including the new feature remote port administration) from any Windows 2000-based computer. This feature is supported for local, Standard TCP/IP, and LPRMON ports. However, it is not supported for all monitors (for example, HPMon and Appletalk ports are not supported).

Easy-to-Find Network Printers Using Active Directory

In a Windows 2000 Server-based domain, the easiest way to manage, locate, and connect to printers is through Active Directory. By default, when you add a printer using the Add Printer wizard and elect to share the printer, Windows 2000 Server publishes it in the domain as an object in Active Directory. Publishing (listing) printers in Active Directory lets Active Directory clients—computers running Windows NT Server 4.0 or Windows 9x—locate the most convenient printer. When a printer is removed from the server, it is unpublished by the server.

The group policies that control printer defaults with respect to publishing printers are Automatically publish new printers in Active Directory and Allow printers to be published. The Allow printers to be published group policy controls whether or not printers on that machine can be published. (For detailed information about how to use Windows 2000 group policy settings, see the section "For More Information."

Administrators can also publish printers on non-Windows 2000-based print servers in Active Directory. To do so, use the Active Directory Users and Computers tool to enter the universal naming convention (UNC) path of the printer. Alternatively, use the Pubprn.vbs script provided in the System32 folder. The group policy Prune printers that are not automatically republished determines how the pruning service (automatic removal of printers) handles printers on non-Windows 2000-based print servers when a printer is not available.

Users can search for a printer that has been published in Active Directory by feature (such as color printer), by physical location (such as the third floor in Building A), or by a combination (all color printers in Building A). A list of printers matching the given criteria is presented. Users can select a listed printer and right-click to view its properties, open the print queue, or create a connection to use that printer. Users can save search results for future use. Administrators can create custom searches for different groups of users, and then save the result files wherever they wish—for example, on users' desktops.

Windows 2000 introduces print queue monitoring. The System Monitor feature's new Print Queue object lets administrators monitor the performance of a local or remote printer. Counters can be set up for a variety of performance criteria, such as bytes printed per second, job errors, or total pages printed.

User Permissions and Group Policies

After you add a printer and share it over the network, you must verify that users have the appropriate permissions. Printer permissions control not only who can print, but also which printing tasks a user can perform. The three levels of printer permissions are:

  • Print. By default, all users have the Print permission as members of the Everyone group and can therefore print documents, pause, resume, start, and cancel their own documents, and can connect to a printer.

  • Manage Documents. This permission adds the ability to control job settings for all documents as well as pause, restart, and delete all documents.

  • Manage Printer. This permission adds a printer, changes printer properties, deletes printers, and changes printer permissions.

You can set a group policy to change the default behavior of the printing environment and to provide computers and users a standard set of preferences. For example, you can restrict some groups of users from adding or deleting printers or prevent a group from using Internet printing.

User Settings

The ability to change personal document defaults (already available for Windows 95/98 users) has now been extended to Windows 2000 Server and Windows 2000 Professional clients. In Windows NT Server 4.0 and earlier, only an administrator could modify global document settings.

Enhanced Print Server Clustering

Clustering provides transparent failover of the print server to offer the highest level of availability. For example, if you take down one print server for maintenance, users' print jobs are sent to the surviving node (print server) in the cluster. Clustering is not currently supported by Windows 2000 Server, but it is available with Windows 2000 Advanced Server. Windows 2000 Advanced Server uses new port monitors that automatically copy the ports and settings to both nodes.

Enhanced Printer Drivers

A printer driver is a software program used by computer programs to communicate with printers and plotters. Printer drivers translate the information a user sends from the computer into commands that the printer understands. Various drivers must be installed on the print server to support different hardware and operating systems. For example, an administrator running Windows 2000 Server who shares a printer with clients running Windows 3.1 might want to install the appropriate drivers so the users won't be prompted to install the missing drivers.

Windows 2000 Server supports the UniDriver 5.0 printer driver and the PostScript 5.0 printer driver, described in the following two subsections.

UniDriver 5.0 Printer Driver

UniDriver 5.0, a 32-bit Windows 2000 printer driver, includes the following features:

  • Supports all non-Postscript printers.

  • Provides improved color printing using Microsoft Windows-based Image Color Matching (ICM) 2.0.

  • Provides much improved output quality, such as correct handling of layered text, graphics, and bitmaps.

  • Supports original equipment manufacturer (OEM) customization, which lets application developers exploit printing device features without doing custom development.

  • Optimizes faster processing performance.

  • Supports text-based Generic Printer Description (GPD) file format for minidrivers. GPD format is considerably more extensible and flexible than its predecessor, Generic Printer Characterization (GPC) binary format.

  • Prevents mistakenly choosing incompatible printer features. For example, if the envelope feeder is selected, letter size cannot be selected.

  • Supports Far East device fonts.

  • Supports device font substitution for faster printing.

PostScript 5.0 Printer Driver

PostScript 5.0 printer driver includes the following features:

  • Provides structured PostScript generation.

  • Provides improved color printing using Microsoft Windows-based Image Color Matching (ICM) 2.0.

  • Offers page-independent, Document Structuring Conventions (DSC)-compliant output option. DSC is an Adobe standard that lets Postscript applications communicate the document structure and printing requirements to print spoolers, drivers, or other resource servers.

  • Supports Postscript Level 3 devices.

  • Provides various font formats: Type 1, Type 3, Type 32, Type 42, CID, Open Type fonts.

  • Supports OEM customizability of user interface and code generation.

  • Supports improved driver/application interaction with PostScript applications.

  • Provides virtual memory (VM) tracking on Postscript Level 2 and greater devices. VM tracking tracks the memory available at the Postscript language level.

Better Color Output Quality

Image Color Management (ICM) 2.0 technology, in conjunction with better halftone and image processing technologies, lets users reproduce documents on a printer faster, easier, and with greater color accuracy and consistency.

ICM 2.0 features include the following:

  • Better color mappings between devices with various mapping conditions, such as paper type, inks, or resolutions. Windows 2000 Server features the automatic installation of the printer-specific color profile at the time the printer is installed. This color profile is compliant with International Color Consortium (ICC) color standards, and it is this new feature, not available in Windows NT Server 4.0, that ensures better color mappings.

  • Standard color space for images exchanged between applications and the operating system.

Better Halftone and Image Processing Technologies

Windows 2000 printing offers the following improved halftone and image processing features:

  • Generates better color gradient, and provides more detail, smoother color rendering, and higher image quality using new SuperCell Halftone.

  • Provides better halftones and solid brushes for colored text and fill.

  • Provides OEM-customizable halftone dither matrices.

  • Supports multiple-level color printers that produce photo quality output; these are printers that provide six or more colors by producing various shades from Cyan, Magenta, Yellow, and Black inks.

  • Supports output devices (printers) with 256 grayscale levels.

  • Detects and applies anti-aliasing to smooth jagged edges automatically when printing enlarged digital images, and preserves image content when image size is reduced during printing.

  • Provides generally faster processing and output speed in both color and monochrome printers.

Internet Printing

The Windows 2000 Server printing architecture is now seamlessly integrated with the Internet:

  • URL format for printer name. When installing a printer from the Internet, the printer's Uniform Resource Locator (URL) is the name of the printer. Administrators can also choose to use the URL format within an intranet. For a Windows 2000 Server-based server to process print jobs that contain URLs, it must be running IIS. (For print servers implemented on Windows 2000 Professional, Microsoft Peer Web Services (PWS) must be running.)

    IIS (or PWS) print server security. Print server security is provided by IIS (or PWS). To support all browsers and all Internet clients, you must choose basic authentication. Basic authentication (also called clear-text authentication) encodes the user name and password data transmissions, but can be decoded by anyone with a freely available decoding utility. Alternatively, for more restricted security, you can specify one of the following:

    • Microsoft challenge/response authentication, which encrypts communication between a host (server) and client and is supported by Internet Explorer.

    • Kerberos authentication, which is the basis of Windows-based security for both internal and intranet logon and is also supported by Internet Explorer.

    • Digest authentication, which sends the user name and password information over the network as a hash value. A hash message authentication code is an IP security function that verifies that the information received is identical to the information that was sent.

    • Secure Sockets Layer (SSL) 3 authentication, which was developed by Netscape for transmitting private documents over the Internet.

  • Web point-and-print. Users on Windows 2000 or Windows 95/98 client computers can connect to printers on the network using Web point-and-print for single-click installation of a printer shared by a Windows 2000 Server-based server.

  • Use a URL to print. Users can print over the Internet or an intranet from a Windows 2000 Server or Professional (or Windows 95/98 with at least Internet Explorer 4) client to a Windows 2000 print server using a URL. For example, a mail-order company can send its new catalog directly to the publisher's printer, provided they have permission from the publisher and the URL of the publisher's printer.

  • View or connect to printer from browser. Administrators or users can view and manage printers from any browser. They can pause, resume, or delete a print job and can view the printer and print job's status from any browser. In addition, if they use Internet Explorer (IE) version 4.0 or higher, they can connect to a printer using a browser.

Existing NT File & Print Servers

If you have existing file and print servers in a Windows NT network, you can upgrade only those servers to Windows 2000 Server, or you can upgrade the entire network.

Windows 2000 Server is the most significant release of the Windows-based platform since the advent of Windows 3.0 in 1990. Businesses can take advantage of new Windows 2000 Server file and print features even before converting their existing network to this new platform. Those that do plan to take immediate advantage of the significant architectural improvements provided by a complete Windows 2000 Server implementation need to protect existing investments in hardware, software, and organizational logistics. Therefore, Microsoft designed Windows 2000 Server to support incremental deployments as well as complete conversion to the new operating system.

Incremental Deployment

The interoperability features of Windows 2000 Server lets member servers coexist in today's Windows NT 3.51 and Windows NT 4.0 server environments, providing customers with the flexibility to do the following:

  • Perform server upgrades in incremental stages.

  • Implement specific Windows 2000-based services and stabilize them.

  • Upgrade to Windows 2000 Server at their own pace.

For customers who are already running Windows NT Server 3.51 or 4.0, a good starting point is to upgrade existing Windows NT file and print member servers (as well as Web servers). File servers can experience a considerable increase in file access, and print servers can gain significant performance improvement. In addition to improved performance, upgrading an older file or print server also improves manageability immediately for organizations not yet ready to implement an infrastructure-wide deployment of Active Directory.

Once file and print member servers have been upgraded to Windows 2000 Server and the new NTFS 5 file system, an organization can take immediate advantage of several enhanced file and print services even while continuing to run these machines in a Windows NT 3.51 or 4.0 domain. The Windows 2000 setup process automatically upgrades NTFS 4 volumes on Windows NT machines to NTFS 5; installers can choose to upgrade FAT16 or FAT32 volumes.

Key new features offered by the new Windows 2000 Server-based member servers running in the existing Windows NT environment include:

  • File services in a Windows NT environment. Disk quota management, content indexing, and distributed link tracking (each described earlier in this paper) become operational.

  • Print services in a Windows NT environment. Internet Printing Protocol (IPP) is available.

Deployment of Windows 2000 Server Network

When an organization upgrades its entire network to a Windows 2000 Server network, the biggest change is the deployment of Active Directory. The Active Directory provides a way for users, applications, and other clients in a distributed environment to name, store, and retrieve information. Once the Windows 2000 Server Active Directory and the Distributed File System are in place, the following additional features become available on file and print servers:

  • File services in a Windows 2000 environment. When used in conjunction with Dfs, users can now publish a share as a Volume Object in Active Directory. This means they can now easily and quickly query Active Directory for available resources and shares.

  • Print services in a Windows 2000 environment. Windows 2000 Server provides a standard printer object for Active Directory. Using this object, administrators can publish printers to be shared across the network in Active Directory. This means that users can now easily query Active Directory for any of these printers, searching on printer attributes such as type (PostScript, color, legal-sized paper, and so on) and location.


Fast file and printer sharing are network services that virtually all users require on an internal network. The Windows 2000 Server operating system has updated many features of traditional file and print services and has added new ones. Information search and retrieval capabilities have also been expanded. In addition, Windows 2000 Server includes a new dynamic disk architecture and significant new and improved storage-related capabilities. Organizations can take advantage of several new features if they use Windows 2000 file and print servers in a Windows NT-based or other legacy network, and they acquire additional new features when they upgrade to a Windows 2000 Server-based network.

All of these changes have been made with both network administrators and application developers in mind. Network administration is 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.

For More Information

For the latest information on Windows 2000, check out our World Wide Web site at, the Windows NT Server Forum on MSN™, and The Microsoft Network online service (GO WORD: MSNTS).

In addition, you can look at the following sources for more information:


For information about . . .

Where Available

Windows 2000 Information

"Active Directory Architecture"

Active Directory, including what this new directory service is and how it is structured.

"Group Policy"

Detailed information about the Windows 2000 Group Policy feature.

File System Information

"Encrypting File System for Windows 2000"


Installable File System (IFS) Kit

For sample kernel-mode file system and file system filter drivers.

NTFS File System

NTFS file system information for developers.

"File Systems" chapter in Windows 2000 Resource Kit

NTFS, FAT16, FAT32, file and folder compression, NTFS recoverability, reparse points, and file system tools.

Currently scheduled to be published by Microsoft Press in the first half of the year 2000. Also located on the Windows 2000 Server and Advanced Server CDs as part of Support Tools.

Storage Information

"Enterprise Class Storage"

In-depth discussion of storage issues.

"Data Storage and Management" chapter in Windows 2000 Resource Kit

Data management, removable storage, remote storage, disk management, disk quotas.

Currently scheduled to be published by Microsoft Press in the first half of the year 2000. Also located on the Windows 2000 Server and Advanced Server CDs as part of Support Tools.

Microsoft Windows 2000 Hardware Compatibility List (HCL)

Lists which drives and robotic libraries are supported for Windows 2000 Removable Storage

You can find the Hardware Compatibility List (Hcl.txt) on the root directory of the Windows 2000 compact disk, or online at

Microsoft Platform Software Development Kit (SDK)

How to write Removable Storage-aware applications.

Windows NT Mixed-Mode and Migration Information

"Planning Migration from Windows NT to Windows 2000"

Upgrading from Windows NT to Windows 2000

"Upgrading and Deploying File, Print, and Web Services"

Upgrading file, print, and Web services from Windows NT to Windows 2000 Server


1 Windows 2000 introduces the Microsoft Management Console (MMC), which is a framework for hosting administrative tools called snap-ins. The main MMC window provides commands and tools for authoring consoles.

2 In Windows NT version 4.0 and earlier, the Macfile program handled Macintosh file administration, including the creation of Macintosh volumes, passwords, security options, user limits, and permissions. You accessed the Macfile menu from Control Panel, File Manager, and Server Manager.

3 Note that site topology refers to Active Directory replication topology both within a site (within a LAN) and between sites (within a WAN). Although Dfs makes use of site topology set up for Active Directory replication, Active Directory replication itself is unrelated to Dfs replication. Active Directory replication replicates network objects, whereas Dfs replication replicates Dfs shared folders and files. For more about Active Directory replication, see the "For More Information" section at the end of this paper.

4 For a stand-alone Dfs root, the one and only copy of the PKT is stored on the server itself.

5 Domain controllers (which, by definition, have Active Directory installed) use multimaster replication (separate from the multimaster replication used by FRS, described below) to replicate and synchronize Active Directory objects--including the PKT (which stores Dfs topology information)--among peer domain controllers, each of which has a read-and-write copy of the directory. This is a change from Windows NT Server 4.0, in which only the Primary Domain Controller (PDC) had a read-and-write copy of the directory (the Backup Domain Controllers, or BDCs, received read-only copies from the PDC). For more about Active Directory replication, see the white paper Active Directory in the section "For More Information" at the end of this paper.

6 Active Directory replication is a multimaster object-based replication service.

7 Client improvements in Windows 2000 Dfs depend on the host platform.

8 You can encrypt or decrypt files and folders located on a remote computer that has been enabled for remote encryption. However, if you open the encrypted file over the network, the data that is transmitted over the network by this process is not encrypted. Other protocols, such as Secure Sockets Layer/ Private Communications Technology (SSL/PCT) or Internet Protocol Security (IPSEC) must be used to encrypt data over the wire.

9 COM lets programmers develop objects that can be accessed by any COM-compliant application.

10 The NTFS Journal is also referred to as the Reliable Change Journal or Change Log (not to be confused with the NTFS recovery log, which is a log of disk activities that helps you restore information quickly in the event of power failure or other system problems).

11 OEM (also called value-added reseller) stands for original equipment manufacturer. OEMs buy computers in bulk and customize them for a particular application. They then sell the customized computer under their own name. The term can be confusing because OEMs are not the original manufacturers—they are the customizers.

12 ISO, though not an acronym, stands for the International Organization for Standardization, an international organization that defines standards for designing networks.

13 OSTA is an international trade association that promotes the use of writeable optical technology for storing computer data and images.

14 DVD is a new type of CD-ROM that supports disks with capacities from 4.7 GB to 17 GB. DVD drives are backward compatible with CD-ROMs; that is, they can play old CD-ROMs, CD-I disks, and video CDs as well as the new DVD-ROMs.

15 Windows 2000 Server offers Remote Storage; Windows 2000 Professional does not. Remote Storage does not support clustering.

16 Founded in 1918, ANSI is a voluntary organization composed of over 1,300 members (including all the large computer companies) that creates standards for the computer industry.

17 OSI is an ISO standard for worldwide communications that defines a networking framework for implementing protocols in seven layers.