Printing on Windows 7 and Server 2008 R2 with HP Universal driver

This is using the version 5.2 (5.2.9.8874) driver (at the moment). Seeing a few issues, shall we say…

• Print server is 32-bit Server 2008, but I’ve also tried Server 2008 R2 (64-bit obviously) with the same results. Print servers have both 32-bit and 64-bit versions of the driver installed for the shared printers.
• Clients are mostly 64-bit Windows 7 and Server 2008 R2 XenApp 6.0

The issues I’m seeing are as follows:

1. Driver appears to be being pulled down from the print server each time you log on to a client if you have a connection to a network printer (that uses the Universal driver) in your profile, or you try and add a connection to such a network printer. In doing this it creates files of the form SETxxxx.tmp in \Windows\System32, where xxxx is a hexadecimal number. These files are actually copies of DIFxAPI.dll, rename one to have a .dll extension and you get the following from the Properties dialogue, Details tab:
   File description: Driver Install Frameworks for API library module
   Type: Application extension
   File version: 2.1.0.0
   Product name: Driver Install Frameworks API (DIFxAPI)
   Product version: 2.1
   Copyright: © Microsoft Corporation. All rights reserved.
   Size: 497 KB
   Date modified: 25/02/2009 19:01
   Language: English (United States)
   Original filename: DIFxAPI.dll
   The other thing is that the driver seems to be being pulled down via Package Point and Print, as if you block this via group policy the printer becomes unusable. The blocking techique I used is to set the policy Package Point and print – Approved servers, and enter a server name that does not exist (or at least is not the name of your print server), as detailed in CTX128786. When a user tries to print to it they get a warning box asking:
   Do you trust this printer?
   Windows needs to download and install a software driver from \\<printserver> computer to print to <shared printer>. Proceed only if you trust the \\<printserver> computer and the network, and then restart the print job.
   The “Install driver” button has a blue and yellow UAC shield on it. In my environment I’ve configured UAC to decline all prompts for elevation, and so the upshot of this is that users can’t print at all.
   Thus, blocking the driver being downloaded each time seems not to be viable, and so as a workaround I am deleting the SETxxxx.tmp files every couple of days as part of the maintenance process when the servers reboot – these files actually filled up one of the my server system drives, I had over 10,000 of them before I noticed this issue.
   Update: To fix this issue, also set the following group policy to Disabled: Point and Print Restrictions. That said, even with both these policies set I’m still getting the .tmp file being created on the XenApp servers, but the Win7 PCs and the XenApp servers have quite a few differences to their Group Policies, so I’m assuming there is another setting somewhere that’s controlling this. More info if/when I find it.
2. Printers are taking a long time, several minutes, between logging on and when they appear within the Print dialogue in applications. There is a hotfix that potentially might resolve this, KB2457866. However initial testing seems to show that it’s only stopping the error being logged, and the delay with the printers showing up within application Print dialogue boxes is still there. I know it talks about a delay with the printers showing up via Control Panel, but I’ve not been able to test this as I block my users from seeing the Printers control panel.
3. When users print sometimes the print job never gets to the server. Investigating this showed the following error being logged in the Microsoft-Windows-PrintService/Admin event log:
   The document <some doc name>.docx, owned by <some username>, failed to print on printer {381FD361-118F-48D0-8B9D-7246FF78F909}. Try to print the document again, or restart the print spooler.
   Data type: NT EMF 1.008. Size of the spool file in bytes: 26988. Number of bytes printed: 0. Total number of pages in the document: 2. Number of pages printed: 0. Client computer: \\<computername>. Win32 error code returned by the print processor: 5. Access is denied.
4. The following event being logged in the Microsoft-Windows-PrintService/Operational event log (which you need to enable via the Event Viewer snapin)
   Source: PrintService
   Event ID: 822
   Level: Error
   Task Category: Client Side Rendering reverting to Server Side Rendering
   Keywords: Client Side Rendering (CSR)
   OpCode: Spooler Operation Failed
   Unknown print processor (hpzpplhn) or invalid data type (RAW), error 0x706, Client Side Rendering is disabled. See the event user data for more context information.
   If you convert that error number (0x706) from hexadecimal to decimal you get 1798, and if you look this up you find that the error description is: Print processor is unknown.
5. Also in the Microsoft-Windows-PrintService/Operational I sometimes see:
   Source:        Microsoft-Windows-PrintService
   Event ID:      820
   Task Category: Client Side Rendering reverting to Server Side Rendering
   Level:         Error
   Keywords:      Client Side Rendering (CSR)
   User:          SYSTEM
   Description:
   Client side rendering to \\CSR|<print server name>\{0EF995D2-8256-4609-B831-9284A69F31C0}, Job 3 failed, error code 0x5. The print spooler service will retry server side rendering. See the event user data for more context information.

In the 5.3.1 driver (5.3.1.10527) release notes it’s claimed to resolve a few speed related issues: delays when creating new client connection to print servers, and file permissions causing slow installs in Windows 7 and Server 2008 R2 point and print clients.

Interesting response to a support call logged with HP for this issue:

This issue is due to the sharing the driver between server and clients. I would like to inform that, sharing is not recommended as it will result in unknown problems. Hence I would request you to check by locally installing the printer driver i.e. the same UPD directly on any client PC and then check performance issues. I guarantee there will be no issues. Since you are sharing and there is group policy restriction in place, it will be slow every time and not work correctly. So only solution local install on each PC of UPD instead of -> only 1 copy on server and sharing between clients.

But then they decided not to help anymore as the printer I happened to pick to log the fault against (you can’t log a fault against the driver itself) had unfortunately gone out of warranty. I have several hundred in warranty printers but they seemed unable to grasp this.

I then tested installing the driver on a PC in a few different ways, but on connecting to the printer on the print server received the following error in the Microsoft-Windows-PrintService/Admin log:
Event ID: 354
Task Category: Initializing
Level: Error
Keywords: Classic Spooler Event
Description: \\SERVER\HP Universal Printing PCL 5 (v5.2) initialization failed at \\server\print$\BIDI\HPBOID.DLL. Error: 2. The system cannot find the file specified. . This can occur because of system instability or a lack of system resources.

More info as I get it…