Univention Bugzilla – Bug 43252
Workaround for Point and Print drivers not getting downloaded after MS16-087
Last modified: 2023-03-25 06:43:43 CET
June/july Microsoft shipped security update MS16-087 which breaks point-and-print (aka serverside printer drivers) in two ways: 1. For non-package-aware v3 printer drivers, a warning message may be displayed when users try to connect to point-and-print printers (i.e. printers which refer to a serverside uploaded driver). 2. For non-interactive scenarios (for example, the printer is installed through an automated script or via via GPO desribution/PushedPrinterConnection/PPC), printer installation fails for non-package-aware v3 printer drivers, and no warning message is displayed. Samba is currently working to support support package-aware drivers by implementing the MS-PAR protocol. Therefore customers are not able to configure their client to download required printer drivers and install them automatically on first use. Security update MS16-087 is shipped under different IDs for different Windows-Versions: * KB3170455 (or the earlier KB3170005) for Windows 7 / 8.1 * KB3163912 for Windows 10, including several updates. We should describe workarounds for this.
In addition to the scripted de-installation of KB3170455 (see Workaround #3 attechad to Bug 42442 Comment 4), there are two other workarounds: Workaround #4: Tested with Windows 7 ========================== Allow normal users to install "non-packaged-drivers". This workaround doesn't 100% fix the printer assignment via GPO/PushedPrinterConnection, because *some* use on each particular Windows Client needs to click on the network printer once to initiate the download of the printer driver. After that the GPO pushed printer connections (PPC) work for everybody logging on to that client. The configuration of this workaround is a bit more complicated and described in this posting: https://lists.samba.org/archive/samba/2016-September/202922.html While this workaround seems to sacrifice less security (by keeping the update installed), it still opens additional privileges to normal users.
Finally here is Workaround #5: ========================== Quoting the kb3170005: "install the driver files to the local driver store before you install the local printer" In verbatim this means: Run pnputil.exe to stage the drivers on the Windows clients. This can also be done via GPO. Take a joined Windows client which offers the Group Policy Management Console (GPMC). In GPMC edit "Default Domain Policy" as Domain Admin, navigate to Computer Configuration\Windows Settings\Scripts (Startup/Shutdown)\Startup A click on "Show Files" opens an explorer window in the corresponding sysvol subdirectory of the "Default Domain Policy" GPO. Add a bat file which runs pnputil.exe to install the drivers from some file share which the client can access. I'll attach a simple example script, it's really just one line. After the file has been copied to the appropriate sysvol subdirectory of the "Default Domain Policy" GPO, just close the explorer and your are back in the GPMC editor dialog. Now click on Add>Browse and pick the file you just copied. Click ok to close all GPMC dialogs. Now for the actual drivers: In my tests I've simply copied the "HP Universal Print Driver" folder, containing the unzipped driver files, to the sysvol base folder of my UCS Samba/AD DC Master. Done. When the client starts up, it will run the script and pre-stage drivers according to the instructions of the bat file. "pnputil -e" can be used to check this interactively. The drivers should end up in C:\Windows\System32\DriverStore\FileRepository Then, when a user logs on, which has a printer pushed via GPO, the driver gets (really) installed and the printer gets connected automatically, as advertised.
Created attachment 8324 [details] stage_printer_drivers.bat
Caveat emptor: In my tests this Workaround #5 (Comment 2) worked with one of the HP Universal Print Driver inf files which actually seemed to be "package-aware" (It has PackageAware=TRUE in the Postscript hpcu130d.inf file). In a test with a different driver (PCL6 hpbuio45l.inf), which doesn't have PackageAware=TRUE, I experienced Bug #35846 during initial driver assignment, AND, surprise: the printer was not pushed automatically to the user. Interesting. I then opened an explorer and navigated to the printer share. The confirmation dialog popped up, asking me if I trust the driver. After acknowledging, the driver was downloaded and the UAC dialog popped up to ask me for Administrator credentials. After that, the printer was available. So, there might be two lessons from this: A) Bug #35846 might be related to non-package-aware drivers. B) Maybe a combination of Workaround #4 and #5 can fix this to have true automation also for drivers like these. The one thing that I don't fully understand is the nature of the "package-aware" drivers and what Samba is currently doing in this area for the upcoming Samba 4.6 release. In the "Print Management" ("Druckverwaltung") tool, the driver information shows a column "packaged" (or similar wording), which is always "false" in Samba, also for drivers which have "PackageAware=TRUE" in their .inf files. That might be a Samba implementation artefact. This "false" setting is directly controlled by a key in the Window registry. I can edit that key also on an UCS Samba server (remotely via regedit) and switch it to "true", but that doesn't seem to have any real effect. On native Windows systems this hack is reported to trigger the system to re-package the driver and actually turn it into a "packaged" format. As far as I can see from the Samba 4.6 Whatsnew file, some team members from RedHat have been working to allow "upload" of packaged drivers to a samba server (I guess they are stored e.g. in \\server\print$\x64\3\pcc).
It should be noted that it is possible to completely restore the pre-MS16-087 behavior as stated here mid-article: https://support.microsoft.com/de-de/help/3170005/ms16-087-security-update-for-windows-print-spooler-components-july-12,-2016 In short: You have to at least install the cumulative "security and quality rollup" from November 2016 or newer and then set your trusted print servers in 2 seperate GPO settings.
Ok, good to know, I've not checked it again. The report by Geert Lorang on the samba mailinglist is from September (see URL field of this Bug), so the October update may have relaxed the dependency on packaged drivers.
*** Bug 42442 has been marked as a duplicate of this bug. ***
For Ticket# 2017081021000208 I've tested it again (successfully) and provided a howto guide for the customer.
Added https://help.univention.com/t/non-interactive-installation-of-printer-drivers-from-print-servers-fails-on-windows-clients-point-and-print/6642
(In reply to Felix Botner from comment #9) > Added > > https://help.univention.com/t/non-interactive-installation-of-printer- > drivers-from-print-servers-fails-on-windows-clients-point-and-print/6642 unlisted at the moment
Ok, published.