none
KB3163912 breaks Point and Print Restrictions GPO settings

    Question

  • Our labs install our printers through a simple Start Menu\Programs\Startup VBS script that points to a printer depending on the machine name.  This saves anywhere from 1-5 minutes from our login times.

    This morning after the new cumulative update KB3163912 all our lab machines are now prompting for admin credentials to install these print drivers.

    I have changed the Point and Print Restrictions section of our GPO to both "disabled" and "enabled" but without server restrictions, and disabling elevation prompts.  Neither take any effect.

    After removing KB3163912 the printers install fine without any prompts.

    We can add our printers back to the typical GPO location for now, but no doubt we will receive complaints on our login times increasing.

    GPResults show our group polices are processing fine on machines that are both pre and post KB3163912.

    Wednesday, July 13, 2016 8:10 PM

Answers

  • This tweak will get your Canon, Sharp og KonicaMinolta printers up and running again by making the drivers Package Aware.

    Edit the register on your print server(s). If you change the value of the key PrinterDriverAttributes under HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windowsx64\Drivers\...\Driver name\ and restart the print server, you are able to make Windows treat the driver as packaged, and it will install unattended with gpo. The hex number has to be odd. To keep the original settings for the printer driver and only make it Pakage aware you shold add 1 to the original value of PrinterDriverAttributes. In my print enviroment the original attribute had the value 4, so I changed it to 5 and that made it Pakage aware. Different versions of the driver (and different vendors) might need other values.
    Restart server .

    According to MS the 1 flag for PrinterDriverAttributes stands for PRINTER_DRIVER_PACKAGE_AWARE. This will treat the driver as package aware, which means a CAB package will be created, including the inf and the catalog. The package will be installed through setupapi.dll when installing the driver, validating that the catalog is trusted, and that hashes for all files are included in the catalog.

    BTW: This is not a Microsoft problem, but a printer vendor problem! Two lines of code in the *.inf file will make the driver Package aware and fix the problem properly! Solution for vendors posted by Microsoft here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559698(v=vs.85).aspx

    PS: Posted this on Google+ and LinkedIn under the name Grei_70

    • Proposed as answer by sp00ler_n00b Thursday, August 18, 2016 1:48 PM
    • Marked as answer by dsuit Thursday, August 18, 2016 4:40 PM
    Thursday, August 18, 2016 1:46 PM
  • Alright folks, I've found a workaround that has us back up and running.  We've started using a rundll32 procedure for manually installing our shared printer drivers at machine startup.  This method does not use Point and Print and will work when run by the SYSTEM account.

    Once the workstation has been logged in, our login script points to the printer and sets it as default.  Since the driver is already installed at machine startup, the user is not prompted.  I believe this only needs to be done for non-packaged drivers.  This will work for Group Policy Preferences Printers as well as any custom scripts.

    Here is the process:

    1)  On the print server, open Administrative Tools > Print Managment
    2)  Under "All Drivers" identify which unpackaged driver(S) you wish to install.

    3)  Open the location under "Inf Path" (C:\Windows\System32\DriverStore\FileRepository) and copy the entire directory over to your test machine.  I renamed each folder with the proper name specified under Driver Properties.  This is the exact name specified in the INF file, which we will need point to later. Be sure you are getting the correct architecture - it does matter if your workstations are 32 or 64-bit.


    4)  Identify the name of the INF file inside the folder.  Because we copied this from the DriverStore directory there should only be one INF file.


    5)  Here is a sample of my install.cmd script from our printer GPO, located inside the "PrintDrivers" directory:


    SET "NAME=SHARP MX-M283N PCL6"
    
    SET "INF=sr0emenu.inf"
    
    ECHO Installing %NAME%...
    
    START rundll32 printui.dll,PrintUIEntry /ia /m "%NAME%" /f "%~dp0x64\%NAME%\%INF%"
    
    PING 127.0.0.1 -n 05>NUL

    Setting a couple variables helps to simplify adding multiple printers.  Just change the NAME variable to the proper driver name shown in the driver properties, and the INF variable to the name of the .inf file.  You may also need to edit the path shown after the "/f" switch.  I name each driver folder the same proper name shown in the driver's properties, and sort each folder according to its architecture (x64/x86).

    Using START ensures that if there is a problem installing one driver the script continues on with the other printers.  I have had some printers occasionally fail, so it may take a couple restarts to get everything.

    Ping is just adding a 5 second pause between drivers.  Once the drivers are installed they will be skipped on subsequent reboots.


    Run the script on a test computer before you copy it over to a GPO's "Startup Script" section - Computer Configuration > Policies > Windows Settings > Scripts > Startup

    Depending on how quickly you login, you may be able to see rundll32 running in the background as it installs the printer drivers in Task Manager.

    EDIT:

    You still need to make the necessary GPO changes to allow Point and Print without prompting:

    Computer Configuration > Policies > Admin Templates > Printers > Point and Print Restrictions

    User Configuration > Policies > Admin Templates > Control Panel > Printers > Point and Print Restrictions

    I have them both set to these settings:

    • Edited by dsuit Thursday, August 04, 2016 8:05 PM
    • Marked as answer by dsuit Friday, August 12, 2016 6:52 PM
    Wednesday, July 27, 2016 6:11 PM
  • OK. Found the answer. The solution provided by dsuit is working as expected.

    The printer I am deploying is an HP LaserJet P1505n. I was using the latest version of the driver that HP Provides. (ver. 8.0.1.20392 - released 04/27/2010)

    Just for kicks, I looked to see if there was one available from Microsoft Update, and lo and behold, there is. (ver. 1.0.2.2680 - released 04/15/2013)

    The newer one is a Marvell driver.

    So, with luck, a different, newer version of the driver may well solve anyone else's problem.

    Alan Shoop

    • Marked as answer by dsuit Tuesday, August 16, 2016 4:51 PM
    Monday, August 15, 2016 8:04 AM
  • Just heard back from Microsoft on the issue.

    Their official fix for the problem is to obtain updated drivers from vendors.  Supposedly most unpackaged drivers are now available in a packaged format.

    I'm going to mark my workaround as the solution to the issue for now.


    • Marked as answer by dsuit Friday, August 12, 2016 6:53 PM
    • Edited by dsuit Tuesday, August 16, 2016 4:51 PM
    Friday, August 12, 2016 6:52 PM

All replies

  • Hi,

    Thanks for your post.

    Does this issue happen to all clients?


    So if you add printers back to the typical GPO location instead of using VBS script points to a printer, Point and Print Restrictions works properly even after applying KB 3163912, right?

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, July 14, 2016 6:20 AM
    Moderator
  • Yes, it is only prompting for the initial driver installation. 

    Our labs use DeepFreeze, so many of the computers will not have the print drivers installed after a reboot.

    We are hoping to not have to thaw and log-in to hundreds of computers to resolve the issue.

    Thursday, July 14, 2016 4:50 PM
  • After further investigation, it appears our Intranet Zone sites are not applying even though the GPO is applying correctly.

    I'm wondering if IE11 now requires these settings to be applied in a different location in the GPO?  

    Thursday, July 14, 2016 6:36 PM
  • It looks like after the update IE11 is pulling the "Site to Zone Assignment List" from the Computer Configuration instead of User Configuration.

    However the Point and Print setting is only located under the User portion, and it still does not work even after adding our local intranet zones to the computer configuration.  I have verified by checking the control panel after the change was made.

    Is there any other way to bypass the point and print restriction if the GPO is not correctly handling it?

    Thursday, July 14, 2016 8:36 PM
  • I should also add that we have recently updated our ADMX templates, just a week ago, so all Admin Templates should be present.

    I believe this is an oversight on Microsoft's part, and the Point and Print restriction setting needs to be added under Computer Configuration, as it looks like after the update IE11 is pulling from this side instead of the User Configuration where it previously pulled from.

    Thursday, July 14, 2016 8:55 PM
  • your screenshot and the KB3163912, apply to Win10, so I assume it's Win10 where you're seeing this issue?

    Point and Print Restrictions don't have any involvement by IE nor IE zones, AFAIK.

    GP Admin Templates, are not involved in the processing of GP at all - template re only used for authoring settings into a GP via GPMC/GPME/GPedit, and, templates are used for rendering GPResult/RSoP info - not used for processing settings.

    https://blogs.msdn.microsoft.com/7/2011/07/11/allowing-standard-users-to-install-network-printers-on-windows-7-without-prompting-for-administrative-credentials/ shows that both Computer Configuration and User Configuration are applicable, and always have been so..?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, July 14, 2016 9:27 PM
  • Yes, you are correct, I was mistaken about the computer configuration side.  That does exist.  However it is set the same as our user side - point and Print restrictions are disabled.  Yet, they still exist.
    Thursday, July 14, 2016 9:53 PM
  • Literally the only method I've found of fixing this is by removing KB3163912 or using the typical Printers location in our GPO's.  Seems like a large oversight by Microsoft.

    The main problem with removing the KB is obviously it leaves systems vulnerable.  

    Thursday, July 14, 2016 10:16 PM
  • Sounds like you'll need to log a support case.

    I'm not using any LTSB nor TH1/10240 Win10 systems (we are all on TH2/10586) and so far nobody has reported this through to me. I've not had a chance this week to see if TH2/10586 is affected by the equivalent CU (KB3172985)

    EDIT: having said that, I did notice a 'consent' dialog today, on a Win7-x64 machine, when connecting via Point & Print. Maybe a similar regression has crept in there...


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Friday, July 15, 2016 8:53 AM
    Friday, July 15, 2016 8:51 AM
  • Hey sounds like we could be having the same issue.

    This is my post on the issue.

    https://social.technet.microsoft.com/Forums/en-US/00f92279-18fb-4065-853d-12f9cd402268/printer-gpo-and-kb3172985?forum=win10itprogeneral

    --------

    Since this kb3172985 update was installed it appears to have "Broke" GPOs used for printing.  We have added authenticated user and domain computers to the GPO and enabled point and print drivers with do not show warning or elevation prompt.  However in the event log when we run a GPupdate /force it says it cannot download the drivers, gives the error code 0X80070bcb.  I can uninstall kb3172985 and the GPO works with no issue.  We are also seeing the similar issue on windows 7.  

    Can any one suggest something that we may have not have tried yet?

    Thanks.

    Friday, July 15, 2016 8:32 PM
  • Sounds very similar, although I've attributed it to KB3163912 rather than KB3172985.  I'll have to try removing KB3172985 to see if it also fixes our Point and Print issue.  It might be a problem with both CU's.

    We have just setup a traditional printer GPO that loads at login, and it looks to be working on most of our workstations.  However I have found some it is not, but haven't had time to look into it.

    I've also tried moving our Point and Print script to machine startup so it's run directly by SYSTEM.  However it just hangs in the background, no doubt because of the new restrictions set by the CU's.

    Friday, July 15, 2016 9:59 PM
  • Sounds very similar, although I've attributed it to KB3163912 rather than KB3172985.  I'll have to try removing KB3172985 to see if it also fixes our Point and Print issue.  It might be a problem with both CU's.

    We have just setup a traditional printer GPO that loads at login, and it looks to be working on most of our workstations.  However I have found some it is not, but haven't had time to look into it.

    I've also tried moving our Point and Print script to machine startup so it's run directly by SYSTEM.  However it just hangs in the background, no doubt because of the new restrictions set by the CU's.

    Same here, uninstalling KB3172985 solves the problem
    • Edited by hardcrack Monday, July 18, 2016 11:15 AM
    Monday, July 18, 2016 11:05 AM
  • I too can confirm that this issue also exists in Windows 7 x64.

    It appears to only effect printers that use drivers that are "non-packaged" i.e. Print Management -> Drivers -> Packaged column false

    KB3170455 is the KB that needs to be removed in Windows 7



    Monday, July 18, 2016 4:02 PM
  • I have this issue as well in Win 8.1 x64 Pro and Win 10 x64 Pro.

    My experience is the same as yours, only affects non-packaged drivers and when I removed KB3170455 Point and Print GPO started working again. Haven't tried in Windows 10 yet.

    This is a quite annoying problem...
    Tuesday, July 19, 2016 4:07 PM
  • We have submitted a ticket with Microsoft and I will keep you guys posted on any progress we make.
    Tuesday, July 19, 2016 5:17 PM
  • I am having the same issue. Point and print restrictions are ignored after applying KB3170455 (Win7) or KB3163912 (Win10).
    It does not affect all printers. The printers with "packaged" drivers work without any Problems.
    With non packeged drivers the "do you trust this printer" dialogue pops up.
    When the GPO is activated, it is possible to press install on this dialogue and the printer installes without admin rights. With the GPO disabled it should also work, but it does not.
    Did you get any update on this issue from Microsoft?

    Thursday, July 21, 2016 3:02 PM
  • Hello.

    Same issue here at our company.
    Our newly installed Windows10 machines just ignore the GPO, which worked  2 weeks ago.

    Started to investigate and find this thread instantly with short time-range search.
    Definitely the updates at july12 are causing this malfunction.

    Hope some fix comes out asap.

    Friday, July 22, 2016 9:02 AM
  • I'm pretty sure it's because of this...

    http://blog.vectranetworks.com/blog/microsoft-windows-printer-wateringhole-attack

    MS just patched it.  

    Friday, July 22, 2016 3:27 PM
  • We do have same problem here with non-packaged drivers ( like Canon).


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help.

    Friday, July 22, 2016 4:21 PM
  • Definitely - but it's not 100% clear in the linked bulletin, whether the behaviour in ignoring the administrative setting "Do not show warning..." is supposed to have changed, as is being observed.

    /update

    There's a post on the reddit thread for this issue, which is mirroring what I'm seeing, and worryingly for some, it looks like this is now by design:

    https://www.reddit.com/r/sysadmin/comments/4stcdo/kb3170455_stops_nonadmin_users_from_installing_a/d5kmbsi?st=ir24mvpw&sh=310ecc21

    "If you have this KB3170455 installed, non-packaged Printer Drivers IGNORE point and print settings. This means that users mapping the printer manually will get a prompt no matter how your point and print is configured."

    In the environment I'm testing against, it seems like all of the Canon print drivers for their "ImageRunner Advanced" fleet of devices are non-packaged, and there aren't packaged ones available, which screws things up quite a bit.


    • Edited by Sizzl Monday, July 25, 2016 3:17 PM
    Monday, July 25, 2016 10:47 AM
  • This issue has been escalated to the Microsoft Product Team.  I'm hoping they'll have a fix soon.

    Their only suggestion was to add the entire domain "*.mydomain" to the accepted print servers list in the GPO.  This doesn't work, it just automatically ignores any point-and-print drivers rather than prompting for them.

    Tuesday, July 26, 2016 4:42 PM
  • Alright folks, I've found a workaround that has us back up and running.  We've started using a rundll32 procedure for manually installing our shared printer drivers at machine startup.  This method does not use Point and Print and will work when run by the SYSTEM account.

    Once the workstation has been logged in, our login script points to the printer and sets it as default.  Since the driver is already installed at machine startup, the user is not prompted.  I believe this only needs to be done for non-packaged drivers.  This will work for Group Policy Preferences Printers as well as any custom scripts.

    Here is the process:

    1)  On the print server, open Administrative Tools > Print Managment
    2)  Under "All Drivers" identify which unpackaged driver(S) you wish to install.

    3)  Open the location under "Inf Path" (C:\Windows\System32\DriverStore\FileRepository) and copy the entire directory over to your test machine.  I renamed each folder with the proper name specified under Driver Properties.  This is the exact name specified in the INF file, which we will need point to later. Be sure you are getting the correct architecture - it does matter if your workstations are 32 or 64-bit.


    4)  Identify the name of the INF file inside the folder.  Because we copied this from the DriverStore directory there should only be one INF file.


    5)  Here is a sample of my install.cmd script from our printer GPO, located inside the "PrintDrivers" directory:


    SET "NAME=SHARP MX-M283N PCL6"
    
    SET "INF=sr0emenu.inf"
    
    ECHO Installing %NAME%...
    
    START rundll32 printui.dll,PrintUIEntry /ia /m "%NAME%" /f "%~dp0x64\%NAME%\%INF%"
    
    PING 127.0.0.1 -n 05>NUL

    Setting a couple variables helps to simplify adding multiple printers.  Just change the NAME variable to the proper driver name shown in the driver properties, and the INF variable to the name of the .inf file.  You may also need to edit the path shown after the "/f" switch.  I name each driver folder the same proper name shown in the driver's properties, and sort each folder according to its architecture (x64/x86).

    Using START ensures that if there is a problem installing one driver the script continues on with the other printers.  I have had some printers occasionally fail, so it may take a couple restarts to get everything.

    Ping is just adding a 5 second pause between drivers.  Once the drivers are installed they will be skipped on subsequent reboots.


    Run the script on a test computer before you copy it over to a GPO's "Startup Script" section - Computer Configuration > Policies > Windows Settings > Scripts > Startup

    Depending on how quickly you login, you may be able to see rundll32 running in the background as it installs the printer drivers in Task Manager.

    EDIT:

    You still need to make the necessary GPO changes to allow Point and Print without prompting:

    Computer Configuration > Policies > Admin Templates > Printers > Point and Print Restrictions

    User Configuration > Policies > Admin Templates > Control Panel > Printers > Point and Print Restrictions

    I have them both set to these settings:

    • Edited by dsuit Thursday, August 04, 2016 8:05 PM
    • Marked as answer by dsuit Friday, August 12, 2016 6:52 PM
    Wednesday, July 27, 2016 6:11 PM
  • although we're apparently not affected by this (at the moment), I've raised the matter of a lack of package-aware drivers with my contact at Canon (we use Canon iR-ADV devices exclusively in our corp), and I've sent him the link to this thread.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Wednesday, July 27, 2016 9:10 PM
    Wednesday, July 27, 2016 9:10 PM
  • Windows XP
    With Windows XP, there was no device driver method for Printer Drivers. Network Printers provided a \\server\print$\W32X86\3  or \\server\print$\x64\3 folder and drivers would be copied directly from there to C:\Windows\System32\spool\drivers\W32X86\3 or C:\Windows\System32\spool\drivers\x64\3 
    Only administrators could install drivers and the drivers had to be installed first on the machine if non-admin users were to use any printers.

    Windows7
    With Windows 7, Microsoft switched the way they deployed drivers. They made Printer Drivers the same as any other device driver and when you connected to \\server\print$ the computer would be directed instead to \\server\print$\x64\PCC and would extract and install the SIGNED CAB device drivers in to C:\Windows\System32\DriverStore\FileRepository. From there Windows would install the Driver as a “device driver” and place the proper files into C:\Windows\System32\spool\drivers respective subfolders.

    With this new method they gave the “point to print” option so non-administrators could still install drivers into the above File Repository.

    However, in the above scenario there was quite a big security flaw. IF the drivers were signed then Windows would happily install the device drivers into the driver store, however if they were NOT signed, then Windows would simply switch back to the ”Windows XP” way of doing things and skip the Device Driver installation entirely and simply install the files directly into the C:\Windows\System32\spool\drivers folder.

    It is because of this security flaw that unsigned printer device drivers have been appeared to be working fine, when actually they were really only ½ installed. We saw this with a newly imaged machine before installing the KB3170455 MS16-087. If we connected to \\server\printername, it would install the printer drivers into the C:\Windows\System32\spool\drivers folder but would not install the actual driver package into C:\Windows\System32\DriverStore\FileRepository. This would leave us with a semi-installed state.

    Microsoft released KB3170455 MS16-087 to patch the security flaw.

    Therefore you HAVE to have signed printer drivers install on all your print servers.

    The issue arrises when server software modifies the cfg file as is in the case with HP. If you touch hpcpuXXX.cfg to set custom configuration it flags the driver immediately as "unsigned" and won't install.

    Note even administrators can't install unsigned printer drivers IF you have the machines set to not allow unsigned drivers as is the case with Windows 10.


    lforbes

    Friday, July 29, 2016 5:17 PM
  • It is not Point and Print that is broken. Even administrators can't install unsigned printer server drivers after KB3170455 which is a patch included in KB3163912.

    lforbes

    Friday, July 29, 2016 5:21 PM
  • It is not Point and Print that is broken. Even administrators can't install unsigned printer server drivers after KB3170455 which is a patch included in KB3163912.

    lforbes

    The problem mentioned in this thread is not with unsigned drivers, it's with unpackaged drivers.  Point and Print is not broken but its behavior has changed to the point where the previous GPO settings controlling its behavior do not work.

    Prior to the aforementioned CU unpackaged drivers installed silently without elevation, given the correct settings were setup in a GPO.  Now they require elevation and will not install silently regardless of the GPO settings.

    By installing the drivers manually through rundll32 like my previous post you can get around this issue, and a regular user can connect to a shared printer without elevation or prompt, because the drivers are already installed at boot through rundll32 which does not use Point and Print.

    Friday, July 29, 2016 10:26 PM
  • We have this problem too and I have opened a premier case.  Microsoft acknowledges the problem. Strangely, for us, the user is able to add printers that are new, but are not able to update drivers for affected printers.

    For instance Minolta Bizhub printers.  The prinyt server team updated the drivers on the print server for these devices.  Normally, the next time a user attempted to print to these printers, if they already had added the printer, their computers would update the drivers automatically by silently downloading the drivers and installing them. Post KB3170455, the users are prompted to update, and the update fails.  Users on these machines ARE able to remove the printer from the devices control panel, and then use the "Add a printer" button to re-add the printer.  The computer prompts for trusting the printer (which it did not do previously) and the user can affirm the add - and the driver will download and install.  So installing new or delete and re-installing works for our particular printer, but the update/upgrade driver process for existing unpackaged driver printers is broken.   

    Monday, August 01, 2016 2:22 PM
  • dsuit - Thanks for posting the workaround. I tried that in our environment but unfortunately it did not work. I confirmed that the driver package was installed after using the rundll32 method by looking on the Drivers tab of the Print Server Properties on one of our workstations. But when I tried to then connect to the network queue, I got the prompt still.

    Unfortunately, we have an even greater problem starting late this afternoon. Workstations that ALREADY had the non-packaged drivers installed got the security prompt when they initiated a print to the printer. I hadn't seen that before and it's going to be a nightmare tomorrow as I haven't been able to find another workaround tonight.

    Tuesday, August 02, 2016 6:20 AM
  • Hi,

    I am sorry that this issue still hasn't been resolved.

    If there is no progress, I would suggest you contact Microsoft Customer Services and Support to get an efficient solution:

    http://support.microsoft.com/contactus/?ln=en-au

    Have a nice day!

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, August 03, 2016 7:27 AM
    Moderator
  • Basically.. As usual.. M$ f***d up and created additional workloads for IT people.. At first we have to dig around whats wrong for some days.. and after that we will find out that there are some massively affecting changes introduced... and no viable or easy solutions.

    Today I'v deployed our first Windows 10 1607 and found that our GPO's are unable to deploy any more unpackaged Canon drivers.

    Group Policy was unable to add per computer connection \\SERVERNAME\CanonXXX. Error code 0xBCB. This can occur if the name of the printer connection is incorrect, or if the print spooler cannot contact the print server.


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help.

    Thursday, August 04, 2016 10:15 AM
  • dsuit - Thanks for posting the workaround. I tried that in our environment but unfortunately it did not work. I confirmed that the driver package was installed after using the rundll32 method by looking on the Drivers tab of the Print Server Properties on one of our workstations. But when I tried to then connect to the network queue, I got the prompt still.

    Unfortunately, we have an even greater problem starting late this afternoon. Workstations that ALREADY had the non-packaged drivers installed got the security prompt when they initiated a print to the printer. I hadn't seen that before and it's going to be a nightmare tomorrow as I haven't been able to find another workaround tonight.

    Did you also make the necessary changes in your GPO?  There are two locations to disable the Point and Print installation prompt, in computer and user:

    Computer Configuration > Policies > Admin Templates > Printers > Point and Print Restrictions

    User Configuration > Policies > Admin Templates > Control Panel > Printers > Point and Print Restrictions

    I have them both set to these settings:

    Now that the drivers are already installed at system startup, we are no longer prompted.

    Thursday, August 04, 2016 8:03 PM
  • Sven, please try the Rundll32.exe method I listed above.  It's some extra work, but it did resolve the issue for us.
    Thursday, August 04, 2016 8:07 PM
  • I'm inclined to think that Your suggested workaround will help. But it's the matter of principles. We pay every year thousand of $'s and what we get? Some broken infrastructure... Thats okay, if there's some minor bugs here and there..but this kind of BS... Who will be responsible that settings specified in GPO that should work, will not work? Is there any quality testing in MS?

    Nevermind.. I'm pissed off..Every couple of weeks MS surprises me again and again..CFO asks why the hell the IT dept. takes about few days to get printers deployed. Just printers..simple as that.It's wasted time=money and we should pay that money not Microsoft..


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help.

    Thursday, August 04, 2016 9:32 PM
  • I agree completely.  The whole thing is pretty ridiculous.  We just had no choice but to get it working for our thousands of students that need to be able to print.
    Thursday, August 04, 2016 11:23 PM
  • The problem is way worse on Windows 10 because there is no way to remove the KB that breaks printing without removing the rest of the July updates.  At least in older OSes the updates are each distinct units. 

    Friday, August 05, 2016 7:38 PM
  • Does the “Known issue” section of KB 3170005 provide any relief(use package aware, signed drivers with complete catalogs)?

    KB 3170005: MS16-087: Security update for Windows print spooler components: July 12, 2016

    The printer hardening fixes may cause a 2nd problem where print queues are visible if viewed remotely, or locally via UNC path like \\<servernme> but NOT locally from the Printer Management snap-in.


    Problem was resolved by installing KB 3000850 November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

    Friday, August 05, 2016 10:40 PM
  • We are seeing some success with this workaround:

    1) Package the drivers in an MSI via ORCA https://sccmentor.com/2013/06/10/creating-printer-driver-installs-for-sccm-deployment/comment-page-1/

    2) Once the drivers are in the local store, execute PowerShell command "add-printerdriver."

    ex. Add-PrinterDriver -Name "HP Universal Printing PCL 6" -InfPath "C:\Install\HP\hpcu160u.inf"

    You might be able to simplify #1 with a VBscript calling pnputil, but we wanted to go the MSI route to use with SCCM.  Once the drivers are installed to the local machine, subsequent methods of user-driven print queue installs (e.g. GPO, etc.) will not invoke the "Trust" warning and complete successfully.

    We are deploying this for a school distict environment that has 4800 printers, 38,000 machines, 95,000 users.  With classes starting up again in less that three days, this marks the second major disruption in less than two months to normal business operations, the first being the Group Policy processing change in ms16-072-1627.  Given the education budgetary climate and aggressive suitors like Google and Apple at the gates, advocating for Microsoft is a hard enough job already in itself. Let's hope for all our sakes someone high enough up in Redmond is paying attention and can recognize the glaring need for significant change in the communication and QA for product updates. 



    heuristik

    Monday, August 08, 2016 5:17 AM
  • For 38K machines I can definitely see how SCCM would be the way to go.  You still might want to look at a GPO based install, knowing that sometimes SCCM isn't able to reach every single workstation. I'm betting PowerShell's "Add-Printer-Driver" utilizes the same rundll32 process for installing printer drivers.  

    Monday, August 08, 2016 5:17 PM
  • heuristik, I have completed step one in packaging the driver into a single MSI for deployment. Once you load that MSI, what path does it store the driver in so I can reference it when using Step 2?  The directions from step one don't indicate that.

    Thanks in advance.

    Monday, August 08, 2016 8:14 PM
  • Thanks for the info! You mentioned some success, I am still getting the UAC prompt for a printer even though the Driver is in the local store. Have you had certain printers that this has not worked for?
    Tuesday, August 09, 2016 3:24 PM
  • I too am not having any luck getting around the prompts. I have tried multiple ways of preinstalling a canon driver, but it only seems to work if the driver is already installed from the print server.
    Tuesday, August 09, 2016 4:08 PM
  • Thanks for the info! You mentioned some success, I am still getting the UAC prompt for a printer even though the Driver is in the local store. Have you had certain printers that this has not worked for?

    I haven't had any fail for me.  We have multiple Canon and Sharp copiers with unpackaged drivers and all of them have worked so far.

    Have you setup a GPO to remove the prompt?  You will need to set that or it will still prompt even if the driver is installed.

    Also, have you verified that the driver is installed on the local machine?  You can see the print drivers installed here:

    Administrative tools > Print Management > All Drivers

    If it does not show in that list, then you will want to double check your installation script to make sure your syntax is correct.

    Tuesday, August 09, 2016 8:49 PM
  • Odd. I am trying to work with a Zebra driver.

    GPO is set to remove the prompt. (Other printers don't prompt)

    The print driver is listed under All Drivers.

    It seems that it still wants to get the driver from the print server even though it is installed. I have to be missing something. The search continues...

    Wednesday, August 10, 2016 4:30 PM
  • Don, have you heard anything yet from your Canon rep as to how they're addressing this on their end?
    Wednesday, August 10, 2016 4:47 PM
  • Odd. I am trying to work with a Zebra driver.

    GPO is set to remove the prompt. (Other printers don't prompt)

    The print driver is listed under All Drivers.

    It seems that it still wants to get the driver from the print server even though it is installed. I have to be missing something. The search continues...

    That is strange.  If you check the driver installation directory, are there multiple INF files?  I'm wondering if you are installing a different driver than what is needed.
    Wednesday, August 10, 2016 5:20 PM
  • That is strange.  If you check the driver installation directory, are there multiple INF files?  I'm wondering if you are installing a different driver than what is needed.

    Only 1 INF from what I can tell. I only have one other printer that is a non-packaged driver. For a test, I ran my script against that printer and it worked without issue. So it is defiantly a problem with this Zebra driver. I made sure to use the latest version available. My hunch says that you are right. There has to be another INF somewhere that it needs. I will keep looking.
    Wednesday, August 10, 2016 5:55 PM
  • That is strange.  If you check the driver installation directory, are there multiple INF files?  I'm wondering if you are installing a different driver than what is needed.

    Only 1 INF from what I can tell. I only have one other printer that is a non-packaged driver. For a test, I ran my script against that printer and it worked without issue. So it is defiantly a problem with this Zebra driver. I made sure to use the latest version available. My hunch says that you are right. There has to be another INF somewhere that it needs. I will keep looking.
    I would try confirming the driver installation on a client machine, and then copy the drivers after it installs them for other clients.
    Wednesday, August 10, 2016 9:11 PM
  • Just heard back from Microsoft on the issue.

    Their official fix for the problem is to obtain updated drivers from vendors.  Supposedly most unpackaged drivers are now available in a packaged format.

    I'm going to mark my workaround as the solution to the issue for now.


    • Marked as answer by dsuit Friday, August 12, 2016 6:53 PM
    • Edited by dsuit Tuesday, August 16, 2016 4:51 PM
    Friday, August 12, 2016 6:52 PM
  • Whats that for a Solution? Thats really only a Workaround but no Solution?!???!?!?
    Sunday, August 14, 2016 10:04 AM
  • Thanks for the detailed workaround.

    My situation is similar to jdmac.

    I am trying to apply this to Windows 7 64 bit systems to no avail. I have verified that your workaround does indeed install the drivers on the client PC as expected. They are visible in PrintManagement with exactly the same names as are on the print server. They are installed to C:\Windows\System32\DriverStore\FileRepository as well as in C:\Windows\System32\spool\drivers\x64\3.

    I have a GPP that then tries to load the shared printer.

    It still fails with 0x80070bcb (The specified printer driver was not found on the system and needs to be downloaded)

    The GPP works fine for all printers with packaged drivers.

    If I try a manual install, I am still presented with a “do you trust this printer” prompt. If I answer Yes, the printer installs just fine.

    Following that, If I manually remove the printer, the GPP will re-deploy the printer the way it is supposed to in the first place.

    Has anyone else been able to get this to work in Windows 7?

    Alan Shoop

    Monday, August 15, 2016 1:46 AM

  • I have a GPP that then tries to load the shared printer.

    It still fails with 0x80070bcb (The specified printer driver was not found on the system and needs to be downloaded)

    The GPP works fine for all printers with packaged drivers.

    If I try a manual install, I am still presented with a “do you trust this printer” prompt. If I answer Yes, the printer installs just fine.

    No help to, but I have this exact situation but with windows 10 workstations.
    Monday, August 15, 2016 5:11 AM
  • As per https://support.microsoft.com/en-us/kb/3170005, update to packaged drivers or preinstall the drivers on the computers. This is Microsofts answer, not very helpful as usual and us the customer will have to find our own workarounds/solutions.

    Again another (Group Policy) poorly communicated change that's affecting enterprise users.

    Ben

    Monday, August 15, 2016 5:42 AM
  • OK. Found the answer. The solution provided by dsuit is working as expected.

    The printer I am deploying is an HP LaserJet P1505n. I was using the latest version of the driver that HP Provides. (ver. 8.0.1.20392 - released 04/27/2010)

    Just for kicks, I looked to see if there was one available from Microsoft Update, and lo and behold, there is. (ver. 1.0.2.2680 - released 04/15/2013)

    The newer one is a Marvell driver.

    So, with luck, a different, newer version of the driver may well solve anyone else's problem.

    Alan Shoop

    • Marked as answer by dsuit Tuesday, August 16, 2016 4:51 PM
    Monday, August 15, 2016 8:04 AM
  • What I don't get is if I add the driver using printui, it fails. But if I browse to the server and connect to the printer it somehow magically transform the exact same driver into one that works.
    Tuesday, August 16, 2016 12:01 AM
  • This tweak will get your Canon, Sharp og KonicaMinolta printers up and running again by making the drivers Package Aware.

    Edit the register on your print server(s). If you change the value of the key PrinterDriverAttributes under HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windowsx64\Drivers\...\Driver name\ and restart the print server, you are able to make Windows treat the driver as packaged, and it will install unattended with gpo. The hex number has to be odd. To keep the original settings for the printer driver and only make it Pakage aware you shold add 1 to the original value of PrinterDriverAttributes. In my print enviroment the original attribute had the value 4, so I changed it to 5 and that made it Pakage aware. Different versions of the driver (and different vendors) might need other values.
    Restart server .

    According to MS the 1 flag for PrinterDriverAttributes stands for PRINTER_DRIVER_PACKAGE_AWARE. This will treat the driver as package aware, which means a CAB package will be created, including the inf and the catalog. The package will be installed through setupapi.dll when installing the driver, validating that the catalog is trusted, and that hashes for all files are included in the catalog.

    BTW: This is not a Microsoft problem, but a printer vendor problem! Two lines of code in the *.inf file will make the driver Package aware and fix the problem properly! Solution for vendors posted by Microsoft here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559698(v=vs.85).aspx

    PS: Posted this on Google+ and LinkedIn under the name Grei_70

    • Proposed as answer by sp00ler_n00b Thursday, August 18, 2016 1:48 PM
    • Marked as answer by dsuit Thursday, August 18, 2016 4:40 PM
    Thursday, August 18, 2016 1:46 PM
  • This tweak will get your Canon, Sharp og KonicaMinolta printers up and running again by making the drivers Package Aware.

    Edit the register on your print server(s). If you change the value of the key PrinterDriverAttributes under HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windowsx64\Drivers\...\Driver name\ and restart the print server, you are able to make Windows treat the driver as packaged, and it will install unattended with gpo. The hex number has to be odd. To keep the original settings for the printer driver and only make it Pakage aware you shold add 1 to the original value of PrinterDriverAttributes. In my print enviroment the original attribute had the value 4, so I changed it to 5 and that made it Pakage aware. Different versions of the driver (and different vendors) might need other values.
    Restart server .

    According to MS the 1 flag for PrinterDriverAttributes stands for PRINTER_DRIVER_PACKAGE_AWARE. This will treat the driver as package aware, which means a CAB package will be created, including the inf and the catalog. The package will be installed through setupapi.dll when installing the driver, validating that the catalog is trusted, and that hashes for all files are included in the catalog.

    BTW: This is not a Microsoft problem, but a printer vendor problem! Two lines of code in the *.inf file will make the driver Package aware and fix the problem properly! Solution for vendors posted by Microsoft here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559698(v=vs.85).aspx

    PS: Posted this on Google+ and LinkedIn under the name Grei_70

    From my testing this does not work for GPP when mapping to a Shared Printer.  Yes setting the value in registry marks the Packaged field as True for the driver in Print Management, however it still throws the Warning message in the event log on the pc trying to map to it about the printer not being present on the system, and if I browse to the share manually and try to connect it still prompts me for if I want to trust the driver.
    Tuesday, August 23, 2016 4:45 PM
  • This tweak will get your Canon, Sharp og KonicaMinolta printers up and running again by making the drivers Package Aware.

    Edit the register on your print server(s). If you change the value of the key PrinterDriverAttributes under HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windowsx64\Drivers\...\Driver name\ and restart the print server, you are able to make Windows treat the driver as packaged, and it will install unattended with gpo. The hex number has to be odd. To keep the original settings for the printer driver and only make it Pakage aware you shold add 1 to the original value of PrinterDriverAttributes. In my print enviroment the original attribute had the value 4, so I changed it to 5 and that made it Pakage aware. Different versions of the driver (and different vendors) might need other values.
    Restart server .

    According to MS the 1 flag for PrinterDriverAttributes stands for PRINTER_DRIVER_PACKAGE_AWARE. This will treat the driver as package aware, which means a CAB package will be created, including the inf and the catalog. The package will be installed through setupapi.dll when installing the driver, validating that the catalog is trusted, and that hashes for all files are included in the catalog.

    BTW: This is not a Microsoft problem, but a printer vendor problem! Two lines of code in the *.inf file will make the driver Package aware and fix the problem properly! Solution for vendors posted by Microsoft here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559698(v=vs.85).aspx

    PS: Posted this on Google+ and LinkedIn under the name Grei_70

    From my testing this does not work for GPP when mapping to a Shared Printer.  Yes setting the value in registry marks the Packaged field as True for the driver in Print Management, however it still throws the Warning message in the event log on the pc trying to map to it about the printer not being present on the system, and if I browse to the share manually and try to connect it still prompts me for if I want to trust the driver.

    Thanks for testing this.  Can anyone else confirm if this is working for them?

    So far we are having 100% success using the rundll procedure, although updated drivers would be the ideal method.

    Tuesday, August 23, 2016 4:58 PM
  • This tweak will get your Canon, Sharp og KonicaMinolta printers up and running again by making the drivers Package Aware.

    Edit the register on your print server(s). If you change the value of the key PrinterDriverAttributes under HKLM\System\CurrentControlSet\Control\Print\Enviroments\Windowsx64\Drivers\...\Driver name\ and restart the print server, you are able to make Windows treat the driver as packaged, and it will install unattended with gpo. The hex number has to be odd. To keep the original settings for the printer driver and only make it Pakage aware you shold add 1 to the original value of PrinterDriverAttributes. In my print enviroment the original attribute had the value 4, so I changed it to 5 and that made it Pakage aware. Different versions of the driver (and different vendors) might need other values.
    Restart server .

    According to MS the 1 flag for PrinterDriverAttributes stands for PRINTER_DRIVER_PACKAGE_AWARE. This will treat the driver as package aware, which means a CAB package will be created, including the inf and the catalog. The package will be installed through setupapi.dll when installing the driver, validating that the catalog is trusted, and that hashes for all files are included in the catalog.

    BTW: This is not a Microsoft problem, but a printer vendor problem! Two lines of code in the *.inf file will make the driver Package aware and fix the problem properly! Solution for vendors posted by Microsoft here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559698(v=vs.85).aspx

    PS: Posted this on Google+ and LinkedIn under the name Grei_70

    From my testing this does not work for GPP when mapping to a Shared Printer.  Yes setting the value in registry marks the Packaged field as True for the driver in Print Management, however it still throws the Warning message in the event log on the pc trying to map to it about the printer not being present on the system, and if I browse to the share manually and try to connect it still prompts me for if I want to trust the driver.

    Thanks for testing this.  Can anyone else confirm if this is working for them?

    So far we are having 100% success using the rundll procedure, although updated drivers would be the ideal method.

    Are you using that rundll32 command on Windows 10 computers?  When I tested that, I was getting a parameters error.  Also do you have an example of that without the substituted variables?

    I was confused as to what this is "%~dp0x64\

    Also in your environement with GPP mappings are you setting to connect to "Shared Printers" using the shared path \\PRINTERSERVERNAME\PRINTER?  Or are you using GPP to install TCP/IP print queues directly on the PCs?

    Thanks in advance,

    Tuesday, August 23, 2016 5:46 PM
  • Are you using that rundll32 command on Windows 10 computers?  When I tested that, I was getting a parameters error.  Also do you have an example of that without the substituted variables?

    I was confused as to what this is "%~dp0x64\

    Also in your environement with GPP mappings are you setting to connect to "Shared Printers" using the shared path \\PRINTERSERVERNAME\PRINTER?  Or are you using GPP to install TCP/IP print queues directly on the PCs?

    Thanks in advance,

    Yes we are running entirely Windows 10 at this point.

    Without the variables, the command looks like this:

    START rundll32 printui.dll,PrintUIEntry /ia /m PRINTERNAME /f "INFFILE.INF"

    It's important to note that you will need to provide a complete path for the INF file.  That's where "%~dp0" comes in handy.  It's a variable for the entire path of the location of the script that is running.  I included "x64" because that was in the sample screenshot I provided.  I separate our drivers in either an "x64" or "x86" sub-folder.

    The printer name HAS to be the proper name as shown in the driver properties on your print server.  It won't install the driver if the name is incorrect.

    Yes we are connecting directly to the shared printers on our print server.  We use some VBS Scripts that connect to the printer and then set it default.  Basically it does the same thing as browsing to the printer and double-clicking it.

    Tuesday, August 23, 2016 11:22 PM
  • Are you using that rundll32 command on Windows 10 computers?  When I tested that, I was getting a parameters error.  Also do you have an example of that without the substituted variables?

    I was confused as to what this is "%~dp0x64\

    Also in your environement with GPP mappings are you setting to connect to "Shared Printers" using the shared path \\PRINTERSERVERNAME\PRINTER?  Or are you using GPP to install TCP/IP print queues directly on the PCs?

    Thanks in advance,

    Yes we are running entirely Windows 10 at this point.

    Without the variables, the command looks like this:

    START rundll32 printui.dll,PrintUIEntry /ia /m PRINTERNAME /f "INFFILE.INF"

    It's important to note that you will need to provide a complete path for the INF file.  That's where "%~dp0" comes in handy.  It's a variable for the entire path of the location of the script that is running.  I included "x64" because that was in the sample screenshot I provided.  I separate our drivers in either an "x64" or "x86" sub-folder.

    The printer name HAS to be the proper name as shown in the driver properties on your print server.  It won't install the driver if the name is incorrect.

    Yes we are connecting directly to the shared printers on our print server.  We use some VBS Scripts that connect to the printer and then set it default.  Basically it does the same thing as browsing to the printer and double-clicking it.

    Are you storing the source driver files on a file share then from the print server itself and referencing the file path by a UNC path?, or somewhere locally on each computer?  If it's locally on each computer what method are you using to get those copied to each computer?

    On another note, met with Canon techs today. Regional support tech provided me with UFR II beta drivers that are v3 packaged.  It only supports three models (IR-ADV 4225/4251, iR-ADV 8585/8595, iR-ADV C5235/5240).  Which unfortunately are not for the printer models I need (ir3225, ir3235, ir3245, ir-ADV C5030, ir-ADV C2225). According to him they are working on updates to all previous drivers, but had no timeline of availability.

    Also recently found out that other OU admins where I work are not having issues at all deploying printers with with the older GPO method that can target only Computers or Users within the whole OU (nothing specific like GPP targeting).

    Computer Settings -> Windows Settings -> Deployed Printers
    User Configuration -> Windows Settings -> Deployed Printers

    I've never used that method before, but was surprised when they told me they've had not issues since the July KB release.  They would have all the same models of printers I'm having issue with.  I have not tested this to confirm.

    Wednesday, August 24, 2016 3:02 AM

  • From my testing this does not work for GPP when mapping to a Shared Printer.  Yes setting the value in registry marks the Packaged field as True for the driver in Print Management, however it still throws the Warning message in the event log on the pc trying to map to it about the printer not being present on the system, and if I browse to the share manually and try to connect it still prompts me for if I want to trust the driver.

    @johnnypg: We have enabled point and print restrictions, both computer and user policy. Restrictet servers to printserveres in our environment (fqdn), not showing warning/elevation promts on installation/upgrade. We are mapping shared printers \\printserver.fqdn\printername (using update, not create), not running gpo in logged on user´s security context. Not using fqdn when mapping printer might cause failure.

    Some of our users had problems getting printers after the tweak - printer not showing up, but found in registry under hkcu\printer\connections. We had to delete these with Powershell Remove-Printer and run gpupdate /force before the printers worked. 

    I know some have trouble with a universal UniFlow-driver, I have not tried this driver. We mainly use Canon Generic PLC6 driver ver 3.2.0, KonicaMinolta and Zebra (all signed) - all working after fix. I have a confirmation that the tweak also gets Sharp up and running again.

    Grei_70


    Wednesday, August 24, 2016 4:09 PM
  • Are you storing the source driver files on a file share then from the print server itself and referencing the file path by a UNC path?, or somewhere locally on each computer?  If it's locally on each computer what method are you using to get those copied to each computer?

    Yes I've copied off all the drivers on an open share on our DC's.  Then via startup script the computers run that batch file that silently installs all the drivers via the SYSTEM account.

    As long as the machines had access to the share you could put it anywhere.  You could also deploy the package via SCCM.  But I've found the Startup method is very reliable.

    Wednesday, August 24, 2016 4:56 PM
  • @johnnypg: We have enabled point and print restrictions, both computer and user policy. Restrictet servers to printserveres in our environment (fqdn), not showing warning/elevation promts on installation/upgrade. We are mapping shared printers \\printserver.fqdn\printername (using update, not create), not running gpo in logged on user´s security context. Not using fqdn when mapping printer might cause failure.

    Some of our users had problems getting printers after the tweak - printer not showing up, but found in registry under hkcu\printer\connections. We had to delete these with Powershell Remove-Printer and run gpupdate /force before the printers worked. 

    I know some have trouble with a universal UniFlow-driver, I have not tried this driver. We mainly use Canon Generic PLC6 driver ver 3.2.0, KonicaMinolta and Zebra (all signed) - all working after fix. I have a confirmation that the tweak also gets Sharp up and running again.

    Grei_70


    Thank you for posting again.  This got me testing your method again.  I think I've identified how to make your method work on select drivers.  Let me outline my setup first:

    Point And Print Restriction is defined on Computer Configuration only (not in User Configuration).

    I am not checking the first two boxes.
    Only defining the two pull downs to: Do not show warning or elevation prompt

    When creating the connection to the printer I'm using GPP defined in User Configuration.  I'm connecting to a Shared Printer, and referencing the printer via \\SERVERNAME\PRINTERNAME and I'm NOT adding the FQDN, just the server name only.

    I'm also checking Run in Logged-on user's security context (user policy option) - I've always used this as I thought it had to be checked if you were targeting based on a user's name or group membership (but maybe I've always understood that wrong)

    I'm am also using Item-Level targeting (sometimes it's a Group, sometimes it's a defined user, sometimes it's both)

    That being said:

    On the non-v3 Package aware drivers I tested, from what I've found if the Driver Isolation mode default setting is "Shared", you can edit the registry as sp00ler_n00b has pointed out: HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\<X86 or X64 DEPENDS ON DRIVER>\Drivers\Version-3\<DRIVERNAME>\ then look for the PrinterDriverAttributes REG_DWORD.  If the Driver Isolation is already "Shared" by default, the value should be a 4, change it to a 5.  Then Reboot.  Cycling the print spooler service does not work.  Upon reboot it will show True in the Packaged Column.  GPP mappings worked without issue on the several drivers that fit this scenario. 

    From what I tested, if the Driver Isolation's default setting is defaulted to "None", the PrinterDriverAttributes value is set to 0.  Changing this to a 1 and rebooting does make the Package column show True however I could not get GPP mapping to work.  I tried changing to a 5 as well, still no dice. 

    In my case on the drivers that were defaulting to None for Driver Isolation mode, I simply downloaded a different driver that had it set to Shared.  I understand it's not the same driver, but if it prints, user's don't care. On the Canon's I couldn't make work I substituted a UFRII driver for the PCL6.

    On another note, the Canon tech informed me today the timeframe for public release of updated drivers is Sept-Oct timeframe.

    Wednesday, August 24, 2016 7:57 PM
  • There are actually two locations for Point and Print restrictions:

    Computer Configuration > Policies > Admin Templates > Printers > Point and Print Restrictions
    
    User Configuration > Policies > Admin Templates > Control Panel > Printers > Point and Print Restrictions

    Though I'm not sure if they both take effect.  I suspect you are right that only the computer side takes effect.

    Thursday, August 25, 2016 6:02 PM
  • There are actually two locations for Point and Print restrictions:

    Computer Configuration > Policies > Admin Templates > Printers > Point and Print Restrictions
    
    User Configuration > Policies > Admin Templates > Control Panel > Printers > Point and Print Restrictions

    Though I'm not sure if they both take effect.  I suspect you are right that only the computer side takes effect.

    I am aware.  My understanding is the user configuration side has been deprecated and is no longer needed:

    https://support.microsoft.com/en-us/kb/2307161

    Thursday, August 25, 2016 8:57 PM
  • Yes , Only the Computer configuration is honored.  Unless one is running Vista release or Vista SP1.

    I like some of the creative solutions here.

    Good work on a difficult unannounced situation.


    Alan Morris formerly with Windows Printing Team


    Monday, August 29, 2016 4:57 AM
    Answerer
  • Johnnypg,

    This is still an issue with deploying via Group Policy - Deployed Printers.  You get the same type 'warning' IF you don't already have the driver installed on the system  (Look deeper into event viewer under print services and you can find it for anyone curious) For instance, I was testing with an admins machine.  We had removed his printers (by taking away the 'deployed printers' mappings you are using above).  Then moved to GPP mappings.  His mapped, mine did not.  I had a fresh VM without the drivers on my system.  So whilst many folks may have gotten the printers, new systems without drivers would not.  No matter what i configured, GPP, GP, Script, manual...they all prompted with the prompt that started this thread.  Removing the KB article worked like a champ.  But we know this isn't the real solution.  We will probably go with the Registry Tweak, since it could be months before drivers are released for all Canon models.  

    This is a vendor issue, guys.  All vendors have known this was coming for nearly 10 years.  I tell ya what.  2 days of nothing is what this amounted to for me.  My only sanity was knowing the HP printer was mapping as planned.  I nearly went crazy with this.  Thanks everyone for posting!

    Sidenote: Copying the drivers down to every system doesn't seem like a valid solution and I challenge that as the answer.

    -LvilleSystemsJockey


    Tuesday, September 06, 2016 7:38 PM
  • I would wait if I were you before going to  a lot of work and trouble.  It is almost patch Tuesday and there is a very good chance an update will be released in the September updates to correct the problem with the July patch.

    I had a case open with premier.  Microsoft has acknowledged the problem and has developed a patch that corrects the problem.  The only question is whether the patch was approved in time to be released in the September patches - and we wont know the answer to that question until next Tuesday.  If you can hang on for a few more days, you will have an answer.  Since you are already removing the broken update, that seems reasonable to continue on that path for 6 more days.  

    Wednesday, September 07, 2016 3:03 PM

  • Sidenote: Copying the drivers down to every system doesn't seem like a valid solution and I challenge that as the answer.

    -LvilleSystemsJockey


    I have yet to find a system or printer that this has not worked with when deployed properly.  We have dozens of unpackaged printers with thousands of workstations connecting to them.

    Monday, September 12, 2016 6:05 PM
  • This is still an issue with deploying via Group Policy - Deployed Printers.  You get the same type 'warning' IF you don't already have the driver installed on the system  (Look deeper into event viewer under print services and you can find it for anyone curious)


    Good to know I never tested this method. Just based it off another departments word. I'm not surprised.

    So far the registry hack for enabling packaged drivers has been our fix.

    Update from our Canon tech just yesterday is "No updates yet"

    Tuesday, September 13, 2016 10:28 PM
  • The specific KB article is https://support.microsoft.com/en-us/kb/3170005
    MS16-087: Security update for Windows print spooler components: July 12, 2016


    Guidance for network administrators:

    • Update the affected printer driver. Package-aware V3 printer drivers were introduced in Windows Vista. Installing a package-aware printer driver will resolve the issue.
    • If a specific legacy printer does not have the appropriate printer driver available, preinstalling the problematic printer driver on the client system will resolve the issue.

    For more information about these scenarios, see the following Microsoft resources:

    Print and Document Services architecture
    https://technet.microsoft.com/en-us/library/jj134171(v=ws.11).aspx

    Package-aware print drivers
    https://msdn.microsoft.com/en-us/library/windows/hardware/ff559698(v=vs.85).aspx

    Wednesday, September 21, 2016 12:32 AM
  • The specific KB article is https://support.microsoft.com/en-us/kb/3170005
    MS16-087: Security update for Windows print spooler components: July 12, 2016


    Guidance for network administrators:

    • Update the affected printer driver. Package-aware V3 printer drivers were introduced in Windows Vista. Installing a package-aware printer driver will resolve the issue.
    • If a specific legacy printer does not have the appropriate printer driver available, preinstalling the problematic printer driver on the client system will resolve the issue.

    For more information about these scenarios, see the following Microsoft resources:

    Print and Document Services architecture
    https://technet.microsoft.com/en-us/library/jj134171(v=ws.11).aspx

    Package-aware print drivers
    https://msdn.microsoft.com/en-us/library/windows/hardware/ff559698(v=vs.85).aspx


    Microsoft plans to release a fix for this problem.  The fix was finished and tested in August, and will be released in October (3rd Tuesday, I'm told -- why they are sitting on the fix for 8 weeks, who knows?)  It was not intentional to break the installation of non-packaged drivers via Point and Print trusted sources as configured in GPO.  You folks keep pointing to the workaround like that is the final answer from Microsoft -- Like the new normal is to manually distribute non-packaged printer drivers.  It isn't.  It was never the intention to break driver installation from the trusted print servers, and it is not the intention that the long term fix is to manually install the drivers. 
    Thursday, September 22, 2016 3:08 PM
  • @Todd, could you share the SR number of the Prem case please?

    I'll get my SDM to check into it for us.


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, September 22, 2016 9:36 PM
  • The specific KB article is https://support.microsoft.com/en-us/kb/3170005
    MS16-087: Security update for Windows print spooler components: July 12, 2016


    Guidance for network administrators:

    • Update the affected printer driver. Package-aware V3 printer drivers were introduced in Windows Vista. Installing a package-aware printer driver will resolve the issue.
    • If a specific legacy printer does not have the appropriate printer driver available, preinstalling the problematic printer driver on the client system will resolve the issue.

    For more information about these scenarios, see the following Microsoft resources:

    Print and Document Services architecture
    https://technet.microsoft.com/en-us/library/jj134171(v=ws.11).aspx

    Package-aware print drivers
    https://msdn.microsoft.com/en-us/library/windows/hardware/ff559698(v=vs.85).aspx


    Microsoft plans to release a fix for this problem.  The fix was finished and tested in August, and will be released in October (3rd Tuesday, I'm told -- why they are sitting on the fix for 8 weeks, who knows?)  It was not intentional to break the installation of non-packaged drivers via Point and Print trusted sources as configured in GPO.  You folks keep pointing to the workaround like that is the final answer from Microsoft -- Like the new normal is to manually distribute non-packaged printer drivers.  It isn't.  It was never the intention to break driver installation from the trusted print servers, and it is not the intention that the long term fix is to manually install the drivers. 

    Totally agree.

    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help.

    Friday, September 23, 2016 7:11 AM
  • Canon has finally released v3 Package aware drivers!

    They are not currently on their site when searching but the links are below.

    Current models, and some older models are included in the V21.85 drivers.

    Anything older should use the Generics

    Canon UFRII Printer Driver V21.85
    http://downloads.canon.com/bisg2016/drivers/win/UFRII_v21.85_Set-up.exe

    Canon PCL6 Printer Driver V21.85
    http://downloads.canon.com/bisg2016/drivers/win/PCL6_v21.85_Set-up.exe

    Canon PS Printer Driver V21.85
    http://downloads.canon.com/bisg2016/drivers/win/PS_v21.85_Set-up.exe

    Canon Generic UFRII Printer Driver V2.20
    http://downloads.canon.com/bisg2016/drivers/win/Generic_UFRII-2.20_Set-up.exe

    Canon Generic PCL6 Printer Driver V3.10
    http://downloads.canon.com/bisg2016/drivers/win/Generic_PCL6-3.10_Set-up.exe

    Canon Generic Fax Driver V10.25
    http://downloads.canon.com/bisg2016/drivers/win/Generic_Fax-10.25_Set-up.exe

    Friday, September 23, 2016 4:16 PM
  • Microsoft plans to release a fix for this problem.  The fix was finished and tested in August, and will be released in October (3rd Tuesday, I'm told -- why they are sitting on the fix for 8 weeks, who knows?)  It was not intentional to break the installation of non-packaged drivers via Point and Print trusted sources as configured in GPO.  You folks keep pointing to the workaround like that is the final answer from Microsoft -- Like the new normal is to manually distribute non-packaged printer drivers.  It isn't.  It was never the intention to break driver installation from the trusted print servers, and it is not the intention that the long term fix is to manually install the drivers. 

    Today it was confirmed by MS Premier support that this issue will be fixed in October, at the moment 12th October is planned for Windows 7.
    Monday, September 26, 2016 12:12 PM
  • Changed the value in registry and all Win 10 1607 builds are working again with Canon driver.  Thanks for the fix!
    Thursday, September 29, 2016 7:47 PM
  • Worked for me - blimey that was a lot of wasted hours tracking this down, we have Oki printers and most were non packaged drivers, this got them installing via GPO again instantly. Thanks for the good tip.
    Wednesday, October 05, 2016 1:34 PM
  • I've heard from others within my agency that this is supposed to be fixed by https://support.microsoft.com/en-us/kb/3187022

    I'll be testing tomorrow, please give it a try and see how it works out for you.  If this does correct the problem, it's disappointing that the MS16-087 bulletin hasn't been updated to reference this in the "Known Problems" section.

    Friday, October 07, 2016 1:07 AM
  • I've heard from others within my agency that this is supposed to be fixed by https://support.microsoft.com/en-us/kb/3187022

    I'll be testing tomorrow, please give it a try and see how it works out for you.  If this does correct the problem, it's disappointing that the MS16-087 bulletin hasn't been updated to reference this in the "Known Problems" section.

    But what about Windows 10 ?

    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help.

    Saturday, October 08, 2016 11:37 AM
  • I've heard from others within my agency that this is supposed to be fixed by https://support.microsoft.com/en-us/kb/3187022

    I'll be testing tomorrow, please give it a try and see how it works out for you.  If this does correct the problem, it's disappointing that the MS16-087 bulletin hasn't been updated to reference this in the "Known Problems" section.

    Can someone confirm if this update: https://support.microsoft.com/en-us/kb/3187022 has fixed the issue? If so how can I download this update? 

    Or should I update the drivers? 

    Thanks. 


    Tuesday, October 11, 2016 1:16 AM
  • https://support.microsoft.com/en-us/kb/3187022

    is a fix in GDI, this fix has no connection to the changes in the spooler code. 


    Alan Morris formerly with Windows Printing Team

    Wednesday, October 12, 2016 5:21 AM
    Answerer
  • Not yet tested it..

    https://support.microsoft.com/en-us/help/12387/windows-10-update-history

    October 11, 2016
    KB3194798 CU for Win10 1607 v14393..
    - Addressed issue causing printer drivers to not install correctly after installing security update KB3170005

    KB3192441 CU for Win10 1511 v10586..
    - Addressed issue causing printer drivers to not install correctly after installing security update KB3170005

    KB3192440 CU for Win10 1507 v10240..
    - Addressed issue causing printer drivers to not install correctly after installing security update KB3170005


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, October 12, 2016 8:36 AM
  • and, seems like an equivalent backport fix not included in the chunky new Win7 RUP:
    https://support.microsoft.com/en-us/kb/3185330

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, October 12, 2016 8:42 AM
  • So I´ve installed the KB you mentioned but the GPO still fails to add the printers. Have you tried it out yet?

    Running Win 10, 1511 on the client
    Wednesday, October 12, 2016 1:23 PM
  • https://support.microsoft.com/en-us/kb/3187022

    is a fix in GDI, this fix has no connection to the changes in the spooler code. 


    Alan Morris formerly with Windows Printing Team

    Alan - I ma confused now. Can you please clearly if this is a fix or not? Should I deploy this fix "https://support.microsoft.com/en-us/kb/3187022" to our end user computers? 


    If this is not the correct fix, can you please provide the link to appropriate fix? 

    Cheers 

    Thursday, October 13, 2016 1:04 AM
  • I have been told by Microsoft premier that this issue is resolved in KB3192403 -- October, 2016 Preview of Monthly Quality Rollup for Windows 7 (whatever that means).  I cannot find any concise  Microsoft documentation that outlines the differences and recommendations among

    1. (Month), (Year) Preview of Monthly Quality Rollup for Windows 7

    2. (Month), (Year) Security Only Quality Update for Windows 7

    3. (Month), (Year) Security Monthly Quality Rollup for Windows 7

    the names of these updates are poorly chosen and add to the confusion. Can't find much good information on what these three mean and how they differ.  One things seems clear though... Microsoft thinks "Quality" is the new "tremendous"

    Friday, October 21, 2016 3:14 PM
  • I have been told by Microsoft premier that this issue is resolved in KB3192403 -- October, 2016 Preview of Monthly Quality Rollup for Windows 7 (whatever that means).  I cannot find any concise  Microsoft documentation that outlines the differences and recommendations among

    1. (Month), (Year) Preview of Monthly Quality Rollup for Windows 7

    2. (Month), (Year) Security Only Quality Update for Windows 7

    3. (Month), (Year) Security Monthly Quality Rollup for Windows 7

    the names of these updates are poorly chosen and add to the confusion. Can't find much good information on what these three mean and how they differ.  One things seems clear though... Microsoft thinks "Quality" is the new "tremendous"

    https://blogs.technet.microsoft.com/windowsitpro/2016/10/07/more-on-windows-7-and-windows-8-1-servicing-changes/

    https://blogs.msdn.microsoft.com/dotnet/2016/10/11/net-framework-monthly-rollups-explained/

    https://blogs.technet.microsoft.com/enterprisemobility/2016/10/07/configuration-manager-and-simplified-windows-servicing-on-down-level-operating-systems/


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Friday, October 21, 2016 11:29 PM
  • Has anyone tried with success to have KB3192403 fix the point-and-print problem?

    I installed this update on a couple of client systems that were having problems installing upgraded drivers.  After the install of KB3192403, users will still unable to upgrade drivers for existing printers.  

    When trying to print to a Minolta buzhub where the drivers on the client were out of date compared to those on the print server, the user would get a notice that the printer needed updating.  When printing, the user was still getting the "Do you trust this printer" dialog along with a non-functioning UAC button (user is normal, non-admin.)  The drivers appear to download, but they are not updated successfully.  This is the same behavior as prior t the October Preview rollup.

    Monday, October 24, 2016 3:54 PM
  • I can confirm that KB3192404 for Windows 8.1 does not fix the problem whatsoever, users still get the warning message when connecting to a point&print printer for the first time, regardless of GPO settings.

    This is especially critical since we use 140+ Samba print servers, which do not yet support package-aware drivers at all.

    Tuesday, October 25, 2016 2:55 PM
  • Sorry V ,

    I'm not getting updates from this thread.  3187022 was not a spooler fix and nothing to do with the Point and Print driver installation failures.  It did impact printing but was not a printing fix so I assume no one verified print scenarios which has happened several times with changes in GDI and is one of reasons MS moved to the XPS print path.


    Alan Morris formerly with Windows Printing Team

    Wednesday, October 26, 2016 6:18 PM
    Answerer
  • I'll do some tests on this soon as well. I was so excited to see MS posted the update, then came to this thread and read that there are still issues. :-(

    I have control of my Enterprise environment and control the print drivers here.  Seems like a big step back to give users admin rights for this basic task.


    Alan Morris formerly with Windows Printing Team

    Wednesday, October 26, 2016 6:21 PM
    Answerer
  • I got tired of waiting from Microsoft. A useless organisation that unfortunately we have to use. Therefore, I downloaded the new drivers and updated all 60+ computers using this script: 

    gwmi win32_printer -computer COMPUTER01 -filter 'drivername="OLD Driver Name"' |

        ForEach-Object{

                    $_.DriverName='New Driver Name'

            $_.Put()

        }

    I've left the sciprt running over night as for some reason it took a long time. 

    Cheers 

    Friday, October 28, 2016 1:11 AM
  • we configured the point and print restriction in both user and computer configuration in group policy but still will get UAC prompt to trust the printer. click install will install the printer without having to enter admin credentials.

    any way to not even pop up the UAC prompt to trust the printer?

    my group policy configuration is as such:

    users can only point and print to these server: disabled
    users can only point and print to machines in their forest: enabled
    when installing drivers for a new connection: do not show warning or elevation prompt
    when updating drivers for an existing connection: do not show warning or elevation prompt
    Friday, October 28, 2016 6:31 PM
  • we configured the point and print restriction in both user and computer configuration in group policy but still will get UAC prompt to trust the printer. click install will install the printer without having to enter admin credentials.

    any way to not even pop up the UAC prompt to trust the printer?

    my group policy configuration is as such:

    users can only point and print to these server: disabled
    users can only point and print to machines in their forest: enabled
    when installing drivers for a new connection: do not show warning or elevation prompt
    when updating drivers for an existing connection: do not show warning or elevation prompt

    the KB article https://support.microsoft.com/en-au/kb/3170005 has been updated..
    That KB now provides 16 specific steps to follow: 
    (Note After you enable these group policies, you have to add all printer servers to both the Point and Print Restrictions list and the Package Point and Print – Approved server list. This is true regardless of package awareness.)

    and also refers to https://support.microsoft.com/en-au/kb/3192403


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Friday, October 28, 2016 10:50 PM
    • Proposed as answer by glsb Friday, January 06, 2017 9:22 PM
    Friday, October 28, 2016 10:49 PM
  • Thursday, November 03, 2016 7:26 PM
  • 1. For those not using Windows 10, do any of the October or November security-only updates contain the fix?

    2. If the answer to the first question is no, is there a plan for a fix in a future security-only update, or in an updated version of an existing security-only update?

    Wednesday, November 16, 2016 4:30 AM
  • 1. For those not using Windows 10, do any of the October or November security-only updates contain the fix?

    2. If the answer to the first question is no, is there a plan for a fix in a future security-only update, or in an updated version of an existing security-only update?

    Have you read the updated KB article https://support.microsoft.com/en-au/kb/3170005 ?

    Microsoft has released an update for October 2016 that lets network administrators configure policies that permit the installation of print drivers that they consider are safe. This update also allows for network administrators to deploy printer connections that they consider safe


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Wednesday, November 16, 2016 7:54 AM
    Wednesday, November 16, 2016 7:53 AM
  • Have you read the updated KB article 3170005?

    Yes, thanks, I was already aware that fixes are in those monthly rollup previews and monthly rollups. My question is whether those fixes are in the security-only updates KB3192391, KB3197867, KB3192392, KB3197873, KB3192393, or KB3197876.
    Wednesday, November 16, 2016 12:09 PM
  • Have you read the updated KB article 3170005?

    Yes, thanks, I was already aware that fixes are in those monthly rollup previews and monthly rollups. My question is whether those fixes are in the security-only updates KB3192391, KB3197867, KB3192392, KB3197873, KB3192393, or KB3197876.

    a quick check of the changed-files listing for https://support.microsoft.com/en-au/kb/3197867 does not show any changed-files for *spl* nor *print* nor *pnp*, so my guess would be no.

    Which aligns with my twisted understanding of the MSFT twisted logic (the replaced files are not being replaced for security reasons so would not be included in a security-only rollup update).

    Although product/component behaviour changed due to a security update, the further revision of the behaviour isn't addressing a security vulnerability.

    But they should be included in the security+quality rollup since Oct-preview -> Nov-GA, and so on.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Wednesday, November 16, 2016 8:30 PM
    Wednesday, November 16, 2016 8:27 PM
  • a quick check of the changed-files listing for https://support.microsoft.com/en-au/kb/3197867 does not show any changed-files for *spl* nor *print* nor *pnp*, so my guess would be no.

    Which aligns with my twisted understanding of the MSFT twisted logic (the replaced files are not being replaced for security reasons so would not be included in a security-only rollup update).

    Although product/component behaviour changed due to a security update, the further revision of the behaviour isn't addressing a security vulnerability.

    Thank you for your prompt reply :).

    Have you read any statements from Microsoft personnel that this is how the security-only updates will work?

    Wednesday, November 16, 2016 11:24 PM
  • a quick check of the changed-files listing for https://support.microsoft.com/en-au/kb/3197867 does not show any changed-files for *spl* nor *print* nor *pnp*, so my guess would be no.

    Which aligns with my twisted understanding of the MSFT twisted logic (the replaced files are not being replaced for security reasons so would not be included in a security-only rollup update).

    Although product/component behaviour changed due to a security update, the further revision of the behaviour isn't addressing a security vulnerability.

    Have you read any statements from Microsoft personnel that this is how the security-only updates will work?

    Perhaps a very long time ago, I may have done so, or, perhaps I never have *actually* seen it written so. Could have been a webcast or TechEd session or maybe I leapt to the assumption all by myself ;)

    I'm happy to be challenged on it. I can say that it's something I'm yet to see refuted with evidence?

    I've long-held the following as foundation principles of MSFT updates:

    - a 'Security Update' addresses a known/confirmed security vulnerability
    - a 'Security Advisory' addresses a potential vulnerability
    - a 'Non-Security Update' aka 'Quality Update' addresses a reliability/performance/defect, but doesn't address 'Security'

    * 'Security' is a subjective thing, it seems, according to MSFT ;)

    eg, if an update deploys a changed binary/executable, and the changed behaviour mitigates/reduces 'security risk', I'd call that a security improvement. if the same exe/dll is subsequently changed/revised/improved again, but this subsequent change/revision/improvement causes an improvement to 'quality' but no improvement to 'security', this subsequent update would not be classified as a 'Security Update' by MSFT. This assumes that the original security benefit is carried through/accumulated, and is not lost to regression.


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, November 17, 2016 6:31 AM
  • For me the Registry "Hack" worked fine. I'm now able to install all unpaked drivers. The Path to my Brother driver in the registry is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\Brother MFC-9460CDN Printer

    I changed the key "PrinterDriverAttributes" to "5". Now i'm able to install the drivers as before. So my users can work and i can wait for another fix of MS.

    Cheers

    Charly

    Thursday, November 17, 2016 12:39 PM
  • Regards to which package update being removed  that will fix the issue, it is "KB3197873".
    Friday, November 25, 2016 4:49 PM
  • Regards to which package update being removed  that will fix the issue, it is "KB3197874 not KB3197873".
    Friday, November 25, 2016 9:18 PM
  • Thanks for the tip.  We found restarting the print spooler service was sufficient after the registry change is made.
    Friday, December 16, 2016 1:51 AM
  • This works perfect for me, thank you so much
    Wednesday, December 28, 2016 7:04 PM