Chapter 15

Novell’s Distributed Printing Services (NDPS) was created in response to the need to simplify printer management, and reduce printing costs. NDPS utilizes NDS for providing printing services and managing them from a single NDS object. In addition, NDPS brings new features such as:

• It can be used in a pure IP environment
• Makes available automatic printer driver downloads
• Supports bi-directional printing

Upgrading to NDPS is a worthwhile investment in effort for an existing print-queue-based NetWare network. The fact that it is included as part of NetWare 5 makes it easier to implement as part of an enterprise-wide network upgrade.

In any network system upgrade, one of the first tasks to perform is planning the new system. Protocol choice is a primary area to review. NDPS and NetWare 5 both support a pure IP environment, a pure IPX environment, or a combination of both protocols.

The final system design will depend on the printers already in use within the enterprise network and the protocols used by them. Under NetWare 5, NCP (NetWare Core Protocol) is capable of travelling on top of either IPX or IP. Any application, including the NDPS printing environment, that does not require direct interface with IPX or SPX, can run in a pure IP environment. Those applications that do require IPX interface, such as queue-based printing, can run in NetWare 5’s Compatibility Mode. Compatibility Mode allows IPX-based applications to communicate with the IPX protocol stack counterparts on the client or server without IPX packets being sent directly on the wire.

Security and management of NDPS components is handled in the NetWare Administrator because the NDPS components are integrated in NDS. Designing the NDPS components’ location in the tree, and on which servers they will be run, is a key step for a fully functional NDPS implementation.

Like any object in the NDS tree, the NDPS printers can be made available to all users, or can be locked down so they are available to a select group. There are three roles associated to the security of NDPS printers:

• Manager: maintains complete control of the NDPS component.
• Operator: has administrative control of the NDPS printer.
• User: is granted printing privileges to the NDPS printer.

The broker is the component of NDPS that makes the Service Registry Service, Event Notification Service, and Resource Management Service available to end users:

• The Service Registry Service (SRS) holds and advertises printer registration information (device type, address, and device-specific information) for public access servers so that users and administrators can find them. SRS prevents the need for SAP (Service Advertising Protocol), minimizing bandwidth utilization. When a client needs to send a print job to a printer, it contacts an SRS to retrieve the list of registered NDPS printers.
• The Event Notification Service (ENS) provides event notification for print jobs and status. ENS can be configured to notify the users that sent the print job, or to notify administrators about any printer events.
• The Resource Management Service (RMS) allows centralized printing resources such as print drivers, PDF (printer definition) files, and banners, to be downloaded to clients or printers.

Brokers are not required on all servers. However, the brokers will need to be distributed so that NDPS services are available when and where needed.

When installing a broker, the installer must have the Browse and Create object rights for the container where the Broker will reside. The installer will require file system rights of Read, Write, Modify, Create, and File Scan at the root of the server SYS: volume. The broker will store its databases in the SYS:NDPS/RESDIR directory, which is created at the time the Broker object is created.

When NDPS is installed for the first time into an NDS tree, the installation creates a broker on the server. After that, NDPS installations on new servers will follow a process to determine whether an additional broker is needed. First, it checks all NDPS brokers until one is found that is within three hops of the server that the installer has Supervisor rights to. At this point, the NDPS installation skips creating a broker. If a broker is not found, NDPS installation creates a new one.

Brokers can be moved to different NDS containers, as needed. The NetWare Administrator is the program used to move the Broker object (see Figure 15-1). When a Broker object is moved from one location to another in NDS, a corresponding change must be made on the server in the AUTOEXEC.NCF file. The LOAD BROKER or BROKER command will not have the new location or name of the broker, and that line should be changed.

If a system has multiple locations separated by WAN links, it is best to maintain a broker at each separate location. For example, if there are three buildings in Phoenix, one in London, and two in New York, and there are printers in each location, then the minimum number of NDPS brokers will be six. This corresponds to one NDPS broker in each building.

Figure 1: Broker object

The NDPS Manager makes printer agents available from a NetWare 5 server. The NDPS Manager must be created as an object in NDS tree before server-based printer agents can be created. The NDPS Manager object stores the information that is used by NDPSM.NLM on the server and can control an unlimited number of printer agents.

Each NDPS Manager object can be loaded on a single server with the NDPSM.NLM module. If the NDPS Manager controls a printer that is local to the server, then the NDPS Manager object can be loaded only on the server to which that printer is attached.

1. In the NetWare administrator, navigate to the container in which the NDPS Manager will reside and select it.
2. From the Object menu, select the Create option.
3. From the New Object dialog box, select NDPS Manager.
4. Type a name for the NDPS Manager object, and browse, then select the server that will be assigned to this object. Note that the NDPS Manager can be moved to another server, but when it moves, the NDPS database moves and any local printers will no longer be available for printing.
5. Browse for the database volume where the NDPS Manager database will reside. It must be a volume on the previously selected server, and will contain configuration information for the Printer Agents assigned to the NDPS Manager object. Make sure that there is between 3 and 5 MB of available disk space so that even a large number of printers can be managed.
6. Click Create.
7. In order to load the NDPS Manager automatically, start Remote Console by clicking the Tools menu in NetWare Administrator and begin a session or walk to a server console for the next steps.
8. Type NWCONFIG at the console.
9. Select NCF Files Options.
10. Select Edit AUTOEXEC.NCF.
11. Scroll down to the end of the file and add the line: NDPSM {NDPS manager name and context}.

The following methods can be used to create NDPS printers:

• Use NetWare Administrator and create the NDPS printer as a new object.
• Use NDPSM.NLM on the server console.
• Use the Novell Upgrade Wizard, which can be downloaded from Novell’s web site.

Client workstations must have their NetWare client software upgraded to the NetWare 5 client in order to print to NDPS printers. If there are a large number of workstation clients, the NetWare client software upgrade may be implemented in phases. NDPS can have the server components implemented in tandem with the maintenance of existing queue-based printing components.

In determining the location of brokers, printers, servers, workstation clients, and routers, the designer should have a written record of the existing network resources and components. Taking that written record and drawing a diagram of those components with the changes expected by NDPS will assist in the final configuration determination (see Figure 15-2).

A list of the printers currently in use, their configuration, and how they are used by end users will show which printers can be migrated to NDPS and which cannot. For example, if New York has seven identical printers on the second floor, and fourteen users print to four of the printers with DOS-based applications, then at least one printer must remain as a queue-based printer to serve those end users. If some of the users are on one side of the building in the HR group and the others are on the other side of the building in Accounting, then two printers will be more effective for servicing the DOS-based application print jobs.

Figure 2: Sample network diagram

To make a tree location diagram, draw the tree’s containers and place the potential NDPS Printing objects within. The tree location diagram will depict how the printers will be placed in containers, and whether they will be placed with the users that send print jobs to them.

The diagram can contain the NDPS Manager, the NDPS broker, printer users (grouped together), printer Managers and Operators, and printer configurations (see Figure 15-3). There may be some simplification or reorganization of the tree, until you reach an optimal configuration.

Figure 3: Sample tree diagram

Table 15-1 compares the characteristics of NDPS printers and queue printers.

Table 1 Queue-Based Printers versus NDPS Printers

When NetWare 5 is installed, NDPS v2.0 is included as part of the typical installation. If, however, NDPS was not installed at the server’s installation, it can be added later since the NDS schema is extended to accept NDPS objects whether the server has NDPS installed on it or not. In order to add NDPS later follow these steps:

1. Map a drive to the root of the SYS: volume on the target NetWare 5 server.
2. Access the NetWare 5 CD-ROM.
3. Copy the CD-ROM’s directory of PRODUCTS\NDPS to the root of the SYS: volume.
4. Unzip each of the ZIP files in the RESDIR directory that was copied to the SYS: volume.

Deciding which gateways to use in the NDPS design is one step in the strategy for implementation. Third-party gateways are a good option for the printers that they support. When NDPS-embedded printers are available, the gateways that are used with them will provide the best access. The protocols that the gateways support will make the final determination as to whether they can be implemented in your environment. For example, if the gateway supports only IP, and the environment is IPX, then that gateway would not work in the environment and another should be selected.

When a pure IP gateway is required, and the third-party gateway does not work in an IP environment, then the Novell gateway can be used and configured to communicate with the printer using LPR (Line Printer Remote protocol). This, in turn, requires the printer be configured to communicate using the same protocol.

The following is the strategy to use when deploying NDPS:

1. Design the NDPS printing system.
2. Migrate servers first, since NDPS components and print servers can exist on the same server simultaneously.
3. Create NDPS components using the NetWare Administrator
4. Set up the NDPS printer agents in the NDPS Manager to retrieve prints from print queues as well as service NDPS printers (see Figure 15-4).
5. Gradually migrate end users in printer-sharing workgroups to have the NDPS client software.
6. Change the users’ setup to print directly to NDPS printers. Set up users who require DOS applications to utilize both queues and NDPS.
7. Remove the legacy printer and Print Server objects that are no longer used. Retain any queues needed for DOS applications.
8. Remove login script CAPTURE statements, as needed.
9. Add or move brokers and other NDPS components throughout the NDS tree to optimize the design.

Figure 4: Using the NDPS printer agent and queues during transition

A public access printer is one to which any user may send print jobs. Public access printers are not associated with an NDS Printer object. Controlled access printers do have an associated Printer object and can take advantage of NDS security. In order to create a controlled access printer, an NDPS broker and NDPS manager must be installed and active.

1. In NetWare administrator, navigate to a container that holds the NDPS Manager object.
2. Double-click the NDPS Manager.
3. Click the Printer Agent List button.
4. Click New.
5. Type a name in the NDPS Printer Name field, select the gateway type, and click OK.
6. Select the printer type that matches the printer, or the nearest equivalent, and the port handler.
7. Select the printer driver for each desktop operating system on the network.
8. Click Continue and the printer agent will appear in the Printer Agent window. Click OK to save the changes and close the Details of the NDPS Manager.

Legacy printing components offered printing services by linking printers to print queues, and print queues to print servers. Print servers run on NetWare servers and manage the print jobs. Queues are file storage areas on the server where print jobs are temporarily stored before being processed by the printer. NDPS combines the components into a printer agent. Users are able to send print jobs directly to NDPS printers.

NDPS does not require queues, but is backwards compatible with queue-based printing. Implementing NDPS requires no disruption to the current printing configuration on the network because the two types of systems can exist and be used simultaneously.

It is possible to print through NDPS to an existing queue, which enables access to systems that require a print queue. NDPS can service existing print queues, so client software does not have to be updated before the server components are installed.

The flexibility and coexistence of queue-based and NDPS printing components enables several migration scenarios.

If implementing NetWare 5 and NDPS in an existing NetWare 3.x environment, and if there is no need for queue-based printing, then the migration can be accomplished fairly easily. In a small network with few printers to migrate, it is just as easy to implement NDPS as it is to implement an entirely new system. In a large network, or in one that uses a complex printing design, the Novell Upgrade Wizard (bundled with NetWare 5 or downloadable from http://www.novell.com) can migrate the printers from the old bindery system to the new NDS tree.

When implementing NetWare 5 and NDPS in an existing NetWare 4.x queue-based printing system, the simplest way to migrate printers to NDPS is to use a gateway. NetWare 5 ships with HP and Xerox gateways, as well as the Novell gateway. If there is no applicable third-party gateway, then the Novell NDPS gateway is a good option.

When implementing NetWare 5 and NDPS on a new network, or one that does not include any Novell NetWare servers, NDPS can be implemented as the primary printing solution.

Migration is the process of changing from legacy queue-based printing to NDPS printing. Standard queue-based printing is shown in Figure 15-5. There are three types of printing setups common to the legacy system:

1. Server-attached printers: workstations send print jobs to the print queue, which forwards them through the print server (a server running PSERVER.NLM) to the server running NPRINTER.NLM and attached printer.
2. Workstation-attached printers: workstations send print jobs to the print queue, which forwards it through the print server to the workstation that is running NPRINTER.EXE and attached printer.
3. Network-attached printers: workstations send print jobs to the print queue, which is polled by the network-attached printer running in queue-server mode.

Figure 5: Legacy queue-based printing setup

In any of these three configurations, a gateway can be used to begin the migration to NDPS (see Figure 15-6). The strategy for each type of printer is somewhat different.

Figure 6: NDPS gateway used in migration

After the gateway is installed, server-attached printers must have an NDPS manager installed directly on the server to manage the local printers. The printer agent and gateway are installed and the clients updated so that the clients can pass print jobs through to the server-attached printer.

Workstation-attached printers will be running NPRINTER.EXE at first and may continue in that mode. Alternatively, they may be configured as LPR printers running over IP.

For network-attached printers, the third-party gateway is the best option. If the Novell gateway is the only option, then the protocol running on the network should determine how the printer should be configured. The options are either as an LPR printer over IP, or an RP printer over IPX.

When making any change on a network, a change control process should be followed. Change control is meant to manage any negative affects that changes can have on the network so that they are minimized. One of the major steps in change control is the test plan.

Since both legacy printing components and NDPS components can coexist in the network, there can be a level of redundancy or "backout" available. That is, if the tests are unsuccessful, the old printing environment is easily restored.

It is recommended that you use a lab or test environment whenever possible. This prevents confusion by end users when printers suddenly become unavailable. In the lab environment, testing should be done on the following components:

• Client software: test that the workstation is functional after the upgrade to NDPS. The operating system functions and standard applications should be tested for their ability to open, save, print, and close documents or other applicable files.
• Server software: test that the server is functional after the upgrade to NDPS. Servers should be tested in their standard configuration, with and without the legacy printing components. The standard functionality of the servers should be tested. If the server is used as a mail server as well as print server, both mail and printing components should be verified.
• Printing functionality: test the printers with the native third-party gateways, and if there is any problem, also test them with the Novell gateway. The printer drivers should be selected for each workstation operating system used on the network. Test the automatic download and use of the drivers that are set up, and test for the optimal drivers for the network environment.

When you no longer need to maintain a redundant or "backout" printing system, the old printer components can be removed. The first components to remove are the print servers. Rather than remove their NDS objects, the servers that were acting as print servers should no longer have PSERVER.NLM loaded. Since it is likely that the PSERVER.NLM load line was automated, the administrator will likely have to remove the LOAD PSERVER.NLM <print server name> from the AUTOEXEC.NCF.

It is recommended that you do not remove the print servers from NDS for a few weeks to verify that no one needs them. However, once it is fairly certain that no one needs the print server components, they can be deleted from NDS. At the same time, the printers can be deleted from NDS.

Print queues can still be used in the NDPS environment. For that reason, care should be taken before removing them completely. So, rather than remove the print queue, it can be disabled through its NDS properties first. To disable a print queue, double-click the Print Queue NDS object in NDS and de-select the Operator flag that states "Allow Users to Submit Print Jobs." After a period of time, such as one or two weeks, if the print queue is not needed, delete it from the NDS tree (see Figure 15-7).

Print queues use a directory on the file server as temporary storage for the print jobs. These directories, which are subdirectories of the QUEUES directory in the volume to which the print queue has been assigned, will be removed automatically when the print queue object is deleted.

Figure 7: Disabling a print queue

Novell Distributed Printing Services (NDPS) are a new printing function under NetWare 5 that increase the manageability and capabilities of NetWare print services.

NDPS implementation requires that both client software and server printing components be upgraded or migrated. The client software must be upgraded to the NetWare client that comes with NetWare 5 or a later version that supports NDPS.

The upgrade includes a design component where the new system is considered from a physical topology perspective as well as from an NDS tree perspective. Both the physical location of printers, the security requirements, and the logical placement of their components contribute to the design of the NDPS printing system.

NDS offers three levels of security: users, operators, and managers. The users of an NDS printer can send print jobs to it. The operators are able to access the administrative options for the NDPS printer. Managers have full access to the NDPS printer.

The NDPS broker uses a default system to determine when a new broker is needed. When an NDPS manager is created, the system checks all NDPS brokers until one is found that is within three hops of the server that the installer has Supervisor rights to. If it is not found, NDPS installation creates a new broker. If the default system does not create a broker when one is needed, then one should be manually created and used.

The upgrade process should start with the creation of server printing components. That would include creating the NDPS brokers, NDPS managers, and NDPS printers.

The current printing configuration is used to determine the final configuration of NDPS printing components. The current printing configuration will reveal the need for which types of gateways and printing configuration will be needed.

NDPS printing components are compatible with legacy print-queue-based components. This means that during migration, the legacy components can remain in place until they are removed.

There are three types of printers that can be migrated:

1. Server-attached printers
2. Workstation-attached printers
3. Network-attached printers

The migration for each printer will depend on the protocols in use on the network, the gateways available for the printer type, and the security requirements.

Printing components that are eligible for migration must be tested in a non-production environment prior to implementation. All components—server, workstation, and printer—should be tested in a lab environment for functionality and impact to the existing environment. Eventually, legacy Print Server, Printer, and Print Queue objects should be removed from NDS. Before removing the components, the print servers and print queues can be disabled in case they need to be reinstated on the legacy environment.

• Novell’s Distributed Printing Services (NDPS) was created in response to the need to simplify printer management, and reduce printing costs.
• In any network system upgrade, one of the first tasks to perform is planning the new system.
• Security and management of NDPS components is handled in the NetWare Administrator because the NDPS components are integrated in NDS.
• Like any object in the NDS tree, the NDPS printers can be made available to all users, or can be locked down so they are available to a select group.
• The NDPS Manager makes printer agents available from a NetWare 5 server.
• Client workstations must have their NetWare client software upgraded to the NetWare 5 client in order to print to NDPS printers.
• In determining the location of brokers, printers, servers, workstation clients, and routers, the designer should have a written record of the existing network resources and components.
• When NetWare 5 is installed, NDPS v2.0 is included as part of the typical installation.
• A public access printer is one to which any user may send print jobs. Public access printers are not associated with an NDS Printer object.
• Print servers run on NetWare servers and manage the print jobs.
• Queues are file storage areas on the server where print jobs are temporarily stored before being processed by the printer.
• NDPS combines the components into a printer agent.
• An NDPS gateway is a software component that allows NetWare NDPS clients to print to non-NDPS-aware printers.
• Change control is meant to manage any negative affects that changes can have on the network so that they are minimized.