Jump to content

Recommended Posts

Posted
I am getting something similar. Seems that newly images machines are not installing a needed update for the fix to take effect.

If you install the printer from the share directly, you'll get an error - hopefully 0x000011b.

 

Check for the following update KB5006670.

We have released this via SCCM, but its not being picked up.

Checking MS onine, find the above update and installs it.

 

Machines we updated with KB5006670 update worked fine after the restart, printers connected without having to make any changes to registry etc.

 

We've had exactly the same with machines that have been rebuilt during or since Half Term though. Update KB5006670 was only being found online once we uninstalled the OOBE update it picked up during MDT deployment. Once the update has installed though we're still having to set the registry to 0 to get drivers to install.

Posted (edited)

SERVER 2012-R2 VM - Print Server - OCTOBER CU

LTSB & LTSC - Client - SEPTEMBER CU

 

Just to clarify, the new WSUS server has bags of space so having all of the updates is not an issue. The older server, did not have all of the updates, just the core ones, so I had already tried to free up as much room as I could.

 

Yeah, it's just that the more WSUS has to process the harder it has to work and the chance of it falling over therefore increases exponentially (I'm sure I've just paraphrased a quote from someone there)... Plus it's just more to manage as you found when you have to fix it, that's all (it's a quirky old beast)...

 

1.You mention about the print server drivers having 'render on clent' and 'print directly' set. How is this done? Do I need to ask RISO to do this?

 

These are in the printer settings on the print server (but these have always been our defaults).

 

Capture 2.JPG

 

Capture 3.jpg

 

Found on another forum:

 

https://www.bleepingcomputer.com/forums/t/759880/kb5006670-network-printer-problems-again-this-month/?p=5275230

 

2.You mention that you do not have RpcAuthnLevelPrivacyEnabled=dword:0 set on server or clients. I have not heard of this before? Should I try it?

 

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print]

"RpcAuthnLevelPrivacyEnabled"=dword:0

 

 

Was mentioned in a post on this thread (or another similar one) and on these forums (I tested with it set at 0 and also without it - no difference):

 

https://docs.microsoft.com/en-us/answers/questions/573124/microsoft39s-printnightmare-update-is-causing-a-lo.html

 

https://www.bleepingcomputer.com/news/microsoft/how-to-fix-the-windows-0x0000011b-network-printing-error/

 

Lastly, can I just check that for Point and Print Restrictions within the GPO, have you set them under Computer Configuration or User Coniguration? And also have 'Users can only point and print to machines in their forest' disabled?

 

I notice I have set mine under Computer Config, but under User Config, I have the 'Printer Connections' and respective paths, these are also listed under Computer Config, so duplicated. Does this seem ok?

 

I have the Point and Print settings in Computer.

 

Capture.JPG

 

Printers install/map via USER GPP.

 

Capture 1.JPG

Edited by Koldov
Posted (edited)

"Windows 10 version 1909

Updates and improvements:

 

  • Fixes an issue that might prevent the installation of printers using IPP (Internet Printing Protocol).
  • Addresses an issue of a 0 (zero) width Pen to render one pixel regardless of transformation.
  • Adds a feature to facilitate certain cross-browser data transfers.
  • Addresses an issue in JScript9.dll with PropertyGet.
  • Fixes an issue with Assigned Access Kiosks and Microsoft Edge, which caused Edge to fail to restart.
  • Improved Microsoft Defender for Endpoint's ability to identify and intercept ransomware and advanced attacks.
  • Fixed a File Explorer stops responding issue.
  • Security updates."
     
    Known errors
     
    Windows 10 version 1909
     
    • Print clients may throw errors when connecting to a remote printer shared on a Windows print server. Errors that Microsoft lists are: 0x000006e4 (RPC_S_CANNOT_SUPPORT), 0x0000007c (ERROR_INVALID_LEVEL), 0x00000709 (ERROR_INVALID_PRINTER_NAME)
      • Microsoft is investigating the issue.

 

I await with bated breath...

Edited by ITGuyNW
Posted
0x000006e4 (RPC_S_CANNOT_SUPPORT)

 

0x0000007c (ERROR_INVALID_LEVEL)

 

0x00000709 (ERROR_INVALID_PRINTER_NAME)

 

Balls. I've seen at least two of those from the October patch. Oh well.

Posted

Nothing in there that suggests a fix for my problem... but have they even acknowledged this is actually a problem?

 

I've got to admit though results seem to be very fragmented even within the IT community. There are whole threads devoted to 'WAAAAAAH!!!! I CAN'T PRINT' interspersed with posts from people saying they are 'all patched up to date and printing is fine'...

 

I don't even know what the actual problem is! All I know is that as soon as I put October CU on a client it stops printing (none of the previous workarounds... work)...

 

Back when this started it was universal pretty much, you installed August CU and it killed printing for everyone on the planet.

 

Now it seems that obviously with the endless permutations of people's set-ups it's difficult to compare and contrast (server and client OS, printer makes/models/drivers, various workarounds and fixes), the waters are getting a little muddy and not everyone seems to have the same problems.

 

Some can't install printers, some can... some can't print, some can... Is it a server setting (August/September) or a problem with something on the client (October), is it something MS switched on in an update that you don't know about and haven't added a registry key for to allow it to communicate, is it extra security (NTLM vs. Kerberos), is it specific firewall ports (RPC)...???

Posted (edited)

Some interesting stuff happening over here:

 

https://www.bleepingcomputer.com/forums/t/759880/kb5006670-network-printer-problems-again-this-month/?p=5278335

 

EDIT: I doubt the linked page will ever disappear, but a quick summary below...

 

"I have been plagued with the 0x0000007c error message on the Student endpoints we support. I have had a ticket open with Microsoft while they have been trying to fix the issue with us. Yesterday M$ support supplied me with an ADMX installer for the local machine that disables/reverts the change made in the October update that broke printing for us. The ADMX installer literally sets the following registry key and printing for us once again functions. M$ also informed me that a fix is coming in December, possibly sooner but don't hold your breath. I thought if this solution worked for me maybe others would be willing to try the reg setting. This setting is for versions 2004, 20H2, 21H1 and 21H2. M$ also provided the installers for 1809, 1909 and server 2019, but I did not install those to export the regkey changes. M$ also informed me that this change will need to be backed out once the December "fix" is released."

 

2004, 20H2, 21H1, 21H2

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]

"713073804"=dword:00000000

 

1909

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]

"1921033356"=dword:00000000

 

1809

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]

"3598754956"=dword:00000000

Edited by Koldov
  • Thanks 2
Posted (edited)
I've just tried that on my test VM - it fixed it on there. Going to try on actual machines affected by it now. Edited by Norphy
Posted
But does this expose the original vulnerability ?

 

Well, yes, I suppose it would do but if it's a choice between:

 

1) Exposing that specific vulnerability

2) Removing the October patch and exposing all the vulnerabilities

3) Users shouting at me because they can't print

 

I'll take the first option I think

Posted
For what it's worth, I've just tried this on real production hardware running 1909 that was getting the "0x00006e4" error when it tried to map a printer queue with the KB5006667 patch installed - it's now able to map printers with that registry key.
  • Thanks 1
  • 2 weeks later...
Posted
Posted

 

Did you manage to get any further testing done to confirm this solves the printer nightmare issues?

 

We moved onto Type 4 drivers where we could but that caused us other minors issues down the road..

Posted
Did you manage to get any further testing done to confirm this solves the printer nightmare issues?

 

We moved onto Type 4 drivers where we could but that caused us other minors issues down the road..

 

It solves the issue when you're mapping a new printer queue and you get either 0x000006e4 or 0x00000709 error messages, a fault that was introduced with the October patch. If you're using Point and Print and installing printer drivers when you're mapping the queue, you still need to put in the AllowNonAdminsToInstallDrivers registry entry, or whatever it was called.

  • Thanks 1
Posted
It solves the issue when you're mapping a new printer queue and you get either 0x000006e4 or 0x00000709 error messages, a fault that was introduced with the October patch. If you're using Point and Print and installing printer drivers when you're mapping the queue, you still need to put in the AllowNonAdminsToInstallDrivers registry entry, or whatever it was called.

Thanks for confirming. I'm going to start testing this to a handful of machines and see if we can't get back to something workable,

 

Roll on site wide managed printing and we can ditch these legacy printers! :D

Posted
Our solution is to deploy all printerdrivers to endpoints in advanced. Printerservers and workstations are all up-to-date and security best practices regarding to Printernightmare in place like registry to only allow administrators to install drivers our users can choose their own network printer which are published in ActiveDirectory. No admin credential prompts for regular users. Printers are deployed using PnPUtil which is available in Windows 10 by default.
  • 2 weeks later...
Posted

is this still causing people problems ?

 

Not had time to go through all 20 pages but we are starting to see print issues after some windows updates.

Not sure if it is this driver issue though: some people can print ok, others get

"Access Denied unable to connect"

and in event log for PrintService

Win32 error code returned by the print processor: 283.

:(

  • Thanks 1
Posted
is this still causing people problems ?

 

I'm more surprised that it seems it isn't still causing huge problems as the various printing threads have been fairly quiet recently (or maybe people are just bored with talking about it)...

 

I haven't revisited this since I stopped the October (and November) client updates!

 

I think there might have been recent updates that have cured it for the 20H & 21H brigade (?), but on my test clients both October and November updates just kill printing dead and I haven't seen anything released for lower versions yet that fix it (although we might be reasonably unique in having 2012R2 print server and LTSC clients)...

  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...