pcl6 driver not accepted in a "add network printer" demand.

[Mark Bbb]

All drivers on the server are accepted on the hosts, as long as it is not a pcl6 driver.
The pcl6 device has been found in the list on a host, that is ok, but when we want to install it on that host, it says "contact the IT'er" (or something like that) and installation failled.
I think it is a Firewall issue because when the problem started to happen (at the beginning of these year) with those corrupted Microsoft updates (which resulted in no more printing) this IT'er probably blocked the pcl6 on their firewall.
We don't know if he did, because the IT'er is on holiday for the whole week from this day on.
What do you think?

[rthonpm]

Re: pcl6 driver not accepted in a "add network printer" demand.

You can't block a specific driver from connecting using a firewall: a printer either connects or it doesn't; the driver used doesn't change how it connects.

The issue is that Microsoft has changed the configuration for shared printers that admin rights are needed for the first connection to the server's spooler service. After that, any standard user can print.

[BillyCarpenter]

Re: pcl6 driver not accepted in a "add network printer" demand.

You can't block a specific driver from connecting using a firewall: a printer either connects or it doesn't; the driver used doesn't change how it connects.

The issue is that Microsoft has changed the configuration for shared printers that admin rights are needed for the first connection to the server's spooler service. After that, any standard user can print.

I always enjoy reading your posts. Very informative.

[Mark Bbb]

Re: pcl6 driver not accepted in a "add network printer" demand.

You can't block a specific driver from connecting using a firewall: a printer either connects or it doesn't; the driver used doesn't change how it connects.

The issue is that Microsoft has changed the configuration for shared printers that admin rights are needed for the first connection to the server's spooler service. After that, any standard user can print.

Thanks, Rhon.
But if that would be the case, why would Microsoft blocks only pcl6 and not any other driver?
Perhaps this authentication is in the pcl6 driver itself?

[slimslob]

Re: pcl6 driver not accepted in a "add network printer" demand.

Thanks, Rhon.
But if that would be the case, why would Microsoft blocks only pcl6 and not any other driver?
Perhaps this authentication is in the pcl6 driver itself?

Maybe there are not any currently installed printers using the PCL6 driver.

[rthonpm]

Re: pcl6 driver not accepted in a "add network printer" demand.

It's been hit or miss as to what drivers seem to require the admin prompt and which ones don't. The newer Type 4 drivers don't seem to require an admin prompt, nor do some PCL and PostScript drivers for various models. Part of the issue seems to be how the drivers are signed as Microsoft has become a lot more strict on driver signing.

[KeviM]

Re: pcl6 driver not accepted in a "add network printer" demand.

I've had similar issues on the past. On my side , on a network of about a few computers, all about 1 of 2 would accept the PCL 6 drivers. Normally I would try to update the drivers to Version 4.* or try the drivers on the OS. If it went beyond that it would mean me looking for Windows updates and either installing or removing.

Of course when there's an IT / Network administrator things get difficult. Then I tell them what I picked up and ask them to resolve the issue.

All the best. Hope this helps

[KenB]

Re: pcl6 driver not accepted in a "add network printer" demand.

Microsoft is pushing the use of V4 drivers, mostly in the name of security.

From what I understand, they don’t actually install on the workstations, so the need for admin rights goes away.

Ricoh does offer V4 drivers, but don’t get that confused with the version 4.x numbering of their V3 type drivers, most notably the PCL6 Universal driver (which is almost always used in Streamline or Equitrac environments).

The Type 4 drivers don’t offer as many features, either. They can’t be used with non-standard port monitors, such as Streamline or Equitrac.

[Mark Bbb]

Re: pcl6 driver not accepted in a "add network printer" demand.

Ken, pcl5 is not blocked, only pcl6... I'll check for the windows update.

[rthonpm]

Re: pcl6 driver not accepted in a "add network printer" demand.

Type 4 drivers were developed for servers as a driver type that was platform agnostic since connections can be made to 32-bit, 64-bit, and now ARM clients without the need for additional drivers to be installed on the server. The downside is that Type 4 drivers don't install to the clients like a Type 3 driver so if the driver isn't already on a client then a generic point and print driver built into Windows is used. These often don't offer the full feature set of a device. Type 4 print queues also won't allow connections from non-Windows operating systems.

We've experimented with using Type 4 drivers and for basic printing, they work quite well. When you get to MFP's or any kind of advanced finishing options, they rapidly lose their value. For environments with mixed operating systems Type 3 is the only way to go.


Sent from my BlackBerry using Tapatalk

[Mark Bbb]

Re: pcl6 driver not accepted in a "add network printer" demand.

Type 4 drivers were developed for servers as a driver type that was platform agnostic since connections can be made to 32-bit, 64-bit, and now ARM clients without the need for additional drivers to be installed on the server. The downside is that Type 4 drivers don't install to the clients like a Type 3 driver so if the driver isn't already on a client then a generic point and print driver built into Windows is used. These often don't offer the full feature set of a device. Type 4 print queues also won't allow connections from non-Windows operating systems.

We've experimented with using Type 4 drivers and for basic printing, they work quite well. When you get to MFP's or any kind of advanced finishing options, they rapidly lose their value. For environments with mixed operating systems Type 3 is the only way to go.


Sent from my BlackBerry using Tapatalk

Thank you, Rhon!

[Mark Bbb]

Re: pcl6 driver not accepted in a "add network printer" demand.

Type 4 drivers were developed for servers as a driver type that was platform agnostic since connections can be made to 32-bit, 64-bit, and now ARM clients without the need for additional drivers to be installed on the server. The downside is that Type 4 drivers don't install to the clients like a Type 3 driver so if the driver isn't already on a client then a generic point and print driver built into Windows is used. These often don't offer the full feature set of a device. Type 4 print queues also won't allow connections from non-Windows operating systems.

We've experimented with using Type 4 drivers and for basic printing, they work quite well. When you get to MFP's or any kind of advanced finishing options, they rapidly lose their value. For environments with mixed operating systems Type 3 is the only way to go.

Maybe a stupid question, but when will this be solved properly? And who must give the solution? Perhaps customer needs a more recent server?

[KenB]

Re: pcl6 driver not accepted in a "add network printer" demand.

Maybe a stupid question, but when will this be solved properly? And who must give the solution? Perhaps customer needs a more recent server?

Not a stupid question at all, although I fear the answer to both parts is "Who the <fill in expiltive> knows".

I was actually on a Teams call last week with a customer and a Microsoft rep. He had some suggestions, but no real fixes. He did say they are actively look into a fix for the problems they created.

Hurry up and wait, I guess.

[rthonpm]

Re: pcl6 driver not accepted in a &quot;add network printer&quot; demand.

This is a problem that really goes back decades to the NT kernel. Eventually (and I'm going to be shocked if it's not already underway) Microsoft is going to have to replace NT as the foundation of Windows. There's a lot of legacy code sitting in the kernel that was designed for a very different world from a security perspective.

From what I've seen, the only real workarounds right now are either explicit group policies for domain machines that tell computers what print servers to inherently trust, or registry keys on both client and server sides to remove some of the changes made by the patches.

Sent from my BlackBerry using Tapatalk