NetWare Enterprise Print Services
Articles and Tips: article
01 Dec 1999
Print services are essential to users but can be difficult to set up and manage. If users glanced at this lead, they'd probably yawn while asking if this is one of those boring articles about printing. Users take network printing for granted and don't care what you do to make printing possible.
For example, Windows, Macintosh, UNIX, and mainframe users don't care that you set up and maintain at least four different printing systems so that they can print. Nor do these users care how many utilities you use or tasks you complete so they can share printers, despite different client platforms. In fact, to users, network printing is like tap water: They care only that it works--always; they don't care how.
Fortunately, I'm not talking to users. I'm talking to you--network administrators. So let's start again: Print services are essential to users but can be difficult to set up and manage. If your company's network (like most networks) has a mixture of client platforms, you probably responded to this lead with a snort and a snide comment about understatements of the century. But print services don't have to be difficult to set up or manage. If you're cynical, you're probably squinting your eyes and asking, "Oh yeah? Prove it!" And that's just what Novell aims to do with NetWare Enterprise Print Services (NEPS).
NEPS is an add-on software product that you can install on NetWare 4.11, NetWare 4.2, NetWare 5, and NetWare 5.1 servers. NEPS is based on the architecture of Novell Distributed Print Services (NDPS) 2.0, which prior to NEPS, was available only for NetWare 5 and NetWare 5.1. (If you're running NetWare 4.11 or NetWare 4.2, and consequently running NDPS 1.0, see "Step Up to NDPS 2.0.") In addition to the features offered by NDPS 2.0, NEPS offers the following three features, which introduce entirely new advantages, regardless of the NDPS version you're running:
Line Printer Remote/Line Printer Daemon (LPR/LPD) server
Internet Printing Protocol (IPP) server
Vendor-specific gateways
Generally speaking, the result of these features is that with NEPS you can set up and manage print services more easily and for a wider range of client platforms than you can with NDPS alone.
THE ARCHITECTURE UNDERLYING NEPS
Most of you have probably read about or are using NDPS. (For more information about NDPS, see "NDPS: Good-bye, Queue World!" NetWare Connection, Oct. 1997, pp. 6-22. You can download this article from http://www.nwconnection.com/past.) To understand NEPS, you need at least a basic understanding of the key architectural components of NDPS. A brief discussion of these components follows. (If you already understand the NDPS architecture, skip to the "Sounds Great, But What's the Catch?" section.)
The following server-side components form the foundation of the NDPS architecture and, therefore, of NEPS:
NDPS Manager
Printer Agents
NDPS Broker
Gateways
NDPS Manager
One of the first steps you take to set up both NDPS and NEPS is to load the NDPS Manager (NDPSM) NetWare Loadable Module (NLM) on every server that will run one or more Printer Agents. In other words, you load NDPSM on every server that will provide print services for one or more printers.
For every NDPSM that you load, you also create a Novell Directory Services (NDS) object calledPrint Service Manager object. Using the NetWare Administrator (NWADMIN) utility, you can open the Print Service Manager object to manage NDPSM, which in turn enables you to create and manage Printer Agents.
Printer Agents
Printer Agents form the core of the NDPS architecture underlying NEPS. Printer Agents are software programs that can run on the server as an NLM or can be embedded in a printer. (Today, no printers with embedded Printer Agents are available, so Printer Agents run on servers.)
Printer Agents replace the need for print queues and print servers by doing the job of both. However, Printer Agents can do much more than spool jobs and extract them from queues. For example, Printer Agents store or have access to information about the printers they represent, such as the printer's name, network address, status, and characteristics. Printer Agents can relay this information to NDPS clients that request it.
NDPS Broker
NDPS clients can request information about printers and print jobs. For example, an NDPS client may request to be notified about the status of a print job. In this case, the Printer Agent accesses the NDPS Broker. The NDPS Broker loads automatically when you install NEPS on a server (just as it does when you install NDPS alone). When the NDPS Broker loads, NEPS also automatically creates an object to represent the NDPS Broker in the NDS tree.
The NDPS Broker relays information between Printer Agents and three services:
Resource Management Services (RMS)
Event Notification Services (ENS)
Service Registration Services (SRS)
RMS stores network resources such as drivers in a central location and locates these network resources for clients and printers. For example, when an NDPS client first installs a printer, the Printer Agent for that printer accesses RMS (via the NDPS Broker) to request the appropriate driver. RMS returns the driver, which NEPS then automatically installs on the client.
ENS makes it possible for users that are running the NDPS client software to request to be notified about a print job's status. Because Printer Agents can access ENS, you (or anyone with the necessary rights) can also configure NEPS to notify somebody else of a print job's status or of a printer's condition. For example, you can configure NEPS to notify somebody else when a printer that is located several floors or buildings away from you is low on toner. By configuring NEPS in this way, you can remind the person sitting next to this printer to fix a simple problem that would otherwise cost you a trip (and some time).
Through ENS, users that are running the NDPS client software can request notification by way of pop-up screens, log files, or e-mail messages. In addition to supporting GroupWise (4.x and above) and Message Handling Services (MHS), NEPS supports most other e-mail programs through its support of the Simple Mail Transfer Protocol (SMTP).
SRS enables printers and other services to advertise their availability on the network without forcing each printer or service to use the Service Advertising Protocol (SAP). Instead, NDPS printers and other services register with SRS, and SRS advertises its own location using SAP in IPX environments and Service Location Protocol (SLP) in IP environments. NDPS clients and printers then access SRS to learn the location of NDPS printers and services. As a result, NEPS reduces the traffic that print services can otherwise generate on a network.
Gateways
Finally, for every printer you want to configure as an NDPS printer, you also need to install the Novell gateway or a vendor-specific gateway. NEPS includes several new vendor-specific gateways. (For more information, see "The Back Door To NEPS" section.)
Basically, these gateways connect Printer Agents to printers. For example, when you create a Printer Agent, you configure the gateway associated with that Printer Agent to understand the printer's make and model and the way this printer is attached to the network (by way of a parallel or serial port or via the RPRINTER utility, for example).
The Components in Action
In general terms, the NDPS architectural components underlying NEPS work together as follows to enable NDPS clients to submit jobs to NDPS printers: When a user at an NDPS client decides to install a printer, the NDPS client asks the Printer Agent which printer driver to install. The NDPS client then accesses RMS to retrieve the driver, and NEPS then automatically installs the driver.
When the user prints to this newly installed printer, the user's application formats the data using the printer driver, and the NDPS client then submits the job to the Printer Agent. The Printer Agent receives the job and queues and spools it. If the user has requested to be notified of this job's status, the Printer Agent registers that request with ENS.
As soon as the printer to which the user sent this job is free, the Printer Agent retrieves the job from the spooling area and submits it to the Novell gateway or the vendor-specific gateway. This gateway then channels information to and from the printer through the appropriate port. (See Figure 1.)
When the job is printed, the printer notifies the Printer Agent via the gateway, which in turn notifies ENS. If ENS has stored a request for notification of job completion from the NDPS client, then ENS uses whatever format the client requested to notify the NDPS user of the job's completion.
ADMINISTRATIVE ADVANTAGES OF THE ARCHITECTURE
These technological underpinnings to NEPS yield several administrative advantages. For example, NEPS' intrinsic NDPS architecture makes NEPS much easier to set up than legacy NetWare print services. With legacy NetWare print services, you must create and link three NDS objects per printer: a Print Queue, a Print Server, and a Printer object. This system works but can be difficult to troubleshoot. In contrast, with NEPS, you create only one Printer Agent per printer.
With NEPS, you can set up some printers as easily as plugging them into the network (directly or by way of a workstation or server) and then creating Printer Agents on the servers running the NDPS gateways for these printers. These printers are called public access printers, which are printers to which you don't control users' access.
Setting up controlled access printers requires only one more step than setting up public access printers. Controlled access printers, as the name suggests, are printers to which you control users' access. To set up a controlled access printer, you plug a printer into the network, create a Printer Agent, and then create a Printer object in your company's NDS tree.
After you have set up NEPS (and NDPS for that matter), you can use the NWADMIN utility to manage printers and print services. With legacy NetWare print services, on the other hand, you must use several software programs to manage printers and print services, including the NWADMIN utility, PSERVER, and several third-party utilities--one for each vendor's printer.
SOUNDS GREAT, BUT WHAT'S THE CATCH?
All of the administrative advantages of the NDPS architecture upon which NEPS is based sound great--and they are. However, there is a catch: Without the additional features that NEPS contributes to the NDPS architecture, the advantages apply only to setting up and managing print services for Windows users. Novell currently provides an NDPS 2.0 client for only Windows NT, 98, 95, and 3.1x clients, and an NDPS 1.0 client for only Windows 95 and 3.1x. (The NDPS 2.0 client is part of the NetWare client software for Windows clients that ships with NetWare 5 and NetWare 5.1. The NDPS 1.0 client is part of the NetWare client software for Windows clients that ships with NetWare 4.11 and NetWare 4.2.)
In other words, only NDPS clients--that is, only Windows users--can print directly to NDPS printers. And you know what that means, don't you? You will have to set up and manage legacy print queues for non-NDPS clients--that is, die-hard Macintosh fans, UNIX mavericks, and mainframe users. (See "Too Many Non-Windows Clients to Ignore.")
In addition, for each non-NDPS client platform, you will have to set up different print services to transport print jobs from these non-NDPS clients to the legacy queues. You will then have to configure NDPS Printer Agents to service those queues by specifying the location of these queues in the Queue Management Services (QMS) Backward Compatibility field. (This field is located on the Spooling Configuration dialog box, which you access by selecting the spooling option from the Job pull-down menu on an NDPS Printer object's Printer Control page.)
Admittedly, configuring NDPS Printer Agents to service the legacy queues works. However, because you have to create queues for NDPS printers, you miss out on one of the primary advantages of NDPS and NEPS. That is, you must still set up, manage, and troubleshoot queues.
"GOODBYE, QUEUE WORLD!"--SAY IT AGAIN WITH NEPS
Fortunately, NEPS provides support for Macintosh, UNIX, and many mainframe users, enabling them to print directly to NDPS printers. With NEPS, you won't need to set up and manage different printing systems for these users. With NEPS, you really can kiss the entire queue world good-bye. (See Figure 1.)
Figure 1: Through the LPR/LPD Server and IPP Server, NEPS provides unified print services for a wider range of users, including Macintosh, UNIX, and many mainframe users. Through the vendor-specific gateways, NEPS can communicate with a wider range of printers using their specific protocols to tap into these printers' full range of capabilities.
NEPS supports these users indirectly through its support for LPR (a UNIX print command) and LPD (a UNIX daemon program that controls printing). NEPS supports LPR/LPD through the LPR/LPD server.
The LPR/LPD server is an NLM that is automatically loaded when you use the NWADMIN utility to configure a Printer Agent to support LPR/LPD. Of course, the word configure conjures up all sorts of complex management tasks that belie the simplicity of "configuring" a Printer Agent to support LPR/LPD. To configure a Printer Agent to support LPR/LPD, you complete three simple steps:
Using the NWADMIN utility, double click to open the NDPS Printer object (also known as acontrolled access printer) or Public Access Printer that represents the physical printer for which you want to enable LPR/LPD support.
Click the Enterprise NDPS LPR/LPD Support button. (See Figure 2.)
Figure 2: With NEPS, NDPS Printer objects have two new options: Enterprise NDPS IPP Support and Enterprise NDPS LPR/LPD Support. Clicking these options opens dialog boxes that enable you to configure Printer Agents to support IPP and LPR/LPD, respectively.
Click "Enable LPR/LPD services for this printer." (See Figure 3.)
Figure 3: To enable an NDPS Printer Agent to support LPR/LPD, you simply click the appropriate field.
By configuring the Printer Agent to support LPR/LPD, you enable any system that can submit jobs via the LPR/LPD standard to print directly to the NDPS printer that this Printer Agent supports. UNIX, Macintosh, and even some mainframes support LPR/LPD.
In fact, by default UNIX workstations print using LPR/LPD. After you have enabled a Printer Agent to accept LPR/LPD print jobs, the UNIX users need only load the correct driver on their workstations to send jobs to this printer.
You can configure Macintosh workstations to print to NDPS printers by changing the desktop default settings from printing via AppleTalk to printing using LPR/LPD. You can configure Macintosh workstations to print using LPR/LPD when you create new printers to represent the NDPS printers to which the Macintosh users will print. (For more information about configuring Macintosh workstations to print using LPR/LPD, see "How Do You Get From Mac to NDPS? [No Queues Please!].")
You can also configure many mainframes to print to NDPS printers using LPR/LPD via TCP/IP services. For example, to configure systems running Open Virtual Memory System (OpenVMS) to print via LPR/LPD, you can use a product such as Compaq's DIGITAL TCP/IP Services for OpenVMS software. (For more information, see http://www.openvms.digital.com:8000/72final/6525/6525profile_015.html#print_chap.) To configure IBM systems running the Virtual Storage Extended (VSE) operating system (such as IBM 4381s and IBM 9870s) to print via LPR/LPD, you can use a product such as Connectivity Systems' TCP/IP for VSE. (For more information, see http://www.tcpip4vse.com/concept.htm.) To configure IBM systems running Multiple Virtual Storage (MVS) operating system and systems running Virtual Machine (VM) operating system to print via LPR/LPD, you can use IBM's TCP/IP services for those operating systems. (For more information, see http://www.redbooks.ibm.com/abstracts/gg243376.html.)
IT'S A THANKLESS JOB
You should be warned, however, that after you enable Macintosh, UNIX, and mainframe users to print to NDPS printers, these users won't care--they won't be able to tell the difference. Non-Windows users on a network with NEPS simply get the "same printing they get today, except that they get to print directly to an NDPS Printer Agent," says Brad Christensen, Novell product manager for NEPS and Novell's backup and clustering solutions.
Non-Windows users don't get all of the advantages that Windows users enjoy because there is no NDPS client software for non-Windows platforms. As Christensen explains, "The good news for UNIX, Macintosh, and mainframe users is they don't have to install any software" to be able to print directly to NDPS printers. "The bad news," Christensen wryly admits, "is that because they haven't installed any software, they don't have any of the advantages of installed software." For example, NEPS cannot load drivers on non-Windows clients and cannot notify non-Windows clients of a printer's characteristics or of a print job's status.
In other words, "the value in supporting UNIX, Macintosh, and mainframe clients [through the LPR/LPD server] is not to the end user," Christensen says. The value is to you, the network administrator.
EXTRA, EXTRA, READ ALL ABOUT IPP
In addition to the LPR/LPD server, NEPS includes an IPP server to support IPP clients, which you may not have now, but you may want soon. Unless you've been under quarantine, you've probably heard that IPP is a new printing protocol that makes it possible to send print jobs to printers on intranets or on the Internet in the same way you send print jobs to a printer on your desk.
To put the IPP print model into action, you will need the two objects upon which this model is based: an IPP client and an IPP printer (or print server), both of which must have the HTTP 1.1 stack. IPP 1.0 uses HTTP 1.1 to traverse intranets and the Internet.
The IPP client encodes requests, uses HTTP 1.1 to send these requests across the wire, and decodes responses from IPP printers. For a printer to receive and understand print requests from IPP clients, it needs IPP server software, either embedded on the printer itself or running on the print server. The IPP server software decodes the IPP requests it receives, translates those requests into a language the printer can understand, and encodes any responses from the printer back into a language the IPP client can understand.
With IPP client software running on users' desktops, users can install the IPP printers on the desktops to which they want to print. When users with IPP client software first install IPP printers on their desktops, they also need to install the appropriate printer driver, just as they would to install any printer. Users must also specify the printer's URL. Users then can make the IPP printer their default printer (which may be preferable on an intranet), or they can choose the printer each time they print.
WHERE IPP'S AT
If you think that IPP sounds great in theory but you'll believe in Internet printing when you see some actual IPP products--start believing. IPP clients and printers are already available.
IPP Clients
IPP client software for both Windows and UNIX platforms is available from several vendors, including Hewlett-Packard, Microsoft, ShineSoft, and Easy Software Products. (For an updated list of IPP client software and other IPP products, visit ftp://ftp.pwg.org/pub/pwg/ipp, and open the Products folder. From there, you will see several files that are named according to date. A file posted on September 17, 1999, for example, is called990917--IPP--Products.docor990917--IPP--Products.html. Click to open the most recent Products file in the format you prefer.)
For example, for several months Microsoft has been offering IPP client upgrades to its Windows 95 and Windows 98 platforms and will include the IPP client in Windows 2000. (For more information about IPP on Windows 95, see http://www.microsoft.com/Windows95/downloads/contents/WUPreviews/IPP/Default.asp. For more information about IPP on Windows 98, refer to the same address except substitute Windows98 for Windows95. For more information about Windows 2000, see http://www.microsoft.com/windows/preview/order.asp.)
Easy Software Products has had IPP client software available for about nine months as part of its Common UNIX Printing System (CUPS). CUPS replaces the System V and Berkeley print systems included in most versions of UNIX with a compatible IPP-based printing system. CUPS also uses Adobe PostScript Printer Description (PPD) files and a MIME-type filter database that together enable you to print to PostScript printers--and use all of their capabilities--"just by grabbing the appropriate PPD file," notes Michael Sweet of Easy Software Products. (For more information about CUPS, visit http://www.cups.org.) Easy Software Products also provides ESP Print Pro software, which is based on CUPS and includes drivers for more than 1600 PostScript and non-PostScript printers. (For more information, visit http://www.easysw.com/printpro.)
Apple Computer has also announced plans to support IPP in future versions of the Macintosh operating system. Admittedly, given Apple's policy of not preannouncing product releases, you have no way of knowing just how soon this future IPP-enabled version will be available. However, the general consensus seems to be that it will be sooner rather than later. To print using IPP, Macintosh users will need to configure their workstations using steps similar to the steps they take to print using LPR/LPD, according to Paul Danbold at Apple.
Without Novell, IPP may still be only a distant dream. After all, Novell is responsible for spawning the idea of a printing protocol for the Internet and for approaching other companies with that idea.
IPP Printers and Print Servers
Printers with embedded IPP software are also available from Lexmark and Xerox, and small print servers that can accept IPP requests for jobs intended for specific printers are available from Hewlett-Packard, i-data, and Tally. Large print servers, such as the NEPS IPP server, that can accept IPP requests are also available.
The availability of these pieces means that printing over the Internet--assuming you have the necessary software--is possible today. And Internet printing is working. The Printer Working Group (PWG) has twice held "Bake-Offs," during which IPP vendors gather to test IPP solutions to ensure interoperability. (The PWG is a consortium of major printer and print server vendors. This consortium is chartered to make printers, applications, and operating systems work together better. The PWG is also the parent organization to the IPP Working Group, an Internet Engineering Task Force (IETF) working group. For more information about the PWG, the IPP Working Group, and IPP in general, see http://www.pwg.org.)
Novell hosted the second IPP Bake-Off during March 9-12. At this second Bake-Off, representatives from 24 companies--including Apple, Easy Software Products, Epson, Extended Systems, Hewlett-Packard, Lexmark, Tektronix, and Xerox--gathered and tested 11 client solutions and 27 printer solutions. The PWG reports that of the 297 possible client-printer combinations, 296 were successful in completing a simple print-job operation. (For more information about the Bake-Off Novell hosted, see http://www.pwg.org/ipp/testing/bake2.html.)
Of course, Novell's contributions to IPP have been far more significant than merely hosting this Bake-Off. Without Novell, IPP may still be only a distant dream. After all, Novell is responsible for spawning the idea of a printing protocol for the Internet and for approaching other companies with that idea in the summer of 1996. Representatives from Novell, IBM, and Xerox are considered the main editors of the model document that describes how IPP works. Furthermore, much of what IPP is and what it can become has its roots in NDPS.
YOU WANT IPP--NEPS HAS GOT IPP
So where does NEPS fit into this big IPP picture? The NEPS IPP server supports IPP 1.0, as described in the IETF Requests for Comments (RFCs) numbers 2565 through 2569 and 2639. (You can download these RFCs by visiting http://www.pwg.org/ipp/index.html and clicking the hypertext links to those documents.) IPP 1.0 describes how IPP clients can submit jobs to IPP printers and find out about IPP printers' capabilities and status.
NEPS also supports IPP Optional Operations--Set 1, which is described in the IPP/1.1 IETF Internet-Draft. (You can view this document at http://www.ietf.org/internet-drafts/draft-ietf-ipp-model-v11-04.txt.) As the name suggests, these IPP Optional Operations describe additional operations (such as hold job, restart job, pause printer, and resume printer) that vendors have the option to include in their implementation of IPP.
The NEPS IPP server sits in front of NDPS Printer Agents, translating requests from IPP clients into a language NDPS Printer Agents can understand and coding responses from NDPS Printer Agents into a language that IPP clients can understand. The result is that any IPP client can print to any NDPS printer, assuming, of course, that there are printer drivers available for the printers to which the IPP client wants to print.
You may ask, so what? How does NEPS' support for IPP benefit you or users? The most obvious benefit to you is the benefit of NEPS overall: a unified printing system for all of the clients on your company's network. For users, the NEPS IPP server potentially benefits UNIX and Macintosh users the most but also provides a nice alternative for Windows users.
For UNIX and Macintosh users, IPP offers much richer features than those offered by LPR/LPD. For example, using the NEPS IPP server, IPP clients on an NEPS network can discover the capabilities of an NDPS printer, such as the printer's speed or whether or not the printer supports color. IPP clients on an NEPS network can also collect information about a print job (such as whether or not the job has been completed or was cancelled) after it is sent to an NDPS printer. In other words, the level of information that UNIX and Macintosh users can get using IPP is "orders of magnitude above" the information they can get using LPR/LPD, says Novell consultant Hugo Parra, who is also Novell's PWG representative.
UNIX, Macintosh, and Windows users with IPP client software can also print to an NDPS printer via the NEPS IPP server without having to log in to the network. However, you can still control which users are able to print to printers for which you have configured NEPS to allow IPP services. "IPP supports Internet security models for authentication and encryption," explains Parra, enabling you to separately configure the NEPS IPP server to accept print jobs only from known users. Because users can print to NDPS printers without having to log in to the network, users can finish up a document from a home computer or a laptop that is not running NDPS client software and send this document to the printer on their desk at work.
In future versions of NEPS, Novell plans to include an IPP gateway, which will sit behind NDPS, enabling NDPS Printer Agents to print jobs from any client to any IPP printer on the Internet or on your company's intranet. With an IPP gateway, NDPS Printer Agents will be able to find out about an IPP printer's capabilities or about the status of print jobs sent to IPP printers. NDPS Printer Agents will then be able to return that information to IPP and NDPS clients. (Without the IPP gateway, IPP clients can find out only about the capabilities of NDPS printers or the print jobs sent to these printers.)
THE BACK DOOR TO NEPS
NEPS' LPR/LPD and IPP servers open the front door to the NDPS architecture, enabling not only NDPS clients but also non-NDPS clients to print directly to NDPS printers. NEPS also opens up the back door to NDPS by including more vendor-specific gateways, which enable NDPS Printer Agents to speak directly to a wider variety of printers using printer-specific protocols. Specifically, NEPS ships with gateways for printers from the following printer vendors:
Epson
Extended Systems
Hewlett-Packard
Lexmark
Tektronix
Xerox
If you've used NDPS 1.0 or NDPS 2.0, you're aware that NDPS includes a Novell gateway, which makes it possible for NDPS to communicate with virtually any printer. However, the Novell gateway does not know or use every printer-specific protocol. Because the Novell gateway does not know or use vendors' proprietary protocols to communicate with the vendors' printers, NDPS is unable to tap into the full range of functionality offered by printers connected to NDPS Printer Agents via the Novell gateway.
Figure 4: With NEPS, you can configure a Macintosh workstation to print directly to NDPS printers over LPR/LPD by selecting Printer (LPR) from the New Printer dialog box and entering the IP address of the NDPS printer in the Internet Printer dialog box.
As you would expect, the vendor-specific gateways use the vendor-specific (that is, proprietary) protocols that these vendors' printers use, enabling NDPS to detect and use all of the capabilities these printers have to offer. For example, the Hewlett-Packard printer gateway connects NDPS Printer Agents to printers that attach to IPX or IP networks via a Hewlett-Packard JetDirect print server or a Hewlett-Packard JetDirect card.
This printer gateway is able to tap into a unique capability of the Hewlett-Packard JetDirect protocol: automatic detection. When you plug a Hewlett-Packard printer into the network, the Hewlett-Packard gateway automatically detects its presence and creates an NDPS Printer Agent. Users can then begin printing to this printer immediately--with no additional intervention on your part (assuming you want this printer to be a public access printer).
In addition to enabling NDPS to recognize and use printers' full range of capabilities, the vendor-specific gateways ship with snap-in modules for the NWADMIN utility. Rather than having to use the management software designed specifically for managing a specific vendor's printers, you can manage all of your company's printers using the NWADMIN utility.
For example, the vendor-specific gateways include the NWADMIN snap-in modules that change the appearance and contents of each printer's Printer Control page. (The Printer Control page appears when you open a public or controlled access printer in the NWADMIN utility.) These vendor-specific Printer Control pages offer views of the specific printers you want to manage and provide information about these printers that the generic Printer Control page does not show.
For example, Lexmark's gateway supports the Lexmark MarkVision family of printers. The Lexmark Printer Control page not only shows you a picture of the specific printer you want to manage but also shows you the display panel on that printer. You can use your mouse to manipulate that display panel from your workstation just as you would if you were standing in front of the physical printer.
PRINT SERVICES FOR YOUR ENTIRE NETWORK
Through LPR/LPD and IPP servers on the front end of the NDPS architecture and new vendor-specific gateways on the back end, NEPS gives you a single printing system for nearly all network users and the ability to manage all of your company's printers using only the NWADMIN utility. With NEPS, you can set up and manage--not to mention, pay for--only one printing system for an entire network. (NEPS plus five user connections is U.S. $995.) Through NEPS' vendor-specific gateways, which include snap-in modules for the NWADMIN utility, setting up and managing that single printing system is easier than ever before. So let's state it again, one last time: Print services are essential to users but can be difficult to set up and manage--unless you have NEPS.
Linda Kennard works for Niche Associates, which is located in Sandy, Utah.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.