Recently in printing Category

Printing from ancient history

| 1 Comment
Over the summer we tested a lot of things, one of which was Windows 7 in the computer labs. The other thing was Office 2010 in the labs. We did learn one thing, though.

Word 2010 files printing to an HP LaserJet 9050 with the Microsoft-supplied PCL5 driver yields some straaange page-counts on the printer.

Most people wouldn't care about this, since most people only look at the printer's page-counter once a quarter if that often. We care about it since we use that number for auditing. Students only get so many pages a quarter, and PCounter allows the use of the printer's page-counter as a double-check to driver-counted pages. It'll ding the user the amount of quota for paper that came out of the printer.

We were getting cases where a file with 7 pages would cause the printer to report it had printed 593 pages. Or in one case last week, a 19 page document dinged the user 2239 pages; more paper than the printer can hold. In every case it was a DOCX file that did it, on a printer using the PCL5 driver.

The fix is to use the PCL6 driver, which we're doing now. Historically we've avoided the PCL6 driver for reasons that our lab managers haven't made clear to me. They just don't work right, apparently. There are 'some issues'. Their labs, so I've rolled with it. But we're on PCL6 since that works with Office 2010.

Then I did some digging on PCL5 vs PCL6 and came across the Wikipedia page with the timeline. PCL5c/e, the version we're using, was introduced in 1992. Wowzers. PCL6 was introduced in 1995. I guess 15 years is enough time to get a printer description language right, eh?

We go through paper

We're a University, and you'd expect that in this modern era of ipads replacing textbooks and suchlike that our paper costs would be going down. You'd be wrong. We go through a heck of a lot of paper in a quarter. Spring quarter earlier this year generated 1,899,865 pages of printing, which is actually a bit up from what we did last year. Ouch.

For a nice visual clue to what we go through in a day, here is Monday of this week:
Pages-per-hour for September 27, 2010
41,375 pages is the total for Monday. Monday is also our heaviest printing day. That spike you see between 11am and Noon is regular. We've had the 11am printing peak for years. There is a smaller spike between 1 and 2pm. This time of quarter we don't have any printing going on at 5am, though the closer we get to Finals Week the more dark-o-night printing goes on.


One of the trickier things we're dealing with these days are multi-function-devices. Or in specific, copiers that can email or save-to-server PDF/BMP/JPG/TIFF images of documents. You'd think this would be easy, but no.

On the one hand, we COULD just let these devices email blindly. Which would allow anonymous users to send butt-scans to the University President, a thing we generally try to avoid.

Or we could configure them with a user ID and password to send authenticated SMTP messages, and still butt-scan bomb the University President.

Ideally every one would have a specific login on these devices so there would be a full audit trail. This kind of thing can be done, but there are caveats. Swipe-card systems require all the devices to use the same back-end processor, and probably mean all the devices come from the same company. We can't use our universal login and passwords since that would require a full keyboard on these devices, and that just isn't going to happen any time soon.

The solution we've come up with isn't a good one, but it's still better than banning the enhanced functionality of these devices. Scanning can indeed reduce the amount of paper we push around. We're disabling the butt-scan vulnerability and forcing potential butt-scanners to drop the scans on a specific file-share where they'll have to forward it from a real email account.

I suspect "email my PDF" will be disabled until such time as we get a card-swipe system, or some other way to individually authenticate copier users.

Printing habits

| 3 Comments
Some students are going to be in for a rude, rude surprise real soon. Today alone there is a student who has printed off 210 pages. Looking at their print history, they printed off 100 copies of two specific handouts (in batches of 50), and that's 40% of their entire quota for the quarter. Once they hit the ceiling, they'll have to pay to get more. This is different from last year!

We always got a few students who rammed their head against the 500 page limit within two weeks of quarter start. I'm sure we'll get some this quarter too. There may be heated tempers at the Helpdesk as a result, but thems the breaks.

Quarter start: printing

Today is go-live for the new Microsoft/PCounter based printing system. It hasn't gone off perfectly, but most of the problems so far have been manageable. Also, it's only Monday. The true peak load for printing will be Wednesday between 11:00 and 12:00. Wednesday is when classes start.

So far the big problem is that some of the disk images used for the labs included printers they weren't supposed to, a side effect of how Microsoft does printing. All in all, it's a pretty small thing but it does ruin the clean look. The time between when Summer session stopped and when all the images had to be applied (last Friday) was the same time we get every year, but this year included major changes we haven't seen since we converted from queue-based printing to NDPS printing back around 2002. So yeah, these kinds of QA things can get dropped when under this kind of time pressure, and just plain new environment.

Also, the Library doesn't have their release stations up yet. They'll have them there by the end of the day, but the fact remains that they're on the old system until then. Due to the realities of accounting, each student was given only 50 pages this morning on the old system. Which means that some users are already whacking their heads on the limit. They'll have to go to one of the ATUS labs to print, as they're all on the new system and their quotas are much higher there. If Libraries doesn't have it by tomorrow, something will have to give.

Migrations

| 2 Comments
We'll be getting our hardware early next week. Still no ETA on the storage we need to manage things.

Also, with Server 2008R2 being released on the 14th, that allows us to pick which OS we want to run. Microsoft just made it under the bar for us to consider that rev for fall quarter. Server 2008 R2 has a lot of new stuff in it, such as even more PowerShell (yes, it really is all that and a bag of chips) stuff, and PowerShell 2.0! "Printer Driver Isolation," should help minimize spooler faults, something I fear already even though I'm not running Windows Printing in production yet. Built in MPIO gets improvements as well, something that is very nice to have.

And yet... if we don't get it in time, we may not do it for the file serving cluster. Especially if pcounter doesn't work with the rebuilt printing paths for some reason. Won't know until we get stuff.

But once we get a delivery date for the storage pieces, we can start talking actual timelines beyond, "we hope to get it all done by fall start." Like, which weekends we'll need to block out to babysit the data migrations.

Pcounter for AD is cool

| 1 Comment
Part of the migration project involves moving the print environment over to Windows. One thing is clear, pcounter makes Windows printing actually work. We haven't had a chance to do anything like scale testing to see how stable it is, that'll sadly have to wait until we get enough traffic (i.e. in production).

One of the ways that pcounter helps Windows printing actually work is to rationalize the print-pooling setup. Under standard Windows printing, print pooling is not a load balancing configuration. Additional printers are used when the first printers are busy with jobs, which means that one printer will get the majority of the print jobs. PCounter does true round-robbin to spread the wear-n-tear.

Pcounter does this by creating a new printer-port type called pcounter. This allows it to get creative with how it handles talking to printers.

PCounter ports display

Hitting Configure brings up the pcounter port config dialog, which you can also get at through the pcounter tools themselves.

PCounter port config dialog

There are many types here. Three ways to talk to printers directly, direct IP, LPR, and direct-attach, and two virtual methods. "Load Balance" does what you expect, you pick a number of already configured pcounter ports to put into the list and any jobs submitted to this new port will print in a round-robin fashion to printers in this list. The "OtherPrinter" option allows you to print directly via non-Pcounter printers, but only one. This last option could be useful if you had some kind of print-to-PDF software on the server that you wanted to regulate through pcounter.

The other nifty thing we're getting into is setting up a web-based release station. We could have done this in the past with NetWare, but never got around to it. It has a lot of features we won't use (such as client-codes), but it does what we want and adds a nice feature: quota listing.

Web release web-page

That sort of quota list is a very nice thing. One thing that pcounter does NOT do that it did do with eDirectory, was put the quota as an attribute on the user object. Instead it uses a custom database. Unfortunately, this means that quota is no longer LDAP accessible, which will have some implications for some of our internal tools.

Cool stuff. I'm still working with ATUS to come up with a config everyone likes, so we'll see where we end up come fall start.

We go through paper

Spring quarter is done, and grades are turned in. Time to take a look at student printing counts.

Things are changing! Printing costs do keep rising, and for a good discussion of realities check this article from ATUS News. The numbers in there are from Fall quarter. Now I'll give some Spring quarter numbers (departmental break down is different than the article, since I'm personally not sure which labs belong to which department):

Numbers are from 3/29/09-6/17/09 (8:17am)
Total Pages Printed: 1,840,186
ATUS Labs: 51.5%
Library Printers: 22.9%
Housing Labs: 14%
Comms Bldg: 6.8%
Average pages printed per user: 152
Median pages printed per user: 112
Number of users who printed anything: 12,119
Number of users over 500 pages: 292
Number of users over 1000 pages: 7
"Over quota" pages printed: 181,756

Students get a free quota of 500 pages each quarter. Getting more when you run out is as simple as contacting a helpdesk and getting your quota upped. As you can see, 2.4% of users managed to account for 9.9% of all pages printed.

It is a common misconception that the Student Tech Fee pays for the 500 pages each student gets. In actuality, that cost is eaten by each of the departments running a student printer, which means that printing has historically been a gratis benefit. There is a proposal going forward that would change things so you'd have to pay $.05/page for upping your quota. The top print-user of this quarter would have had to have paid a bit over $69 in additional quota if we were using the pay system. If ALL of the users who went over 500 pages had to pay for their additional quota, that would have generated a bit under $9088 in recovered printing costs.

Of course, if added print quota were a cost-item it will depress that overage activity. Another curve-ball is the desire of certain departments to offer color printing, but they really want to recapture their printing costs for those printers. So far we haven't done a good job of that, but we are in the process of revising the printing system to better handle it. It'll require some identity-management code changes to handle the quota management process differently, but it is at least doable.

Once you start involving actual money in this transaction, it opens up a whole 'nother can o worms. First off, cash-handling. Our help-desks do not want to be in the business of dealing with cash, so we'll need some kind of swipe-kiosh to handle that. Also, after-hours quota-bumps will need to be handled since our helpdesks are not 24/7 and sometimes students run out of quota at 6am during finals week and have an 8am class.

Second, accounting. Not all labs are run by ATUS. Some labs are run by departments that charge lab-fees that ostensibly also support lab printing. Some way to apportion recovered printing costs to departments will have to be created. Those departments that charge lab-fees may find it convenient to apply a portion of those fees to their student's page-quota.

Third, extra-cost printing like color. PCounter allows printers to be configured to not allow the use of 'free quota' for printing. So in theory, things like color or large-format-printers could be configured to only accept paid-for quota. These devices will have a cost higher than $.05/page, perhaps even $.25/page for color, or much higher for the LFP's. It could also mean some departmental lab-managers may decide to stop accepting free-quota in their labs and go charge-only.

Fourth, carry-over of paid quota. If a student forks over $20 for added quota, that should carry over until it is used. Also, it is very likely that they'll demand a refund of any unspent print-quota on graduation. Some refund mechanism will also need to be created.

I don't know at what step the proposal is, all I know is that it hasn't been approved yet. But it is very likely to be approved for fall.

Printing costs

| 1 Comment
In the most recent ATUS News there is an article about printing costs. As it happens, the page-count data is data I've taken a solid look at. Printing costs have gotten a lot of attention lately as a possible cost-savings measure, and I suspect this article's existence is due in large part to that. Yeah, we go through a lot of paper.

Updated: My figures for Winter quarter.

Windows 7 RC is out

And they're saying that Win7 will ship well before the Jan-2010 Vista timeframe mentioned before. Well, we kind of expected that. We've also been doing a lot with our network to make it more Win7 (and Vista) friendly, since we know we'll get a LOT of Win7 once it shows up for real.

The biggest concern is that Microsoft still hasn't fixed the issue that makes the Novell Client for Vista so darned slow. This is a major deal-breaker for us, so we've been informed from on high to Do Something so our Vista/Win7 clients can have fast file-serving and printing.

That "Something" has been to turn on the CIFS stack on our NetWare servers, with domain integrated login. The Vista and Win7 clients will have to turn their LanMan Authentication Level from the default (and secure) setting of, "Send NTLMv2 Response Only" to at most, "Send NTLM Response Only." The NetWare CIFS stack can't handle NTLMv2, nor will it ever. Those people who have been suffering through the NCV get downright bouncy when they see how fast it is.

Printing... we'll see. A LOT of the printing in fac/staff land is direct-IP which has no Novell dependencies. There are a few departments out there that have enough print volume that a print-server is a good idea, so I'm hoping there is an iPrint client for Win7 out pretty fast.

All in all, we're expecting uptake of Win7 to be a lot faster than Vista ever was. In this sense Win7 is a lot like Win98SE. All the press saying that Win7 is a lot better than Vista will help drive the push away from WinXP.