Archived Content: This information is no longer maintained and is provided 'as is' for your convenience.
After upgrading servers holding print queues (host servers) from NetWare 4.10 to NetWare 4.11, users periodically lose the ability to print to queues on specific servers and NWAdmin reports the error "Print queue ID cannot be read. Verify that the queue volume is mounted." when trying to display the queue information. Dismounting and mounting the queue volumes restores printing for a few days, then the problem returns. The problem first occurred in May 1999.
- On Windows 95/98, the printer status shows as "Printer not available" in Control Panel > Printers. If you try to install that printer on any other client, you get "Printer not available" errors. Printers eventually disappear from Control Panel > Printers.
- On Windows NT, the problem occurs when attempting to print or open printers window in the Control Panel. This leads to Dr. Watson and error with spoolss.exe and RpcSs.exe.
- NetWare Administrator (various versions) returns "Print queue cannot be read. Verify that the queue volume ..." error when double clicking a queue object. Subsequently, it does not show all the detail pages of the object.
- It happens on multiple client versions (2.20, 3.1, 4.11a, 4.5, 4.6).
- The servers hosting the queues are dedicated NW 4.11 (NWIP) spool servers who do nothing but host the queues (150 - 250 queues per server). The jobs are then picked up by a remote NWIP 4.11 print server (5.00 NetWare Print Server PTF v1.03 (990317)). Then the jobs go via LPR_GWY to printer boxes (HP, Lexmark) running IP.
- The queue servers hold a replica of the partitions with the queues, but at least the objects are on local servers.
Extent of problem:
- It has been observed on anywhere from a few and up to more than 50% of the queues on a single queue server.
- After the workaround has been performed (dismount/remount the volumes) the queues work for 1-3 days and then start to fail again.
- On the queue server holding the master replica of the "queue"-partition the problem has not yet been observed. Nor has it been observed on "smaller" queue servers which do not handle so many queues.
The communication between the servers running PSERVER.NLM and the servers holding the queue directories seems to fail at the time of the problem. Dismounting and remounting the spool volume seems to restore the communication. The problem does not often happen when the host server has PSERVER.NLM loaded, but it has occurred a few times. The problem only seems to happen under heavy printing load.
The PSERVER.NLM (5-24-99) from NW4SP7.EXE has been tested but did not resolve the problem. The host servers are loading CLIB.NLM v4.11q (6-02-99, I think), but the servers running PSERVER.NLM are using the CLIB from IWSP6 because CLIB 4.11q causes the problem reported in KB 2950880 (SPD 222906) to return.
Latest summary of the problem:
When do the clients experience the problem?
Both NT and 95 clients are able to print to already connected printers in the beginning after the problem has been observed. They have a limited number of DOS clients, which are the first ones to experience the problem. They are just not able to print.
Later they (95/98+NT clients) get:
95 : In the beginning the printer is changing status to "Not available" in control panel > printers, but later on, the printer simply disappears.
NT : The situation is unclear for the first part, but when the printers disappear from the 95 clients, the NT users get Dr. Watson in spoolss.exe and RpcSS.exewhen entering control panel > printers or if trying to print to a queue that is affected by the problem.
Tried deleting and recreating affected print queues, but the new queues were also affected by the problem.
Minor DS inconsistencies and/or FAT errors on the queue volume.
This problem has been reported to Novell engineering.
There are quite a few good suggestions in the summary KB 2942030 (Print queue cannot be read....), but none of them solved the problem in this case.
On one of the servers hosting queues, the solution was to load DSREPAIR.NLM and perform the following in the Advanced options menu
- Check volume objects and trustees
- Repair local DS database with default options
For the remaining queues causing problems, the solution was to run VREPAIR.NLM on the server hosting the queues in question.
Another solution was to dismount and remount the volume(s) hosting the queues. Once the volumes were remounted, printing began working again. However, the problem would usually return in a few days.
Search: Print q id can not can't be read