Understanding NDPS Novell Distributed Print Services is a new generation of printing services created by Novell, Xerox and Hewlett Packard (HP) which is intended to provide a simpler and easier to manage system than the established trinity of printer, print queue and print server. NDPS was originally developed as an add-on for NetWare 4 and is included as a standard part of NetWare 5. NDPS does not replace existing printing environments, both may co-exist so you can migrate to NDPS gradually. A key feature of NetWare 5 which is also important to NDPS is support for a pure IP environment, i.e. one which does not use IPX at all. NDPS-aware devices are available from a number of vendors including Epson, Hewlett Packard, Lexmark and Xerox and gateway software is available to provide device-specific or generic support for a wide range of other products. Once it was set up and working, something which is admittedly sometimes easier said than done even in a simple printing environment, the old system of printer, queue and server usually worked reasonably well. As well as changing how printing works, NDPS adds a range of new features. Those with a reasonably modern printer connected directly to their computer will probably be quite used to receiving fairly specific status messages from the printer. Instead of a simple "the printer is not responding", messages may differentiate between being out of paper and a paper jam. This sort of feedback is now also available to clients on the other side of the network. Printer drivers are stored on a server (or even the printer in some cases) and may be downloaded to a client workstation automatically. Improvements to print job control, monitoring and reporting have been made for both administrators and users. For example, a "toner low" message could be returned to the user but it could also generate an email to go to someone responsible for actually replacing the toner as well. Both administrators and users, if they are given permission, may monitor printers and move jobs between them if necessary. Job scheduling options make it possible to vary how the document is to be printed based on a number of factors including the time of day and the size of the job. Printer-specific control options make it possible to restrict who can use the colour aspect of a colour laser printer, for example, whilst still allowing other users to print in black and white only on the same printer. Network traffic is reduced because NDPS components communicate directly with each other rather than using regular SAP broadcasts. The exception to this is during the initial registration of components when broadcasts are still used to find out what other NDPS components are out there. SNMP management allows integration with existing management systems. "Plug and print" features mean that it is possible to plug a suitable printer in to the network and have it available for use immediately. Although possibly a good selling point, most environments will still require a certain amount of configuration work to be carried out however. Support for existing queue-based printing environments allows NDPS clients to print to legacy queues and non-NDPS clients to print to NDPS devices. The same printer can service both a queue and NDPS. Components NDPS is made up of a number of components o Broker o Manager o Printer Agent o Printer Gateway o Client software The NDPS Broker provides a number of network support services for the other components, specifically: o Service Registry Services (SRS) advertises public access printers on the network to make them easier to find. o Event Notification Service (ENS) allows printers to send messages to users and operators by a variety of means including pop-up message, email or log file. o Resource Management Service (RMS) maintains resources such as printer drivers, banners and fonts so that clients can download and use them as required. Only one broker is required per three hops on the network and they won't automatically be created any closer together than this. It is possible to create additional brokers if performance, network bandwidth or reliability requirements make one desirable however if there is more than one broker then updates such as new printer versions must be manually applied to each one by the administrator. Collections of printer agents are managed by an NDPS manager and it must be created before any of the printers it is to manage. Only one manager may be loaded on a server but there is no fixed limit to the number of printer agents that a manager can support. The Printer Agent combines roles which were previously fulfilled by the printer, print queue and print server objects in earlier NetWare versions. Every printer must be represented by its own agent so that if you have 30 printers you must have 30 printer agents. A printer agent may run on a computer to represent a printer elsewhere on the network or a printer may have its agent embedded in it. Each printer agent manages many of the functions of the printer as well as job processing. It is responsible for dealing with client requests for information such as print job status or printer attributes (colour, paper sizes, etc.) and also generates events notifications such as job completion or printer problems. Devices which are not NDPS-aware are catered for by gateways. Printer or manufacturer-specific gateways provide the best level of interaction between network and printer since they will have a detailed knowledge of the facilities available from the printer. There is also a generic gateway which provides a minimum but generally usable level of support for any other print device. Client software, available as part of the current Novell client set, is required to enable workstations and users to take advantage of the new facilities in NDPS. This then deals with the requirements for finding out which printers are available, downloading drivers and sending documents to printers. The user just sends a document to a printer (rather than to a queue as previously) and NDPS handles the rest. If the NDPS client software is not installed the user will only be able to print to queue-based printers. A printer must be installed on a workstation before the user can print to it. The downloading of printer drivers may be handled in a number of ways. The normal method of using the Add Printer wizard is supported but it is also possible and usually preferable for the administrator to specify which printers a user should have access to. These printers may then appear in the workstation printer list automatically with drivers being installed without user intervention. It is also possible to specify that printers should be removed from the workstation to really restrict what the user has access to. Any printer on the network, regardless of type or connection method, is regarded as either a public access or controlled access printer. Public access printers provide a plug and print capability - simply connect the appropriate NDPS-aware printer to the network and it becomes available to anyone. This availability is without restriction so security is minimal. Public access printers are not represented by an object in NDS. Instead, management is carried out using a utility obtain via. the Tools menu in NWAdmin, the GUI NetWare Administrator tool. It is necessary to have created a broker, manager and at least one printer agent before a public access printer can be created. Public access printers may be converted to controlled access at any time. Controlled access printers are represented by an object in NDS and may be subjected to all the management and security controls which you would expect, all within NWAdmin and the properties of the printer agent. Controlled access printers can also take advantage of the full range of event notification options which are available. When a controlled access printer is created access to it is granted to users in the same container automatically. Users residing in other containers must have access granted manually. Creating a controlled access printer requires Read, Write, Modify, and Create rights for the container in which the printer will reside. Assuming there are a broker and a manager already running, use NWAdmin to create a new NDPS printer and provide a name for it. Choose the appropriate source for the printer agent from a new printer agent using a gateway, an existing NDPS printer object or an existing public access printer. Confirm the name, associate the printer with the correct NDPS manager and if required complete any additional information for any gateway to be used. Finally, unless NDPS detects that it has the appropriate drivers already it will be necessary to select which drivers to maintain for different client platforms (Windows 3.x, Windows 9x or Windows NT). The HP printer gateway shipped as standard with NetWare 5 supports IP and IPX and allows both controlled and public access printers to be created which are connected to the network using HP JetDirect interfaces, either internal cards in HP printers or external units. Wherever possible, ensure that the JetDirect unit is running the latest version of firmware available. Check the HP Web site (www.hp.com) for up to date information. Planning Migration from a queue-based system requires careful planning and should consider such factors as how many printers there are and of what type (including how they currently connect to the network), compatibility requirements with clients or printing devices which are not NDPS aware, who is going to use the printers and who is going to manage them. Whatever you are planning make sure you know exactly where you are now and be very clear about where you expect to end up otherwise it is impossible to properly plan and then to be confidant that you have achieved what you set out to do. It is possible to upgrade manually from a queue-based system to an NDPS environment however Novell have also made an upgrade wizard available which automates the process, allowing you to use drag and drop to dictate which objects are to go where. If you only have a few printers it may be easiest to create a new NDPS printing environment from scratch and delete the existing queues. If this is not possible, consider implementing NDPS on the servers first, testing it fully and then moving clients over to the new system gradually, running both printing environments in parallel until any initial problems are solved and you can delete the now superfluous queues. Optimising As installed, NDPS allows users to print with very little further configuration being required. There are various way in which you may wish to optimise printing for example to improve performance, fault tolerance or security. Although NDPS doesn't use queues in the same way as before, it is often still necessary to store print jobs somewhere either whilst a printer is busy printing something else or because the job is not to be printed until later. In this case, jobs are kept in a spooling area until they are to be printed. Usually this spool area is on the same volume as the NDPS manager for the printer however it is possible and sometimes desirable to move this area somewhere else, perhaps to a volume with more free space. It is possible to limit the amount of disk space that the spool area may occupy. A database is used by the NDPS Manager to store information about the printers it is responsible for. This database may be backed up to the server running the manager or to NDS. The major advantage to using NDS is that if the server becomes unavailable for any reason you can restore the manager database to another server and have that take over, otherwise the printers controlled by the manager on the failed server will be unavailable until the server is up again. NDPS security is maintained by assigning Manager, Operator and User access control roles. A manager is also automatically designated as an operator and user. An operator is also automatically designated as a user. Care taken when deciding where to place NDPS objects within NDS will also yield a number of benefits including easier security administration. NDPS users can submit print jobs to printers to which they have access and manage their own jobs. They cannot affect print jobs owned by anyone else. Operators are able to pause and reset printers, manage any print job (including reordering or deletion of jobs in the queue) and configure job spooling and printer properties. Operators cannot perform any NDS administrative functions but managers can. Managers are able to create, modify and delete NDPS printer objects, designate operators, users and other managers and configure any other aspect of NDPS. Event notifications can be used to inform the appropriate people when something happens to a printer. Notifications are classified as being either for the job owner or an interested party. A job owner might require a notification that their document has finished printing. A printer manager can dictate that an operator should receive notifications which require some kind of intervention such as low toner or paper jam. Depending on the facilities available on the network, notifications may be delivered by a wide range of methods including on-screen pop-up message, email (various formats) or simply by writing a message to a log file making it easy to keep historical problem information. Troubleshooting Many of the steps required in troubleshooting NDPS problems are common to problem solving in general. To being with check for error messages on the printer, client or server. Determine the scope of the problem, do you have a problem with the whole network (which could suggest a low level problem such as cabling or routing) or only with one workstation. If only one workstation is affected, check basic network connectivity (is the user really logged in to a server) and that jobs are being spooled correctly. Try pausing the printer output, resubmit the job and then check the job list to see what has appeared. If jobs aren't being printed it is often worth turning the printer off and then on again as part of the basic fault finding process. Consider whether anything has changed recently. Ensure that all physical connections are proper and all the correct software is loaded on the servers. If there is no immediately obvious solution to a problem a careful review of the printing environment will be called for. If you have a mixed NDPS and legacy queue-based printing environment then check whether it is only one or both which are affected by the problem. Future of NDPS The future of NDPS is that it provides the foundation for the recently announced NetWare Enterprise Print Services (NEPS). The primary advance of NEPS is support for the new Internet Printing Protocol (IPP), currently described in RFC document numbers to 2565 to 2569 inclusive. This will enable any client which supports IPP (including Unix and Macintosh clients for example) to take advantage of any printer available through NEPS. Some of the practicalities of NEPS (such as the downloading of printer drivers to any client) are not yet entirely clear, especially given the current "experimental" status of IPP. Overall however the support of openly available standards, which should make printing easier for users in a wide range of environments, must be seen as a positive step for Novell in an increasingly Internet or at least network dominated world. As well as the resources available on the Novell Web site at www.novell.com and within the quite usable NetWare 5 Online Documentation, an unofficial support site is also available at www.brightwood.com/ndps/index.html