KB3170455 preventing printer installation

[DavR]

Many thanks for that article @themightymrp! I've got mine working now using the October 2016 Mitigation from that link

 

My clients and servers are up to date with November 2016 rollup, this prevents installation of unsigned / untrusted print drivers as expected.

 

To get round this, I already had my Point and Print restrictions set to unrestricted, and "Do not show warning or elevation prompt" for installing drivers in group policy. The key setting for me was "Package Point and Print – Approved servers" setting. Having put my print server name (fully qualified) in here, Windows is now treating this as "trusted" and happily installing my dodgy drivers.

 

Phew! I understand Microsoft's desire to close a security loophole, but once again doing it (very nearly) at the expense of functionality...

[themightymrp]

Thanks Dave for the feedback! I haven't gone ahead yet myself as I was still unsure, but you have given me confidence. I might implement this on Thursday as we have a training day.

 

Cheers

[DavR]

Yeah, it's really no biggie to implement - as far as I can see, the key points are "Do not show warning or elevation prompt" when installing drivers, and setting your print server name under "Package Point and Print – Approved servers".

[garethEds]

This has just happened to us. Our 2012r2 server had some updates on Monday -

 

KB3197874

 

Then all of a sudden we couldn't print direct through our pCounter Server.

 

I'm thinking it is the server that has the issue because our desktops are on two different networks and the Admin network can see our print server but would not have had updates via WSUS - would this make sense to everyone?

 

Going to uninstall these updates now to see if it makes any difference.

 

Gareth

Edited November 16, 2016 by garethedmondson
Mistake reading my updates list

[DavR]

Yeah, November Cumulative for Server 2012 R2 KB3197874 is server side of this. I don't know whether it's the server update, workstations update (November Cumulative KB3197868) or both that reinforce this behaviour. If it's happening on workstations that don't have November Cumulative, then it would suggest server also enforces this behaviour.

 

Not that it really matters - long term, you will need to have this patch as upgrades are cumulative, we can't just uninstall and block "rogue" updates any more.

 

I'd recommend looking into the policy changes discussed in the article above to "trust" your print server.

Edited November 16, 2016 by DavR

[garethEds]

I'd recommend looking into the policy changes discussed in the article above to "trust" your print server.

 

Hi Dave,

 

yes - that is what I am doing now once everyone has gone home. I've made the changes on my machine via GPO and restarted. Hopefully it will catch pretty quickly. I'm also making sure the printers have the latest drivers. Hopefully something will go right for me.

 

Gareth

[DavR]

Yeah, should be fine! Trusted drivers and/or those policy changes should fix it.

[garethEds]

Doesn't seem to have fixed anything.

 

Do I need any GPO changes on the server?

 

Sigh

 

Gareth

[DavR]

I'm not aware of the server needing any policy changes - after all, the installation is happening on the workstation, it's the workstation stopping you.

 

Have you got the server name in fully qualified in your policy?

 

Have you done a gpupdate and checked RSOP on your workstation to make sure the settings have taken?

[themightymrp]

Got mine working now In the end all I did was set the GPO options for point and print restrictions and the package point and print settings in the default domain policy. I only needed to add them into the computer side of the GPO. Once the server FQDN was in those policies I redeployed the November update and had no further issues.

 

Very pleased that I can tick this job off

[sonofsanta]

The new policy option--Package Point and print - Approved servers, which wasn't there in July--seems to have fixed it for me, with no changes needed on the print server or with the custom (unsigned) drivers. Would have been nice to have had the option there when MS initially pushed the patch out, but at least it's sorted now...

 

Weirdly, after doing the October/November rollups, my workstations still think they need kb3170455, when I thought it (or a superseding update) was in the recent rollups--but printers seem to work with all the updates installed, anyway, so I'm just happy to be done with this job at last.