Auditting a netware print queue?
Hi guys.
I have a printer running on an external JetDirect 500x box hooked to a HP 4200 printer (3 trays). I have a queue setup on a Netware 5 server and then attached that queue to the JetDirect box. Here's the problem:
The printer is in an open area and for some reason sensitive data is being printed to the printer where:
A. it has no business going
B. is printed when no one is at the station near the printer
These reports print out of a specific system, so I had the analyst responsible for that system check who printed the reports. That analyst flagged a specific user as printing the reports. I spoke to and remote controlled the computer of the suspect user, but there is no way that user printed to this printer, because it isn't even installed on their system and they do not have rights to install a printer. The analyst claims the only way those types of reports are printed is from printing from that specific program directly to a locally installed printer on a computer.
We installed PCOUNTER a few months ago to audit and clean up old Netware print queues and it is now past it's shareware trial period, so I cannot use that. There's also a vendor machine that is using the queue (surprisingly, it's made by the same company of the program, but the analyst claims there is no way the report is coming from the vendor machine), so I cannot simply rename the queue to something else. And, do to the current constraints of another printing system, the queue must be left on the Netware server.
Now, I can connect to the Netware queue from my Windows 2000 box and watch print jobs come and go, but obviously I cannot do this all day. I'm thinking if these reports print on a certain night I can have them turn off the printer when they leave for the day which will freeze all print jobs in the print queue until the next morning until they turn the printer on. Then I could look at the print jobs and then have them fire the printer up to see if any of the "bad reports" come out. What would be nice is to have a Windows 2000 utility to monitor a Netware queue. And have this utility be free. :o)
We do have a Windows 2003 print server cluster and do plan to move from Netware slowly, but reports for another system come through our Netware SAA gateway and we haven't completely setup our Microsoft HIS gateway to replace the Netware SAA gateway, so for now this printer MUST use Netware! We don't want to spend several hundred dollars for PCOUNTER just for this one case of auditting.
Thanks.
I have a printer running on an external JetDirect 500x box hooked to a HP 4200 printer (3 trays). I have a queue setup on a Netware 5 server and then attached that queue to the JetDirect box. Here's the problem:
The printer is in an open area and for some reason sensitive data is being printed to the printer where:
A. it has no business going
B. is printed when no one is at the station near the printer
These reports print out of a specific system, so I had the analyst responsible for that system check who printed the reports. That analyst flagged a specific user as printing the reports. I spoke to and remote controlled the computer of the suspect user, but there is no way that user printed to this printer, because it isn't even installed on their system and they do not have rights to install a printer. The analyst claims the only way those types of reports are printed is from printing from that specific program directly to a locally installed printer on a computer.
We installed PCOUNTER a few months ago to audit and clean up old Netware print queues and it is now past it's shareware trial period, so I cannot use that. There's also a vendor machine that is using the queue (surprisingly, it's made by the same company of the program, but the analyst claims there is no way the report is coming from the vendor machine), so I cannot simply rename the queue to something else. And, do to the current constraints of another printing system, the queue must be left on the Netware server.
Now, I can connect to the Netware queue from my Windows 2000 box and watch print jobs come and go, but obviously I cannot do this all day. I'm thinking if these reports print on a certain night I can have them turn off the printer when they leave for the day which will freeze all print jobs in the print queue until the next morning until they turn the printer on. Then I could look at the print jobs and then have them fire the printer up to see if any of the "bad reports" come out. What would be nice is to have a Windows 2000 utility to monitor a Netware queue. And have this utility be free. :o)
We do have a Windows 2003 print server cluster and do plan to move from Netware slowly, but reports for another system come through our Netware SAA gateway and we haven't completely setup our Microsoft HIS gateway to replace the Netware SAA gateway, so for now this printer MUST use Netware! We don't want to spend several hundred dollars for PCOUNTER just for this one case of auditting.
Thanks.
ASKER
Unforunately, we have to grant the Everyone group the rights to use the queue. Trying to set up permissions for each user of the queue would be an adminstrative nightmare. I asked our local CNE if there is a Deny permission like in Windows 2000/2003 and he said no. If this queue was on a 2000/2003 box, I could use the deny permission and auditting and it would be case closed, however, I am not that lucky. =(
There is a sneaky way to do it.
Print queues are just directories on a server volume; anyone who has rights to use a queue, has rights to write data to the queue directory. Now, you could use CONSOLE1 or iManager (not NWADMIN) to find out the location / name of the queue directory, then explicity reject the user's rights to the queue directory -- effectively shutting them out of the print queue.
Print queues are just directories on a server volume; anyone who has rights to use a queue, has rights to write data to the queue directory. Now, you could use CONSOLE1 or iManager (not NWADMIN) to find out the location / name of the queue directory, then explicity reject the user's rights to the queue directory -- effectively shutting them out of the print queue.
Do you perhaps have more than one queue being serviced by that printer? Since you're making the (regrettable) move away from NetWare, you likely are not using NDPS/iPrint, but are still using queue-based printing. Locally-installed printer objects in Windows clients are usually assigned to a print queue as its port, and queue-based printing can have more than one queue serviced by a printer, as well has having more than one printer servicing a queue.
Another possibility is that perhaps the reports are coming from a local printer object that is bypassing the NetWare queue. Since you are moving away from NetWare, and are going to Win2K3 on the back-end, you likely have all of your printers set up to take both queue-based printing (probably over IPX) and to accept IP-based print traffic from your Win2K3 servers. If that is the case, and assuming that you are using network-based print servers like HP JetDirect, your problem user could be printing directly to the IP address of the printer and not hitting the queue at all, so monitoring the NetWare queue may be a useless exercise.
If nobody is as of yet supposed to print to that printer other than by NetWare at this time, then turn off all other protocols in the print server. That is a quick-and-dirty way to eliminate bypassing the queue as a possibility, and if the problem print suddenly stops, will throw up the red flag for you.
Another possibility is that perhaps the reports are coming from a local printer object that is bypassing the NetWare queue. Since you are moving away from NetWare, and are going to Win2K3 on the back-end, you likely have all of your printers set up to take both queue-based printing (probably over IPX) and to accept IP-based print traffic from your Win2K3 servers. If that is the case, and assuming that you are using network-based print servers like HP JetDirect, your problem user could be printing directly to the IP address of the printer and not hitting the queue at all, so monitoring the NetWare queue may be a useless exercise.
If nobody is as of yet supposed to print to that printer other than by NetWare at this time, then turn off all other protocols in the print server. That is a quick-and-dirty way to eliminate bypassing the queue as a possibility, and if the problem print suddenly stops, will throw up the red flag for you.
ASKER
Shineon: Alas, there are many printing systems that go to this printer. One is AnyQueue that prints to the printer directly via IP, so I must leave IP enabled. And we are using IPX on the Netware server, so IPX has to stay as well. What's weird is that there are only about 4 or 5 computers setup to use this printer. I'm suspecting that these reports are truly coming from the vendor print routing machine even though the analyst says that is not possible. However, I need some proof of this. :o)
There is one queue per port on the JetDirect: one for the laser and one for a label printer.
BudDurland: how exactly would I do that? I cannot find a specific "deny permission" to lock anyone out....unless you are saying that I add the user with no rights? Would that lock the user out?
There is one queue per port on the JetDirect: one for the laser and one for a label printer.
BudDurland: how exactly would I do that? I cannot find a specific "deny permission" to lock anyone out....unless you are saying that I add the user with no rights? Would that lock the user out?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Always get the facts straight! The person who opened the ticket did not specify the right printer. The users indeed did have access to the other printer, so I went on the Citrix server where they login and used deny permissions for all of them on that printer (the wrong printer was NOT defined on the Citrix server).
I won't get into Netware arguments here, however, I have not been impressed by Netware in our environment. I'm sure it's probably the way it was setup before I ever came, but after replacing a few Netware with Windows NT servers, my headaches have gotten less and less.
I won't get into Netware arguments here, however, I have not been impressed by Netware in our environment. I'm sure it's probably the way it was setup before I ever came, but after replacing a few Netware with Windows NT servers, my headaches have gotten less and less.
realllllly?
http://www.geocities.com/novellrocks/365.jpg
you have to copy the above URL into an empty browser, Geocities does not allow redirections.
I'm still looking for a Windows box with 1/2 that uptime running the same services on the same hardware.
now, I've built up Windows (since 3.51), NetWare (since 4.11, admin'd 3.11), OS/2 Warp 4 and even dinked with Linux. I've admin'd Solaris (SPARC) and OpenVMS systems (Alpha). Played with BSD.
Still have yet to find an OS like NetWare.
I think it was the schmuck before you who gave you a bad taste for NetWare.
http://www.geocities.com/novellrocks/365.jpg
you have to copy the above URL into an empty browser, Geocities does not allow redirections.
I'm still looking for a Windows box with 1/2 that uptime running the same services on the same hardware.
now, I've built up Windows (since 3.51), NetWare (since 4.11, admin'd 3.11), OS/2 Warp 4 and even dinked with Linux. I've admin'd Solaris (SPARC) and OpenVMS systems (Alpha). Played with BSD.
Still have yet to find an OS like NetWare.
I think it was the schmuck before you who gave you a bad taste for NetWare.
ASKER
We upgraded to Netware 5.1 (from 4.11) about a year ago and everything seemed to go down hill. We had constant utilization problems on one Netware server which bought all the users to a screeching halt (it's a file and printer server and also a authentication server). We added a second processor and that fixed that problem. Then we started having utilization issues on another Netware server (another file/printer/authenication
Again, YMMV, but Netware has left a bad taste in my mouth.
Incidentally, we have a voicemail server running on OS/2 Warp from 1996 and that thing has uptimes of several years without a reboot: very reliable.
Again, YMMV, but Netware has left a bad taste in my mouth.
Incidentally, we have a voicemail server running on OS/2 Warp from 1996 and that thing has uptimes of several years without a reboot: very reliable.
Sounds like something wasn't done properly as part of your migration. The migration from 4.11 to 5.x used to be very touchy, especially with the different peripheral architechture. If the hardware wasn't prepped first, you're going to have problems.
Novell also had some problems with early service packs for 5.1 (as did Microsoft with NT4...) If you don't keep up with the fixes, problems will happen (as with NT4...) so it's really all from the perspective you bring to the process. If you are in love with Windows and afraid of anything "not Windows" then you will have the same bad experience as a red-box fanatic that hates Bill G's guts would with a neglected Windows server.
Novell also had some problems with early service packs for 5.1 (as did Microsoft with NT4...) If you don't keep up with the fixes, problems will happen (as with NT4...) so it's really all from the perspective you bring to the process. If you are in love with Windows and afraid of anything "not Windows" then you will have the same bad experience as a red-box fanatic that hates Bill G's guts would with a neglected Windows server.
Aleinss,
'Incidentally, we have a voicemail server running on OS/2 Warp from 1996 and that thing has uptimes of several years without a reboot: very reliable.'
Repartee? Us too. Great OS - runs and runs and runs. Unfortunately, ActiveVoice no longer sells the OS/2 variant of Repartee and has shifted to Linux.
'Granted, it's likely due to a memory leak due to poor programming, but the replacement Windows 2000 server with the same software has produced no problems!'
Hold on a second, you are saying the APPLICATION is the problem and yet you blame NetWare? Dude! (or dudette) - that is TOTALLY unfair! I've seen applications HOSE Windows servers. I DO NOT blame Windows - I blame the application. Case in point - MOST Windows desktop applications (including Office 2000) don't work properly on Windows 2000/XP if you are using Restricted Users. It's not the fault of Microsoft (except for Office 2000) but a fault of the programmers who had the misfortune to think that EVERYONE would ALWAYS be administrators on the desktop. You don't see me switching to Linux because Windows left a bad taste in my mouth. Put blame where blame is due - on the application developers.
Unlike Windows, which allows you to get away with murder, NetWare NLM's require that you actually write your code properly. Take a look at IE - pages that are written improperly work on IE but won't render on Netscape.
'Incidentally, we have a voicemail server running on OS/2 Warp from 1996 and that thing has uptimes of several years without a reboot: very reliable.'
Repartee? Us too. Great OS - runs and runs and runs. Unfortunately, ActiveVoice no longer sells the OS/2 variant of Repartee and has shifted to Linux.
'Granted, it's likely due to a memory leak due to poor programming, but the replacement Windows 2000 server with the same software has produced no problems!'
Hold on a second, you are saying the APPLICATION is the problem and yet you blame NetWare? Dude! (or dudette) - that is TOTALLY unfair! I've seen applications HOSE Windows servers. I DO NOT blame Windows - I blame the application. Case in point - MOST Windows desktop applications (including Office 2000) don't work properly on Windows 2000/XP if you are using Restricted Users. It's not the fault of Microsoft (except for Office 2000) but a fault of the programmers who had the misfortune to think that EVERYONE would ALWAYS be administrators on the desktop. You don't see me switching to Linux because Windows left a bad taste in my mouth. Put blame where blame is due - on the application developers.
Unlike Windows, which allows you to get away with murder, NetWare NLM's require that you actually write your code properly. Take a look at IE - pages that are written improperly work on IE but won't render on Netscape.
ASKER
Yes, it's a Repartee and it never has given us problems (ok, one: it had a problem with the OS/2 Arcserve client, but not sure if that's the server or the application)
Novell doesn't have good tools to troubleshoot problems. Another reason for the decision is licensing fees: we have to first pay off Novell and then pay off Microsoft. It makes sense from a cost standpoint alone to move to one platform. Also, with less different systems to support means less administrative overhead.
We are moving away from Windows 95/98 to Windows 2000 and I fully understand the file/registry permission problems you speak. However, when I replace a troublesome Netware server with a trouble fee Windows server, I am hard pressed to blame the programmer, especially since it's the same exact company, but just running the Windows version.
Novell doesn't have good tools to troubleshoot problems. Another reason for the decision is licensing fees: we have to first pay off Novell and then pay off Microsoft. It makes sense from a cost standpoint alone to move to one platform. Also, with less different systems to support means less administrative overhead.
We are moving away from Windows 95/98 to Windows 2000 and I fully understand the file/registry permission problems you speak. However, when I replace a troublesome Netware server with a trouble fee Windows server, I am hard pressed to blame the programmer, especially since it's the same exact company, but just running the Windows version.
Novell doesn't have good troubleshooting tools? Licensing fees are cheaper with all Micro$oft? Less administrative overhead with all Microsoft?
I have a bridge in Brooklyn I'm looking to unload, cheap. Interested?
I have a bridge in Brooklyn I'm looking to unload, cheap. Interested?
Register PCOUNTER, although I agree that the pricing is pretty steep.
Put the queue on hold over night. Use NWADMIN to look at the queue contents in the morning
Revoke the suspect user's right to use the queue