File and Printer Sharing

Overview

One of the key functions provided in the Microsoft Windows Server 2003 family is the ability to share files and printers. The Windows Server 2003 family provides both the Common Internet File System (CIFS), based on the Server Message Block (SMB) file and printer sharing protocol, and the Internet Printing Protocol (IPP), which allows clients to install printer drivers over their intranet or the Internet, as well as to send print jobs using IPP encapsulated in Hypertext Transfer Protocol version 1.1 (HTTP/1.1).

CIFS is an operating-system-independent protocol that evolved from the SMB and NetBIOS file- and printer-sharing mechanisms of earlier versions of Windows. The SMB protocol was created in the 1980s by IBM and later enhanced and extended by IBM, 3Com, Intel, and Microsoft. SMB is now also known by the name CIFS.

CIFS allows clients to access files and printers over their corporate LAN as well as over the Internet. Microsoft and several other vendors are jointly developing CIFS specifications, and a specification draft was submitted to the Internet Engineering Task Force (IETF) in expectation that it might be adopted as an informational RFC (this Internet draft has now expired). Copies of the early drafts of this material are contained in the Cifs folder on the companion CD-ROM.

One problem with CIFS is that there is no up-to-date formally published specification. The draft RFC documents contained in the folder were written in 1997 and have not been significantly updated since. They are largely accurate, although they are not completeand appear inaccurate in some areas. There is an active CIFS mailing list; see http://discuss.microsoft.com/archives/cifs.html for the list's archive and for instructions on how to join the list.

IPP is a method of performing printing operations across a network based on usingHTTP/1.1. With Windows Server 2003, IPP also requires the IPP server to be running Microsoft Internet Information Services (IIS) 6, which is not installed by default.

Introduction to CIFS

CIFS is a cross-platform mechanism allowing clients to request file and print services from a network server based on the widely used SMB protocol.

The SMB protocol was invented by Dr. Barry Feigenbaum of IBM's Boca Raton lab during the early Microsoft Disk Operating System (MS-DOS) days. It was extended by 3Com, IBM, Intel, and Microsoft during the mid- to late 1980s. During late 1996, Microsoftrelaunched the Microsoft Windows NT 4.0 extensions of the SMB protocol as CIFS andreleased a draft RFC. Some of the enhancements that were most visible were the addition of Andrew File System/Distributed File System (AFS/DFS), or Transarc, style referrals and the use of port 445 (to avoid reliance on the RFC 1001 NetBIOS service). To ensure compatibility between older and newer systems, the client and server negotiate which variant of the SMB protocol to use, the highest version that both client and server support.

The version of CIFS included with Windows Server 2003 remains backward-compatible with previous versions of Windows. CIFS is an open protocol, which means that all aspects of communication are publicly documented, although the documentation that is publicly available is incorrect and lacking in places.

The chief advantage that CIFS provides over file access protocols such as HTTP and File Transfer Protocol (FTP) is that it allows simultaneous read and write access to a file, as opposed to the simple file transfer capabilities provided by HTTP and FTP. CIFS supports distributed, replicated virtual volumes such as Distributed File System (Dfs), file and record locking, file change notification, read-ahead and write-behind operations, and most of the functionality typically associated only with direct connections to a corporate network. CIFS functions over any IP-based network, including the Internet.

The SMB protocol was originally based on NetBIOS as a transport protocol, running on top of TCP/IP, IPX/SPX, or NetBEUI. Using TCP/IP, a CIFS client wanting access to a file or print server would first create a TCP connection to the server (assuming that both client and server shared a compatible transport connection). Next, the client would establish a NetBIOS session over the previous transport session. The client would finally use the NetBIOS session to create and then utilize a file and print sharing session with the server. When TCP/IP is used as the transport protocol for the NetBIOS session, the client initiates the NetBIOS session over TCP, using server port 139.

With Windows Server, the file server can directly host the file and print sharing and does not require NetBIOS. A client opening a direct host connection sets up a TCP session using TCP port 445.

File and print sharing sessions can also be established and used with NetBIOS running over IPX/SPX and NetBEUI. However, details of such sessions are outside the scope of this book, which concentrates only on the use of TCP/IP.

CIFS Operation

The steps involved in CIFS file sharing can be summarized as follows:

1. The client determines the IP address of the server and makes a connection to either TCP port 445 or TCP port 139 (if NetBIOS is being used) on the server.
2. If the client is using NetBIOS, then a NetBIOS session is set up over the existing TCP connection.
3. The client then negotiates the SMB dialect to use. The server chooses the most functional dialect that both client and server understand and returns a list of capabilities to the client.
4. The client then requests a session with the server, providing some securityinformation. The exchanges relating to security will be dependent on thespecific security mechanisms in use. If the session can be created, the server responds with the User ID (UID).
5. The client attaches to a share using the UID. The server responds with the Tree ID (TID) relating to that share.
6. The client opens a file using the TID and UID. The server responds with a File ID (FID) to identify the open file.
7. The client then uses the UID, TID, and FID to perform file operations onthe file.
8. When complete, the client closes the file, closes the session, and finally closes the TCP connection, which terminates the file sharing session. If the connection has been made using NetBIOS, closing the underlying TCP connection also closes the NetBIOS session.

These steps are shown in Figure 19-1 and discussed in more detail in the following pages.

Figure 19-1: CIFS file sharing.

Name Resolution and Connection Establishment

The CIFS server registers its name with a name resolution service, using either a fully qualified domain name and the Domain Name System (DNS) or a NetBIOS name and Windows Internet Naming Service (WINS). A client wishing to connect to the CIFS server can query a DNS or WINS server to obtain the IP address of the CIFS server. Capture 19-01, included in the Captures folder on the companion CD-ROM, demonstrates the CIFS protocol. This is a trace of a client, Kapoho11, accessing a file on a share contained on the server Kapoho10.

The first step made by the client is to resolve the name to the IP address of the CIFS server. The client establishes a connection to the CIFS server using TCP port 445 (assuming direct hosting is used). If a NetBIOS-based connection is being used, the client next sets up a NetBIOS session. In the trace, NetBIOS hosting is used.

Once the basic connection is established, the CIFS client negotiates which variant of the SMB protocol is to be used. Clients and servers can understand multiple variants of the SMB protocol and need to negotiate which specific variant to use for this connection.The client performs this by issuing an SMB SESSION REQUEST message over TCP port 139 (the NetBIOS session service) or over TCP port 445 (direct hosting).

The client begins the session negotiation by sending a NEGOTIATE packet to the server. This packet contains a list of the dialects the client is able to use. Table 19-1 lists the full set of SMB dialects, with those understood by Windows Server 2003 noted.

Windows Server 2003 clients and servers attempt to negotiate NT LM 0.12, which allows the server to issue parameters that specify things such as encryption key lengths, maximum message sizes, and whether the server is Dfs aware.

The server responds to the client with a NEGOTIATE packet identifying the highest dialect that both machines understand, as well as parameters specific to that dialect. Table 19-2 describes the components of a CIFS server NEGOTIATE response.

By returning a list of its capabilities, the server informs the client which operations might or might not be performed at the client's request. Table 19-3 lists the bit definitions of the server's capabilities.

Once the CIFS client receives a NEGOTIATE PROTOCOL response, it completes the session negotiation by issuing a SESSION SETUP ANDX SMB to the server. Table 19-4 describes the components of a SESSION SETUP ANDX SMB.

The CIFS server then responds with a SESSION SETUP ANDX response message. This message contains a UID to the client session. Additional sessions can be set up over the same connection without prompting the user for a password. CIFS can use any authentication supported by client and server, including Windows 2000 or Windows Server 2003 Kerberos authentication mechanisms.

The connection between client and server in an SMB session is called a virtual circuit (VC), which is formed over the transport service, typically TCP. Within a VC, the server assigns a TID that provides a unique identifier for each file sharing session and defines the types of access allowed over that connection. A process ID (PID) identifies the process environment for that session, and an FID is assigned to each file opened during the session. If a VC is closed, all environments within the VC (TID, PID, FID) are also closed. However, the closing of a single FID might not result in the closing of the VC, as multiple operations can be requested over a single VC.

Session Operations

Once a session has been established, a client can request four basic sets of operations against the file server:

• File management requestsThe client can request the server to create (or open), read from, write to, and lock and close a file or create a temporary file. The client can delete, rename, move, or copy a file. In addition, clients can query and set both file and path information.
• Directory management requestsClients can create, delete, and searchdirectory entries.
• Dfs operationsClients can request a Dfs referral from a Dfs server to atarget server.
• Miscellaneous operationsClients can request device and file system control functions to be transferred transparently to the server, as well as query and set the security descriptor on a file or directory.

Session Disconnection

When a client wishes to disconnect its session to a CIFS server, it follows a teardown process that is essentially the reverse of the session-establishment process. Any open files are closed and their associated FIDs and PIDs then can be disconnected. The TID is disconnected and the user logs off, which results in the server discarding that client's UID. If the client should reconnect, the user is again prompted for credentials because the UID assigned during the last session no longer exists.

Connection Management

CIFS provides mechanisms that allow for efficient disconnections when a client and server have completed all session traffic or when a connection is lost or malfunctioning. A client can issue a connection request only once to a CIFS server in any given session. If the CIFS server receives another connection request from a client with whom it already has an established session, the server disconnects the original session with the client to help ensure that a client that was unexpectedly disconnected from its session can effectively establish another session with the server. If a client is generating malformed or illegal requests to the CIFS server, the server can issue an error to the client and then disconnect the session, again potentially allowing the client to correct the problem and reconnect. A server can also disconnect a session with a client in the case of hard transport errors or if the client has been inactive for a long period of time and the server needs the connection.

File and Printer Access

After a client has established an SMB session with a CIFS server, the client can begin requesting files by issuing open SMBs to the server for the files it wishes to access. A file can be opened for read access, write access, or both. Accessing a printer is accomplished using a read request to the printer. Printing is accomplished using a write request to the printer.

Distributed File System Operations

Any client and CIFS server that supports dialects NT LM 0.12 and later supports Dfs operations. Using Dfs, the CIFS server can represent multiple shares on multiple servers in a single namespace that appears to the client to be located on a single server. The CIFS server can redirect the client software to another location on the network to access a resource, but the client will believe the resource is local to the server with which it originally negotiated a connection.

When a client wants to access a file that is contained in a Dfs share, it will issue a normal set of SMBs, because the client is not initially aware that part of a file path represents a Dfs share. The client sets a flag in the request SMB header indicating that the client wants the server to resolve this SMB's paths within the Dfs known to the server. The server then attempts to resolve the requested name to a file contained within the local directory tree indicated by the TID of the request. If this succeeds, then processing proceeds normally. If, however, the request path name resolves to a file on a different system, the server returns the error STATUS_DFS_PATH_NOT_COVERED. This indicates that the server does not support the part of the Dfs namespace needed to resolve the path name in the request. The client should request a referral from this server for further information.

The client can then ask for a referral using the TRANS2_DFS_GET_REFERRAL request containing the Dfs path name of interest. The response from the server indicates the server and share that the Dfs client should now attempt to access.

Read-Ahead and Write-Behind

To improve performance, CIFS supports read-ahead and write-behind operations. Read-ahead allows a client to cache read data locally so that it does not have to incur traffic over its connection to the server to obtain the next block of data it wants to read. Write-behind allows a client to perform and cache write operations on a file that then can be uploaded to the server, rather than having to submit each read/write operation separately.

Files on the server can also be called locked or unlocked. An unlocked file is a file to which no client has been granted exclusive access for either read or write purposes. CIFS supports caching, read-ahead, and write-behind, even for unlocked files, because the files are said to be "safe" as long as no client is actively writing to the file. If a client wants to write to a file, it must either submit the write data to the server for the server to write, or it can request a lock from the server.

Opportunistic Locks

When a client is actively writing to a file on the server, it can be more efficient for the client to locally buffer its data and submit it as a batched request. However, this increases the possibility that the same file might be opened by another client and data might also be written by that client. To help a client increase the efficiency of its data buffering, CIFS allows for opportunistic locks (referred to as oplocks), which allow the client to "lock" the file, or part of a file, so that it can't be written to simultaneously by another client. The following are three types of oplocks used in CIFS:

• Exclusive oplocksIn an exclusive oplock, a client (Client A) requests exclusive access to a file, where Client A is the only client permitted to write data to the file. When Client A opens the file, it requests an exclusive oplock from the server. If another client (Client B) has already opened the file, the server refuses to issue the oplock to the requesting client (Client A). When this occurs, Client A is does not buffer any data and does not perform any read-ahead. If there are no other clients currently accessing the file, the exclusive oplock will be granted to Client A and it can both read-ahead and buffer data that is to be written to the file. If Client C opens the file while Client A has an exclusive oplock, the server instructs Client A to break its lock. Breaking the lock requires Client A to submit any buffered lock or write data it's currently holding, acknowledge receipt of the notification, and purge its read-ahead buffer so that the file can be released for access by Client C.
• Level II oplocksLevel II oplocks allow multiple clients to open the same file, provided that no client is writing to that file. In a level II oplock, Client A can open a file and request an exclusive oplock to it. If it is the only clientaccessing the file, the server grants the oplock. When Client B requests access to the same file, the server contacts Client A and requests that it break its lock to a level II oplock if Client A hasn't been writing to the file. This is a result of the fact that some down-level client applications request read/write access to files even when they don't intend to perform write operations. After the server has synchronized with Client A to ensure that Client A has no locked buffer data, access to the file is granted to Client B at a level II oplock status. Thisinforms Client B that it can't buffer any locks to the file, although it has been granted access. Either client can eventually write to the file; should this occur, the server notifies all level II oplock clients to break their locks, thus allowing the data to be written by a single client and ensuring that the server does not have to synchronize with all connected clients to allow this.
• Batch oplocksBatch oplocks are commonly used by applications that run command batches requiring them to repeatedly open and close multiple files to read and execute their command sequences. When Client A wants to obtain a batch oplock to server files, it requests the oplock from the server. If other clients do not have the files open, the batch oplock is granted. Client A can now open the files, leave them open while executing its command sequences, and buffer data as needed. If Client B requests access to one of the files while Client A has a batch oplock, the server notifies Client A to clean up its data and synchronize with the server. In most cases, this results in Client A finishing its current batch operation and closing the file in question, allowing Client B to open the file.

Introduction to Internet Printing

Internet printing in the Windows Server 2003 family allows you to install, use, and monitor a printer over an internet. This can, but probably will not include the Internet and might include using a corporate intranet. Using IPP, you can install a printer using a Web browser or the Add Printer Wizard, but you can specify a Uniform Resource Locator (URL) or IP address instead of a Universal Naming Convention (UNC) path to the printer. When submitting a print request, the user can then use the installed printer interface to print directly to the URL. The print server must, however, be running IIS to accept these print requests. Because the print server uses the HTTP functionality of IIS, it can return information regarding the print job in browser-ready format. The underlying protocol that allows Internet printing to function is the IPP, which is sent encapsulated in an HTTP/1.1 request to the print server. The implementation of IPP in the Windows Server 2003 family is unchanged, functionally, from IPP in Windows 2000.

IPP Operation

IPP is defined in the following RFCs:

• RFC 2567, Design Goals for an Internet Printing ProtocolThis RFC looks at the features that would be needed in a printing protocol for the Internet.
• RFC 2568, Rationale for the Structure of the Model and Protocol for the Internet Printing ProtocolThis RFC provides a high-level overview to the functions and features of IPP.
• RFC 2911, Internet Printing Protocol/1.1: Model and SemanticsThis RFC describes IPP from a high-level viewpoint.
• RFC 2910, Internet Printing Protocol/1.1: Encoding and TransportThis RFC formally maps IPP onto HTTP/1.1 and defines the encoding rules for a new Internet Multipurpose Internet Mail Extensions (MIME) media type called application/ipp.
• RFC 2569, Mapping between LPD and IPPThis RFC gives some adviceto implementers of gateways between IPP and line printer daemon (LPD) implementations.

IPP presents a very simplified model of printing that can be implemented on top of a variety of architectures. IPP defines two principal objects as the basis for Internet printing: a printer and a job. The printer object is the server-side component of the IPP protocol. In the Windows Server 2003 family, the IPP printer can be any printer that is installed on a computer running IIS. IPP also requires an underlying directory that can be used to store and retrieve definitions of IPP printers. However, the printer object shouldn't be confused with the output device. The output device is the physical device, which can be a simple printer, fax printer, or software, such as desktop publishing programs, document archive software, or a CD writer. The physical output device does not need to be IPP-aware or IPP-compliant as long as the printer object (the IPP server) handles the IPP.

With the Windows Server 2003 family, a user can query the Active Directory service to locate a printer object based on a printer's attributes, such as its location or capabilities. When a user sends a document for printing using IPP, the client computer submits the document as a print job, which contains a listing of the document's print attributes. The print submission is sent to the printer object, which validates the submission's attributes and creates a new job object. The newly created job object can then be queried. This facilitates reporting on print status and errors.

An IPP client is a computer running an HTTP/1.1-compatible browser, such as Microsoft Internet Explorer, and an installed printer software interface representing the print object. The user at the client computer installs the printer by entering its URL or IP address in either a Web browser or the Add Printer Wizard. After the printer has been added on the client computer, the user can submit print jobs from any application as if the printer were a network printer. When you try to print from a Windows Server 2003 client, theclient attempts to use normal SMB print sharing before using IPP.

When you are printing, the client IPP software processes the print job in the appropriate format for the printer object. The IPP client then submits the job as an encapsulated HTTP/1.1 request to the printer object, which might be a print server or the actual output device. RFC 2566 specifies three different scenarios for setup of the printer objects and output devices. Figures 19-2, 19-3, and 19-4 diagram each of these scenarios.

Hosted Printing

In hosted printing, the IPP client sends a print job to the printer object, which is represented in Active Directory. The client locates the printer object by querying Active Directory for printers that are capable of specific functionality. However, queries for dynamic information, such as job status and queue length, are submitted to the printer object itself. The printer object in this scenario, as shown in Figure 19-2, is a print server running the IPP service (IIS, for example). The output device is a physical print device or software application that can be installed directly on the print server network. The output device does not need to support any IPP functionality, because the printer object, in this case the IIS server, performs all processing related to IPP and sends the job to the output device as it would any locally submitted print job. The printer object is also responsible for providing status monitoring and notification functionality to the requesting client using HTTP/1.1, which is why the server must be running IIS to serve as an IPP printer object.

Figure 19-2: IPP hosted printing.

Fan Out Printing

Fan out printing is very similar to hosted printing, except that the print object can transparently direct the print job to any of a number of physical output devices (as shown in Figure 19-3). These devices can be physical print devices, fax printers, or software on the local computer or another computer on the network. As with hosted printing, the output device does not need to use IPP, because the IPP server or printer object handles that functionality. Client queries relating to job status are submitted to the printer object, not to the output devices.

Figure 19-3: IPP fan out printing.

Embedded Printing

In embedded printing, the printer object and the output device are the same entity, and might or might not be represented in Active Directory. Unlike hosted and fan out printing, there is no intermediary server acting as the print object and print server for the output device (as shown in Figure 19-4). Embedded printing requires that the output device be capable of receiving and processing IPP client requests, as well as returning information to the client over HTTP. Therefore, this implementation requires additional functionality on the part of the output device, which is already provided by some printer vendors.

Figure 19-4: IPP embedded printing.

IPP Specifications

IPP structure and semantics are defined in a series of RFCs, as noted earlier in this chapter. The IPP specifications define two layers to the protocol: transport and operation. The transport layer of the protocol consists of HTTP/1.1 requests and responses, defined in Chapter 21, "Internet Information Services (IIS) and the Internet Protocols." The operation layer is a message body embedded in the HTTP/1.1 requests and responses. Each request or response message contains a sequence of attributes that describe the capabilities and characteristics of the objects involved in the printing operation. These object attributes are as follows:

• Printer attributesPrinter object attributes fall into two categories: printer description attributes and printer job template attributes. Printer descriptionattributes are those that define properties, such as the printer object's location and state. Printer job template attributes describe the printer object's capabilities, such as the types of jobs it can handle and its default settings.
• Job attributesJob attributes are properties of a print job that has been processed by the printer object and assigned to a job object. Job attributes can come from job template attributes, or attributes that the client submits to override default printer job template attributes. For example, a printer object can, by default, assign a specific priority to a print job. However, for a particular job, the client might need to override these defaults. Job attributes can also be job description attributes, which provide parameters, such as the job's size, state, and identification. Clients provide some job description attributes when they request the print job, and other attributes are provided by the print object as it processes the print request. For example, a requesting client can provide information regarding the number of pages in a print request (client-side job descriptionattributes), and the printer object can assign a job a Uniform Resource Identifier (URI) when it accepts the job for printing (server-side job description attributes).
• Operation attributesUnlike printer object and job object attributes, which provide characteristics relating to the objects involved in a print transaction, operation attributes describe the transaction itself. These attributes identify properties, such as where the job is being sent and what localization parameters might need to be defined in the transaction.
• Unsupported attributesBecause IPP attributes are extensible, a client from a particular vendor can issue a request containing attributes that are only supported by the print object provided by the same vendor. If the same attributes are sent to an IPP of another vendor, then these attributes might not be supported. If this is the case, the IPP server returns a message to the client listing which attributes it does not support. This enables the IPP client to issue only those requests that the print object can fulfill. This process allows the client and server to "negotiate" job parameters during the request and response sequences.

  More Info

  IPP structure and semantics are defined primarily in RFCs 2565 and 2566, which can be found in the Rfc folder on the companion CD-ROM.

IPP Request Response Mechanisms

IPP operations are passed between client and server as a series of HTTP/1.1 request and response messages. When a client submits a print request to a print object (IPP server), the client sends a request message to the printer object URI. This message contains operation attributes, object attributes, and the document to be printed. Each request message is followed by a response message from the IPP server. The response message contains a code indicating the success or failure of the requested operation, as well as operation attributes, object attributes, and status messages that the server generated.

After the server has accepted the print request and created a job object with its own URI, the client can request the addition of further documents to the same job object. Although a printer is not required to support job objects that contain more than one document, allowing the submission of multiple documents to a single job object increases printing efficiency and allows print requests to be "batched." Because each job object can be queried, the client can use a single job URI to obtain status reports on multiple documents if the server supports this mechanism.

Each operation request issued by the IPP client must contain a Version-Number, an Operation-ID, a Request-ID, and any attributes required by the specific request type. Each server response message must contain a Version-Number, a Status-Code, the Request-ID that the client issued, and any attributes that are specific to that request type. Figure 19-5 illustrates the format for these requests and responses.

Figure 19-5: Request/Response format.

As Figure 19-5 demonstrates, the Version-Number is the version identifier for the request/response sequence. The Operation-ID is used in a request message to specify what operation the client wants to request of the print object, and the Status-ID is sent in the server's response message to indicate whether that operation was successfully received and processed. The Request-ID is used to assign a number to the request for tracking purposes. The 1-byte Attributes field identifies the type of attributes being sent in this request or response message (printer, job, operation, or unsupported), and the variable-length Attributes sequence lists the attributes particular to that type. The end of theAttributes sequence is indicated by a 1-byte End-Of-Attributes tag, and the remaining bytes might or might not consist of the actual print data being sent.

Operations

An IPP client requests submission of a print job by sending an HTTP Request message containing an operation request and attributes to the printer's URI. The printer uses the information provided by the client to construct a new job object, the URI of which is then passed back to the client so that the client can use it for purposes of querying or adding to the job. IPP version 1 defines certain operations, listed in Table 19-5, which can be requested of a printer or a job.

Each of these operations can be sent as part of either a request or response message between IPP client and printer. Each operation includes attributes that identify the details of the request or response. Printer attributes can be sent as part of a printer operation message, and job object attributes can be sent as part of a job operation.

Attributes

Attributes are extensible characteristics or properties of any object in IPP, such as printer objects, job objects, and operations. Attribute specifications include the name of theattribute, followed by its syntax in parentheses. Tables 19-6, 19-7, 19-8, and 19-9 describe these attributes.

Internet Printing Security

Because a printer object can be represented by more than one URI, an administrator has very flexible control options. For example, a printer can be represented by one URI that accepts unsecured HTTP connections and another URI that only accepts Secure Sockets Layer (SSL) connections. The printer administrator can grant specific permissions to each of the URIs, thereby permitting some clients to print over an unsecured connection and forcing others to print only over a secured connection. Additionally, because the printer object can be published in Active Directory, all Windows 2000 security mechanisms can be applied to the printer. Although IPP provides mechanisms for printing using HTTP, it does not provide full file-sharing functionality; CIFS provides that functionality.

Summary

CIFS enables platform-independent file and printing sharing sessions to be established between a client and a server over the Internet or an intranet. CIFS clients use these connections to access file and print resources including Dfs. IPP can extend the functionality and ease of printing in the Windows Server 2003 family. Using IPP, installing and using a printer can be as simple as typing a URL into a Web browser. The IPP functions of IIS also allow you to query individual printers and to view and manage the printer queue using an Internet browser.