How can I get rid of the "Do you trust this printer" message box and add my printer via GPO?

Question

• Workstation: Windows 7 (x64) [Install target for printer]
• Server: Windows Server 2012 R2 (x64) [Active Directory, Print Server]

I have been bashing my head on the desk trying to get this printer to be installed via group policy! For some reason, I simply can NOT get this printer deployed with GPO. I have tried setting it up to deploy via Computer Configuration->Policies->Windows Settings->Deployed Printers, as well as Computer Configuration->Preferences->Control Panel Settings->Printers and User Configuration->Preferences->Control Panel Settings->Printers. I have also tried going through my Print Server Management console to add it via user and/or computer targeting. I have tried ALL KINDS of ways and nothing is working. I followed a bunch of tutorials and watched a bunch of videos just to make sure I was not missing something but it really is a simple task (in theory)... It just will not work.

In trying to debug the issue I found that if I went to \\myserver\ and double clicked on the printer it would try to install the printer and then prompt me to install the drivers with a UAC type prompt.

I have tried everything I can think of to get that message box to stop popping up. I dug into it and found that if I was to edit a GPO called Point and Print Restrictions located at Computer Configuration->Policies->Administrative Templates->Printers and was as at User Configuration->Policies->Administrative Templates->Control Panel->Printers you could try setting the policy to Disabled or Enabled and choose Do not show warning or elevation prompt for the two Security Prompts listed at the bottom of the policy settings.

Well that was a bust too...

I did find that if I tried to manually install the printer by going to the unc and typing in my Administrator credentials it would download the drivers from the server and install the printer (as expected). If the user tried to remove the printer and was successful somehow as soon as they would log off and back on the GPO would do what I want and add the printer back. But it required me to add it manually the first time on EVERY PC.

After testing this and then removing the printer from the GPO, then logging off and on again. I could run the command printui /s /t2 to bring up a GUI that would allow me to remove the installed drivers with ease to put the PC back to it's original state (asking for Administrator credentials). Also something else I learned was the printers were stored in the registry located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Connections. When I was trying to remove a printer and it told me I couldn't, I just went to that registry key and removed the GUID key of the printer I was trying to delete. Then just restarted the Print Spooler service and boom it was gone. This was no help getting me get to where I wanted but it was helpful in removing the printer during debugging the issue.

I read somewhere that maybe the cause is some type of windows security update that changed something. It was released because of some article showing how you could pwn an entire network if you were able to pwn a single printer. Something about when users connected to the printer and downloaded the drivers it would install injected software and run on the machine, etc...

My main goal is to be able to deploy this printer to a set of users in this OU with the GPO I'm using. But everything I try requires an Administrator to be logged on to do it (at least the first time). Does anyone have any idea why my printer will not automatically add itself via the GPO and also how do I get that dang "Do you trust this printer?" message to go away?

Solution 1

The "fix" is to download trusted, package-aware print drivers from the printer manufacturer; however, since not all manufacturers will produce these drivers, there is a work around that I found here: Cannon Forum - Package-Aware Print Drivers (Note: This does not work for unsigned drivers, but there are plenty of tutorials out there for self-signing a print driver.)

Here are the steps to get around the issue:

1. Install the required drivers on the print server
2. Note any drivers that have "false" listed under the "Packaged" column. All of these will have to be modified to deploy via Group Policy.
3. Edit the registry on your print server and go to the following locations:
   • For 64-bit drivers: HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windowsx64\Drivers\Version-X\{Driver Name}
   • For 32-bit drivers: HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windows NT x86\Drivers\Version-X\{Driver Name}
   • Where "X" is the print driver "Type", usually either "3" or "4"
4. Edit the key named "PrinterDriverAttributes" by adding 1 to whatever value is currently set. (Example: if the current value is "6", change it to "7".) This will make the print server believe that these drivers are packaged.
5. Do this for every driver that is not listed as a "Packaged" driver.
6. Restart the print server.
7. Everything should now deploy through Group Policy (provided you have all the usual GPO settings configured correctly).

I am in the process of deploying this fix myself; however, since it requires a restart of the print server I cannot test it until this evening since our print server also runs a few networked applications.

An alternate solution to the registry edit is to edit the printer driver INF file and add the following:

For 32-bit drivers:

[PrinterPackageInstallation.x86]
PackageAware=TRUE

For 64-bit driver

[PrinterPackageInstallation.amd64]
PackageAware=TRUE

If you decide to edit the INF file, it'll be easier to remove the driver from the print server, edit the INF file from a clean download, and then install the edited driver.

Aside from this, double check the Group Policy settings for Point and Print Restrictions and Package Point and print - Approved Servers.

Background Info

Microsoft Security Bulletin MS16-087 detailed a security issue where a rogue print server could inject malicious code through a "man in the middle" style attack. Security update KB3170455 was issued on July 12, 2016 to fix it, which then messed with the distribution of print drivers from the print server.

Solution 2

Thanks for the registry hack to get a driver come up as packaged. That alone may not do the trick. Please ensure that you set the Computer policy Package and print settings to enabled along with the print server concerned.

1. Above registry hack on print server if your driver shows up as "false" in the packaged column of Print manager on the server.
2. Comp config -> admin templates -> point and print restrictions enabled.

Hope this helps.

Comments

[Davidw]

Have you taken a look at this question? social.technet.microsoft.com/Forums/windows/en-US/…

[Arvo Bowen]

@Davidw I did just notice this though!... "These settings have been moved to the Local_Machine hive for Windows 7. You need to use a Windows 7 machine to manage the two sets of policies (Machine for Windows 7, User for Pre-Windows 7)" from another answer... How would I manage it from the local machine via GPO? I'm guessing it's just a registry setting but what registry setting?

[Noor Khaldi]

Reading through your question, I'm leaning toward the idea that your printer drivers are the cause of this problem, if you have to install the printer at least once for it to work, I'd sure try to change the drivers and try again. The "Do you trust this printer" dialog will not stop you from installing the printer using GP.

[Arvo Bowen]

@NoorKhaldi I think it has to do with two things... 1) The drivers are not signed...! 2) The drivers I'm trying to install do not seem to be a simple HP Laserjet type driver to install for a network printer... These drivers create a special new type of port for printing/generating PDFs... What a pain...

[Thomas]

A "Me too!" response. I've tried all of the same troubleshooting. I thought it might be related to driver signing, but I disabled "Only use Package Point and Print" and set "Code signing for device drivers" to "ignore" with no effect. Is there a way to pre-stage the drivers on workstations via group policy? Has anyone with this problem tried setting up an old-fashioned network driver store?

[crysman]

I've posted the workaround here serverfault.com/questions/1075399/…

[P.Turpie]

If Step 4 seems weird, it's because PrinterDriverAttributes is actually a bit array where each bit indicates a different setting. The last bit (least significant) indicates whether the driver is part of a driver package. So incrementing the value by one will modify the last bit in the field. See: msdn.microsoft.com/en-us/library/windows/desktop/…

[George Erhard]

From a systems admin point of view, this is the way to go. It does involve considerable prep and vetting on the print server, but that's because we admins are supposed to be aware of what's deployed, what poses a danger, et cetera. However, once the print server has the drivers pre-staged, any client systems that attach to the printer will be able to install the drivers in the background, with no UAC checkpoints.

[Thomas]

Note that you can restart just the "Server" service on the print server and it will update with the new settings without rebooting the server.. Restarting this service may have other repercussions, but may be a better solution than rebooting the server for some admins.