New network printer prints out garbage like old printer :(

[Cerulean]

Greetings,

We have a brand new Windows 2008 R2 x64 terminal server. Additionally, we have a Windows Server 2003 x86 print server. All prints to the 2003 server are problem-free and print fine. However, because we have upgraded most of the company's computers to 64-bit Windows 7 and moved many users from PCs to the 2008 R2 x64 server, we've been forced due to resource constraints and perhaps to some degree 'bad planning' to use the 2008 R2 x64 server as a print server for x64 machines and users.

Using the latest HP Universal Drivers, when users print to many of the printers at the office (through the 2008 R2 x64 server), they get an extra page with this garbage printed to it [1]:

[1]

(I censored out the actual username there)

This problem would happen for these old HP LaserJet 2200 printers (parallel-based, long before Ethernet connectivity came to be). So, we thought, "it must be cause these printers are so darn old that even though HP says the UPD supports these models, it obviously doesn't! We need to upgrade office printers anyway because none of the printers here support automatic duplex."

So, we got a new printer: HP LaserJet 2055dn (networked, supports auto-duplex)

Low and behold, the problem is not solved by getting a new printer. We only bought one so that we can diagnose the situation and get it solved before upgrading the entire office's printers. When replacing, we just created a new TCP/IP printer port (for the DHCP-assigned & reserved IP address of the new 2055dn), went into the existing printer queue DIVI_LZ.P06, changed to the TCP/IP printer port we created, went to the Drivers tab, and verified that HP Universal Printer Drivers was selected.

In addition, we have these symptoms as well:

• The above extra printout image [1] -- we get this easily if we just print a simple test page
• When printing PDFs or Excel sheets, only blank pages (both sides) come out -- nothing actually printed
• When printing e-mails from Outlook 2010, this [2] and this [3] happens

[2]

[3]

We have a lot of HP LaserJet 1100 parallel-based printers, a couple 2200, and a few stray/other model. We're mostly experiencing these problems on 1100 and 2200 printers. On some 1100 printers, we get a Windows test page like this too [4]:

[4]

We were using 5.2.3 UPD PCL5 drivers on both the x86 and x64 servers. I had upgraded the UPD drivers on both servers to latest 5.4.0 -- made no difference whatsoever. I even tried PCL6 on the x64 server, but that didn't work, so I switch back to PCL5 (just wanted to see the difference). I never tried using the PostScript/PS version of the HP Universal Printer Drivers.

And finally, just to clarify: the x86 server has never given any troubles with printing, only the x64. Using default for everything for creating printer queues, no special tweaks, fixes, configuration, etcetera -- just setting up new printer queues like any normal consumer or network administrator would.

 

[cyr0n_k0r]

Try not using the universal driver.

I'll tell you thought that we have the EXACT same setup as you and ours work fine. We have 2008 R2 servers running XP clients with HP 2055dn's. We use the UPD PCL5 and everything works great.

Also, why is using the 2008 R2 server bad planning to use as a print server? Ours work great.

Also, read this:
http://social.technet.microsoft.com...t/thread/6067a35d-d9ac-4f52-8beb-9aca3f116e9e

 

[Cerulean]

The idea is to avoid using printer-specific drivers and hug universal drivers of any kind as tightly as possible. The reason being that some printer drivers will overlap each over on libraries and functions they use, and in 99% of the cases we have had BSODs on the x86 ad x64 dedicated print servers at headquarters were because of conflicting printer drivers. Using the least number of unique printer drivers results in greater stability, less problems with both driver, software, printers, and OS, and less resource usage.

At the company I work, we try to have a server dedicated to being a print server (some other functions are added too, such as fileserving). The reason we do this is I think because to cut down on 'unnecessary' resource usage on terminal servers that users use, and BSODs. If a terminal server encounters a BSOD, that takes down everyone on that terminal server (and of course, any laptop/desktop that is connected to a print queue on that server). At the particular branch I am working at -- an international location -- the "utility server" is used as the x86 print server, being Windows Server 2003. The 2008 R2 x64 is a new from-scratch deployment our previous sysadmin had prepared (before he left the company), and is the only 2008 or 64-bit server in the entire rack. This is the second terminal server, and is a 1U DL380 G7 I think; the first terminal server is a Windows Server 2003 DL380 G5.

Pro of using a print queue on a terminal server rather than a server dedicated to print serving is that users can print to those queues as local queues -- less network overhead, less time to wait for print (though not as noticeable of an improvement), one less factor involved in troubleshooting printers ...

We're trying a couple things from http://www.ardamis.com/2012/02/15/troubleshooting-printing-problems-with-hp-upd-and-pjl/, such as disabling advanced printer/printing features in Printer Properties. That seems to have fixed it for our 2055dn. We're waiting for more 2055dn's to arrive in shipping so that we can test this on other printer queues to see if this is the solution in our case.

An additional problem with our old 1100, 1300, and 2200 printers are that HP doesn't make x64 drivers for these printers, and instead points the user to go and use the UPD instead if you want x64.

 

[cyr0n_k0r]

The idea is to avoid using printer-specific drivers and hug universal drivers of any kind as tightly as possible. The reason being that some printer drivers will overlap each over on libraries and functions they use,

I hear ya.. preaching to the choir.
I use the universal whenever I can, but was just saying that our setup is the same as yours and it works great.
Although I don't subscribe to your way of setting up print servers in terms of what server you put the printer service on and your reasoning why.