This occurs because the print processor defined for the package is not suitable for the workstation it is being installed upon. This normally happens when the package supports both 64- and 32-bit architectures, but is being installed on a CPU bit depth that differs from the Uniprint Print Server (for example: a 64-bit Windows 7 client installs the package, and the Print Server is 32-bit Windows 2003). Some drivers may use different files for the print processor on different architectures.


There are two courses of action.

Course 1. Change the Driver's Print Processor


Many print drivers can use the standard WinPrint as a print procesor. To change to this print processor, go into Properties for the queue on the Pharos Print Server, click the Advanced tab and click the Print Processor button. From there, choose the WinPrint processor from the list on the left, and then choose Raw from the list on the right (see the attached, PP.JPG). Once complete, rebuild the packages, initiate a change control and install again. If your packages include the Automatic Updater, clients will receive the new driver over time.

The risk with this course is that the manufacturer may have designed the driver to only support certain features through the custom print processor. If this change allows the driver to install, but yields unexpected (or unwanted) results or lack of features, go on to Course 2.


Course 2. Modify the Windows Registry for the included Print Processor


Rather than switching to Winprint, which can potentially drop printing features, there is an alternative solution you may be able to apply. Also, clients may not update for a day or more, and printing through mismatched print processors can cause failures in the system.


On a 32-bit server, go to the Windows Registry and look under HKey_Local_Machine\System\CurrentControlSet\Control\Print\Environments, you will see a number of subkeys. Look under the Windows NT x86\Print Processors key and find the exact name of the print processor (it will be listed as a value for "Driver") that you're using successfully on your 32-bit clients. Then look under Windows x64\Print Processors key and find the x64 equivalent. It will almost certainly be named subtly differently. If you rename the x64 print processor key so that it matches the x86 one, then rebuild the packages, your 64-bit clients should install fine and your 32-bit clients will not need to update.

Note: In order to rebuild the packages correctly, you may need to delete the existing driver modules from the modules subdirectory in your package build location.  The driver modules have filenames beginning with drv_.