This should affect all print server installations, because it's
something MS changed on the client and is independently of the type of
print server (AD, NT4 domain, standalone)
>> You can easily figure out if this is your problem: Set up a new Win7
>> client without applying the
>> updates. If you can preconfigure drivers and connect to the printers
>> on this machine, then
>> MS16-087 is your problem.
> Tested that but it still fails in the same way. Maybe I should have
> mentioned that connecting to the printers and using them to print
> does work. It's just the management part that fails.
Even if you applied this patch, your users are able to connect the
printer and use it - as long as the driver is already available on the
client. This means, if one of your users connected the printer on a
workstation before MS16-087, the driver was installed locally. For all
users on this host that are connecting later to a printer that uses the
same driver, the driver is not downloaded from the print server again
(as long as it is not updated on the server).
Your situation sounds really like it is caused by this MS update.
However, if you tested this with a fresh install without installing any
updates, it's unlikely.
Can you please go through the following guides:
and make sure that everything matches your environment? Especially that
you use an account that has the SePrintOperatorPrivilege privilege
granted and is able to write to the print$ share. I rewrote both guides
recently and verified them using Samba 4.5.3 or 4.5.4 on RHEL 7.3.
However, I only checked Win8 and 10 (both 64-bit), not Win7.
If you verified that your settings matches what we have in our
documentation and be sure that it's not related to the MS update, can
you please put a level 10 debug log on pastebin (or any other paste
service) that contains only the log entries when you click the action
that fails? Additionally, your [global], [printers], [print$], and the
section of an printer would be interesting.