Environment
Novell iPrint for Linux
Novell iPrint for NetWare
Novell iPrint for NetWare
Situation
This TID answers the question of how many Brokers / Driver Stores
should be implemented. In short, Novell strongly recommends
only one Broker or Driver Store per Tree.
Resolution
Definitions:
Broker = A service hosted on a NetWare server that holds a repository of printer drivers that can be used by Printer Agents.
Driver Store = A service hosted on a Linux server that holds a repository of printer drivers that can be used by Printer Agents.
RESDIR = An abbreviated name for Resource Directory. The name of a directory hosted on NetWare and Linux where printer drivers are stored.
Print Manager = A service hosted on NetWare or Linux servers that maintains a database of Printer Agents.
Print Manager CSV = A text file containing Printer Agent information for that Print Manager's database.
Background Information:
From the beginning of NDPS until 2005, Novell recommended that a Broker exist for every Print Manager. This recommendation ensured that the printer driver hosted on the network was as close to the end user as possible. The more Brokers spread across the network, the increased chance that a user would have a driver nearby. Having many Brokers would also allows for fault tolerance. If one Broker went down, and another Broker was hosting print drivers in common with the downed Broker, then the NDPS or iPrint client could find the driver from the available Broker.
However, there are significant problems with having multiple Brokers.
Problem 1: Management overhead
If a driver is commonly shared by multiple Brokers, administrators need to replicate their RESDIR, or upload the same driver to each Broker.
Problem 2: Confusion
When associating a driver to a Printer Agent, you don't always know which Broker is providing that driver. The Print Manager uses an algorithm that decides which Broker should be used. But, if the administrator's intended Broker is not available at the time the driver is associated to the Printer Agent, or another condition is changed that would affect the results of the algorithm, then another Broker will be used. This process of finding a Broker is hidden from the administrator. Therefore, it is possible to have a list of Printer Agents on a Print Manager unknowingly point to several different Brokers to obtain their drivers.
To review the list of Brokers being used by your Print Manager, see the driver column in the padbtxt.csv file. The driver column will not list the Broker names, but it will list server and/or volume names hosting the printer drivers. Ideally, the same server and/or volume will be listed for all Printer Agents within a Print Manager's CSV. The CSV is located in [VOL]\NDPS\[someHexValue].PSM\padbtxt.csv. If you have multiple .PSM directories, then you can determine the correct one by following these steps.
a. Go to the NDPS Manager screen on the server console
b. Hit ENTER on NDPS Manager Status and Control
c. Hit ENTER on Database Options
d. Hit ENTER on Examine Database
e. Make note of the database location
f. The padbtxt.csv will be in that database location directory
The location of the padbtxt.csv for OES1 is straight forward on Linux: /var/opt/novell/iprint/[PrintManagerName].[OU].[O].psm/padbtxt.csv. OES2 uses a different text format: padbtxt.xml.
Novell's recommendation:
NOTE 1: All of the below information also applies to Driver Stores
NOTE 2: This recommendation does not apply to those installing Printer Agents with the NDPS client.
Since 2005, a significant change has been implemented in the way printer drivers are made available to workstations running the iPrint client. The first time a printer is requested to be installed by an iPrint client, the driver is copied to the Print Manager. A copy of the printer driver is placed on the server that is hosting the Print Manager. Subsequent requests by iPrint clients for the driver (requests initiated by an iPrint printer installation) will not communicate with the Broker. Instead, the driver is provided by the Print Manager's copy. You can view the Print Manager's repository of drivers at:
NetWare: [VOL]\ndps\ipp\drivers
Linux: /var/opt/novell/iprint/mod_ipp/drivers/
Within the drivers directory, you will see a subdirectory for each copy of the driver. Within each subdirectory, you will find a file named ndps.a. If you rename that file to ndps.zip and open the zip file, you will see all the files expected for a printer driver. (NOTE: If you go through that renaming exercise, be sure to rename the file back to it's original name.)
Changes to the the Broker's RESDIR copy synchronize with the Printer Manager's copy. For example, if you remove or update a driver in the Broker's RESDIR, that change will be pushed to the Print Manager's copy.
This new architecture of maintaining a copy of the driver at the Print Manager changes Novell's previous recommendation. Novell now recommends only one Broker per tree. Having only one Broker per tree has important benefits.
Benefit 1: Less Management
With one central Broker you need to upload your printer drivers to only one repository. There is no need to synchronize RESDIR's across multiple Brokers.
Benefit 2: Fault Tolerance
If your Broker service goes down, end users won't know it. They will still be able to install printers because the driver is provided by the Print Manager's copy.
Benefit 3: Driver proximity to users
The printer drivers will be as close to the end user as the Print Manager is close to the end user. While most drivers are under 1 MB, some can be much larger. Having drivers close to end users decreases network traffic and increases iPrint printer installation speeds.
Benefit 4: Simplicity
With only one Broker, there is no question which Broker is providing the driver for the Printer Agents.
Consolidation:
The recommendation to have only one Broker or Driver Store works well when setting up a new Print Manager / Broker environment. However, there are significant problems to overcome if you decide to consolidate existing Brokers/Driver Stores.
Consolidation Problem 1: Printer Driver Profiles
As explained above, the install of iPrint printers looks to the Print Manager's copy (mod_ipp cache) to retrieve the printer driver. If the Broker or Driver Store is decommissioned, the iPrint printer will continue to point to that unavailable Broker. That scenario does not pose a problem because the iPrint printer will obtain the driver from the mod_ipp cache. However, when a Printer Driver Profile is associated to the iPrint printer, the printer will fail to install. The Printer Driver Profile does not point to the mod_ipp cache, but rather the Broker or Driver Store path (resdir).
Consolidation Problem 2: Incorrect UNC paths
As explained above, you can view the UNC path to the associated printer driver in the padbtxt.csv for NetWare and OES1 and the padbtxt.xml for OES2. After consolidating Brokers or Driver Stores, printer agents will continue to point to the old resource. This will not present any iPrint printer install problems, but will result in errors if using the padbtxt.csv to regenerate the Print Manager database (psmdb.dat) using PAGen.exe. Similarly, errors will be returned if using iprntman --xml-import to regenerate the Linux Print Manager database.
Consolidation Problem 3: Winsock Time Errors
If the centralized Broker or Driver Store communicates over a slow network link to the Print Manager, end users may be presented with "Winsock 10060 Connection has timed out" errors when attempting to install iPrint printers. This time out is a result of the printer driver not copying from the resdir to the mod_ipp cache within the alloted time. If the printer driver can be copied at least once from the resdir to the mod_ipp cache, then this problem will not occur for subsequent install attempts because the driver must be copied only once.
To workaround the Winsock error in this scenario, manually copy the driver assigned to that Printer Agent from the Driver Store's resdir to the Print Manager's mod_ipp.
resdir: /var/opt/novell/iprint/resdir/
mod_ipp: /var/opt/novell/iprint/mod_ipp/drivers/
Broker = A service hosted on a NetWare server that holds a repository of printer drivers that can be used by Printer Agents.
Driver Store = A service hosted on a Linux server that holds a repository of printer drivers that can be used by Printer Agents.
RESDIR = An abbreviated name for Resource Directory. The name of a directory hosted on NetWare and Linux where printer drivers are stored.
Print Manager = A service hosted on NetWare or Linux servers that maintains a database of Printer Agents.
Print Manager CSV = A text file containing Printer Agent information for that Print Manager's database.
Background Information:
From the beginning of NDPS until 2005, Novell recommended that a Broker exist for every Print Manager. This recommendation ensured that the printer driver hosted on the network was as close to the end user as possible. The more Brokers spread across the network, the increased chance that a user would have a driver nearby. Having many Brokers would also allows for fault tolerance. If one Broker went down, and another Broker was hosting print drivers in common with the downed Broker, then the NDPS or iPrint client could find the driver from the available Broker.
However, there are significant problems with having multiple Brokers.
Problem 1: Management overhead
If a driver is commonly shared by multiple Brokers, administrators need to replicate their RESDIR, or upload the same driver to each Broker.
Problem 2: Confusion
When associating a driver to a Printer Agent, you don't always know which Broker is providing that driver. The Print Manager uses an algorithm that decides which Broker should be used. But, if the administrator's intended Broker is not available at the time the driver is associated to the Printer Agent, or another condition is changed that would affect the results of the algorithm, then another Broker will be used. This process of finding a Broker is hidden from the administrator. Therefore, it is possible to have a list of Printer Agents on a Print Manager unknowingly point to several different Brokers to obtain their drivers.
To review the list of Brokers being used by your Print Manager, see the driver column in the padbtxt.csv file. The driver column will not list the Broker names, but it will list server and/or volume names hosting the printer drivers. Ideally, the same server and/or volume will be listed for all Printer Agents within a Print Manager's CSV. The CSV is located in [VOL]\NDPS\[someHexValue].PSM\padbtxt.csv. If you have multiple .PSM directories, then you can determine the correct one by following these steps.
a. Go to the NDPS Manager screen on the server console
b. Hit ENTER on NDPS Manager Status and Control
c. Hit ENTER on Database Options
d. Hit ENTER on Examine Database
e. Make note of the database location
f. The padbtxt.csv will be in that database location directory
The location of the padbtxt.csv for OES1 is straight forward on Linux: /var/opt/novell/iprint/[PrintManagerName].[OU].[O].psm/padbtxt.csv. OES2 uses a different text format: padbtxt.xml.
Novell's recommendation:
NOTE 1: All of the below information also applies to Driver Stores
NOTE 2: This recommendation does not apply to those installing Printer Agents with the NDPS client.
Since 2005, a significant change has been implemented in the way printer drivers are made available to workstations running the iPrint client. The first time a printer is requested to be installed by an iPrint client, the driver is copied to the Print Manager. A copy of the printer driver is placed on the server that is hosting the Print Manager. Subsequent requests by iPrint clients for the driver (requests initiated by an iPrint printer installation) will not communicate with the Broker. Instead, the driver is provided by the Print Manager's copy. You can view the Print Manager's repository of drivers at:
NetWare: [VOL]\ndps\ipp\drivers
Linux: /var/opt/novell/iprint/mod_ipp/drivers/
Within the drivers directory, you will see a subdirectory for each copy of the driver. Within each subdirectory, you will find a file named ndps.a. If you rename that file to ndps.zip and open the zip file, you will see all the files expected for a printer driver. (NOTE: If you go through that renaming exercise, be sure to rename the file back to it's original name.)
Changes to the the Broker's RESDIR copy synchronize with the Printer Manager's copy. For example, if you remove or update a driver in the Broker's RESDIR, that change will be pushed to the Print Manager's copy.
This new architecture of maintaining a copy of the driver at the Print Manager changes Novell's previous recommendation. Novell now recommends only one Broker per tree. Having only one Broker per tree has important benefits.
Benefit 1: Less Management
With one central Broker you need to upload your printer drivers to only one repository. There is no need to synchronize RESDIR's across multiple Brokers.
Benefit 2: Fault Tolerance
If your Broker service goes down, end users won't know it. They will still be able to install printers because the driver is provided by the Print Manager's copy.
Benefit 3: Driver proximity to users
The printer drivers will be as close to the end user as the Print Manager is close to the end user. While most drivers are under 1 MB, some can be much larger. Having drivers close to end users decreases network traffic and increases iPrint printer installation speeds.
Benefit 4: Simplicity
With only one Broker, there is no question which Broker is providing the driver for the Printer Agents.
Consolidation:
The recommendation to have only one Broker or Driver Store works well when setting up a new Print Manager / Broker environment. However, there are significant problems to overcome if you decide to consolidate existing Brokers/Driver Stores.
Consolidation Problem 1: Printer Driver Profiles
As explained above, the install of iPrint printers looks to the Print Manager's copy (mod_ipp cache) to retrieve the printer driver. If the Broker or Driver Store is decommissioned, the iPrint printer will continue to point to that unavailable Broker. That scenario does not pose a problem because the iPrint printer will obtain the driver from the mod_ipp cache. However, when a Printer Driver Profile is associated to the iPrint printer, the printer will fail to install. The Printer Driver Profile does not point to the mod_ipp cache, but rather the Broker or Driver Store path (resdir).
Consolidation Problem 2: Incorrect UNC paths
As explained above, you can view the UNC path to the associated printer driver in the padbtxt.csv for NetWare and OES1 and the padbtxt.xml for OES2. After consolidating Brokers or Driver Stores, printer agents will continue to point to the old resource. This will not present any iPrint printer install problems, but will result in errors if using the padbtxt.csv to regenerate the Print Manager database (psmdb.dat) using PAGen.exe. Similarly, errors will be returned if using iprntman --xml-import to regenerate the Linux Print Manager database.
Consolidation Problem 3: Winsock Time Errors
If the centralized Broker or Driver Store communicates over a slow network link to the Print Manager, end users may be presented with "Winsock 10060 Connection has timed out" errors when attempting to install iPrint printers. This time out is a result of the printer driver not copying from the resdir to the mod_ipp cache within the alloted time. If the printer driver can be copied at least once from the resdir to the mod_ipp cache, then this problem will not occur for subsequent install attempts because the driver must be copied only once.
To workaround the Winsock error in this scenario, manually copy the driver assigned to that Printer Agent from the Driver Store's resdir to the Print Manager's mod_ipp.
resdir: /var/opt/novell/iprint/resdir/
mod_ipp: /var/opt/novell/iprint/mod_ipp/drivers/