Yea at the moment this project only works for local printers (as you understand, networkprinters on remote sites also counts as local) 
I'm actually heading for usage tracking and report errors on the fly.-DoXiD
Cool. Now for the errors, are you looking for communication errors (getting the job there), machine errors (printer out of something /jammed), or both?
These days (with direct IP printing so common/cheap) print servers seem to only get used for user usage tracking scenario. However most of the (driver/spool interrogation level) ones I've tested have great difficulty tracking duplexed pages, multiple copies, and the larger paper sizes (like 11x17) that can make a big difference when calculating someones actual usage.
Then there are the printers that locally store the by user usage tracking info... Which is great if you want to pole for it constantly to avoid missing something (not recommended) because they dump the logs when restarted.
Only thing I found that will guarantee-ably accurately catch everything sent to a printer is Capella Megatrack. Which is an accessory firmware add-on that sits on the printer and reports back to a SQL db. At the time I had investigated the options available, including a scratch write ... but decided the best thing for the company was to recommend the client go with Capella (which ain't cheap). The deployment has been running just fine for the last (almost) 5 years.
Please understand, I'm not trying to talk you out of the project. I really and truly hope you succeed ... I'm just sharing the fact that I couldn't quite pull it off.
This is mostly developed due to the lack of information given by windows when customers call in and say that their printouts never show up in the printer, this way i can track where, why and when
-DoXiD
Yeah, that can get "fun" at times. The GUI say the job is gone/there, but the wire activity doesn't quite actually agree, and the printer isn't responding at all. I hate when that happens.
Atm I've bumped into some problems regarding the network printers, seems like they don't spool documents as they should when they come from a second "printer" server running a software called "Streamserve" :/-DoXiD
I'm not familiar with that one, but I have seen some Novell print servers that would convert the print job on-the-fly from RAW/9100 (what you'd expect) to LPR/LPD 515 ... Which strangely was the root cause for many rather interesting failures. Like a 500 page job that kept reprinting the first 150 pages in a loop until the machine ran out of paper.
Yours is more of a scanner then a job-information tool o guess even if yours had a few information features such as printer toner levels etc. Have you developed yours entirely from scratch cause it looks like you were surprised that "web access" was in your feature list?
What's it written in? C# or .NET?-DoXiD
Yes, Page Countster's primary function is to find and list all of the printers on a network and collect page count and tracking information for billing purposes. I'm not sure what you're referring to regarding the "surprised that "web access" was in your feature list" part. But if you can link me to the statement I'll have a better chance of answering.
At any rate, yes it was a from scratch project, that occupied a great deal of my time for about 3 years. It is written in pure Win32 API C++ (no .NET/MFC/run-time requirement nonsense) using MSVS2005.