HP Universal Print Driver PreConfig

[Storm]

Im having an issue following HP's Drvier preconfiguration guide

Im using the latest version of the universal print driver and thus have a file called hpcpu215.cfm saved in the %systemroot%\system32\spool\drivers \x64\3\ path

Install the driver

Select one of my printers and choose the new driver

Settings work as expected, this is the tab shown under the printer:

I then use this Powershell script to change the driver on all of my other printers

    $driver = "HP Universal Printing PCL 6 (v6.6.0)"
    
    $printers = gwmi win32_printer
    
    foreach($printer in ($printers|Where{$_.DriverName -like 'HP Universal Printing PCL 6 (v6.2.1)'})){
            $name = $printer.name
            & rundll32 printui.dll PrintUIEntry /Xs /n $name DriverName $driver
    }

Which changes the drivers as expected;

However, when i then go into the settings of that printer; the driver is no longer using my preconfigurations.

Been tearing my hair out on this, if anyone has any ideas that would be amazing.

 

[sc302 Veteran]

I am guessing you are a windows shop.  if you are a windows shop, I hope you are running active directory.  If you are running active directory, perhaps you should run a print server.  If you run a print server all of your issues go away as it would be a central repository for drivers (all clients look to the server for the drivers) and it can also default all settings to whatever you choose them to be.  1 and done kind of thing.

[Storm]

2 minutes ago, sc302 said:

I am guessing you are a windows shop.  if you are a windows shop, I hope you are running active directory.  If you are running active directory, perhaps you should run a print server.  If you run a print server all of your issues go away as it would be a central repository for drivers (all clients look to the server for the drivers) and it can also default all settings to whatever you choose them to be.  1 and done kind of thing.

Hi

Yes we are

 

This is on one of the print servers. 

 

I have precondigured the hp UPD to default to B&W, and disable mopier mode. 

 

We have over 400 printers and are slowly changing models, so without this it's a lot of manual work. Sadly for some reason it's not working. 

[sc302 Veteran]

When you setup the windows print server printer object properties, go to advanced, printing defaults.  You will be able to select the default behavior of the printer driver there, when computers connect to the printer object they will get the defaults you have applied to that object.  The driver drop down is also available to choose whatever driver you wish to push out.  And if you are using the print server role, you can go to "deployed printers" and have it create a group policy to deploy that printer to the computers in your environment.  Alternatively you can use group policy preferences to push the printer objects out (with whatever driver you choose) or delete the printers.  The printers can be deployed as a user object or computer object and it can be based on a group or an OU or a combination of the both.  Or you could use kix, or you could use printui.dll to connect to those printers or remove those printers.  

 

FYI, those drivers are not on a local computer connected to a print server.  Those drivers are on a local computer.  

 

The driver properties would read Printer on Print server if it were connecting to a print server.  You are doing this very manually.

 

 

 

[Storm]

Thats not really what i need; 

 

Sorry

 

We have 12 Terminal server hosts; one of our applications requires the printers to be installed locally

 

which means we have 400 printers on each of the servers (400 x 12 ) .

 

Its a pain when we change printers; what i am doing should work but doesnt

 

And the issue is with the HP UPD Preconfig (HP Park) not the actual admin of the drivers etc

[sc302 Veteran]

Well it could be done my way as well.  

 

But you should be using a terminal server universal print driver, not that.  

 

uniprint 

https://www.uniprint.net/en/

 

screwdrivers

https://www.tricerat.com/solution/screwdrivers/

 

These allow pass through to the client printer without the need to install every different printer on the planet that they may have (home printers or office printers)

 

that universal print driver is not what you should be using.   I believe 2012 comes with its own rendition to this because printing is so terribly managed on terminal servers. 

 

 

Also, very much yes, you can absolutely do it the way I suggest for terminal servers. If you do it the way I suggest and have rds pass the printer object through to the client, it would use the clients settings.  Even a thin client of if it has a local printer setup on it. Or you could simply have the gpo on the user object based on group membership to connect to the proper printer on the print server with the correct settings. 

 

But I would use uniprint or screwdrivers or the built in one that comes with windows (if you are on a version that supports it) esp if not on thin clients.  That is a terminal server/Citrix server universal print driver, not what you are using which is a universal print driver for printers (which really screws with the terminology as universal print drivers for terminal servers came out with windows 2000 server to help manage ts printers).   No need to install a million drivers, no need for a million printer objects for users to fish through.  

[Matthew S.]

@sc302in an ideal world where companies actually used the recommended setup that would work, but a lot of companies don't and create thousands of printer objects and clog up the print server.

[sc302 Veteran]

5 minutes ago, Matthew S. said:

@sc302in an ideal world where companies actually used the recommended setup that would work, but a lot of companies don't and create thousands of printer objects and clog up the print server.

Do you realize the time and effort another $1000 per server can save?  You have already invested this much what is a little more to do it right.  Or if you have a server with that tech built in, why would you do something so time consuming and difficult to support?  Or if it is local why not have group policy connect to the printer object on your print server per user? Or if the computers already have mapped printers why not just only install the printer driver on each host so that client default printer pass through would function?

[Matthew S.]

Oh I'm not saying I don't agree with you, but really, even the company I work for doesn't use the built-in tech, hell we still use local profiles vs. remote...

[sc302 Veteran]

It is either lazy IT who refuses to look for better ways or it is inexperienced IT who doesn’t know better.   Take your pick. 

[kej.android]

Hi Storm,

 

 Just in case you're still watching this thread,  I just wanted to confirm that this is happening here too. It looks to be a bug specifically in the v6.6.0 drivers. I've thrown my bag-of-tricks at it a number of times but the they keep sliding off. The only thing to suggest here is stepping back to the v6.5.0 drivers and then asking HP to look at it. I will as soon as I have time!

 

 The best I've got so far is that there's a caching mechanism being used nowadays and it looks a bit logistically tied up for the latest drivers. I haven't yet managed to find time to try all the angles and identify the breaking point but my gut feeling is that HP have dropped the ball on cross-testing the caching of settings properly for all deployment methods. right now, the .CFM drop method has interesting programmatic issues that people like yourself and I only notice from our front-line usage.

 

 FWIW -

 

 From what I've seen so far for the newer drivers;

 1) During the driver staging, the .CFM file gets copied to a .CFG file with a name related to the driver's name. The name is different for generic vs specific versions and also for the flavour of driver (PS vs PCL) so you get things like "hpcpuXYZ.cfg", "hpcpuXYZ_PS.cfg", "hpcpuXYZ_P6.cfg" appearing in the driver directory .

2) When the queue "instance" is created from the pre-staged driver, a copy of that generated  .CFG is added to "%ProgramData%\Hewlett-Packard\HP Print Settings" with an abstract name such as "HP<6-digits-in-lowercase-alphanumerics>.cfg" that links back to the print queue itself  via a registry entry.

 

 I've monitored those two stages separately with ProcMon and the pre-staging seems to open all the right files and should work. Watching the first instance of a print queue being created vs the second is interesting though from a coder's point of view.

 

 When the first instance of the queue is created, you can see the abstract files being created in %PROGRAMDATA% twice which suggests to my programmer head that the there's two code paths running in turn. The first code path fires to properly read the config files and set up the registry keys to initialise a working queue and leaves you with a working setup. The second code path (most probably what fires up secondarily and then also for every instance from then on) probably fires correctly but doesn't appear to actually do anything useful. (It seems to write the registry entries correctly but just lacks the code to prod the queue to reload the settings and leaves the queue working with whatever it had in memory at the time)

 

My gut-feeling is that HP have just whoopsied the code a bit... trying to explain it without hours of detailed work might take a while though...

 

My best advice is to step away from the v6.6.0 drivers if you can avoid them for the moment and just use the v6.5.0 until the dust settles.

 

Regards,

 

Keith

[Zinomian]

On 6/13/2018 at 5:53 AM, Storm said:

We have 12 Terminal server hosts; one of our applications requires the printers to be installed locally

 

which means we have 400 printers on each of the servers (400 x 12 ) .

Any hope that you might have tested the printer redirection on RDS 2016?  I had a similar situation with an old DB program, however, after testing deployment to our new RDS 2016, the MS printer redirection driver worked like a charm and the old program was able to see the redirected printers as locals.....not sure what changed between RDS 2012 R2 and 2016, but something did.