Unable to install printer

[Sebastian Roth]

@tatanas Maybe the changes that came when MS fixed the printer nightmare issue is causing the problem.

[george1421]

@sebastian-roth said in Unable to install printer:

Maybe the changes that came when MS fixed the printer nightmare issue

I had to deal with this last week on my campus. (TBH I only skimmed this thread, so this may be a bit off point). The windows accumulative patch for September for both the servers and workstations broke printing for me on the older legacy systems. If you have a currently supported and fully patch version of 2012, 2016, 2019, or what ever is being patched on windows 10 printing worked normally. If you had anything less than 2012 or unpatched win10 or less the users could not print to a current windows print server or install new printers.

It appears in the sept patch MS turned on encrypted communications on the print spooler. I can’t find the article I found at the moment but the workaround is to disable the encryption using the registry key here: https://borncity.com/win/2021/09/20/windows-september-2021-update-workaround-fr-druckprobleme/ Look at the post by Benjamin. I’m not saying this is your problem here with the fog client, but setting this registry value to 0 will allow legacy windows devices to print to contemporary windows print spoolers.

[tatanas]

Unfortunately, the problem is still the same after changing 2 registry keys :
(printer nightmare)
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint]
“RestrictDriverInstallationToAdministrators”=dword:00000000

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print]
“RpcAuthnLevelPrivacyEnabled”=dword:00000000

[tatanas]

New test : After upgraded a Windows 7 host (Fog printer ok) to Windows 10, Fog printer installation didn’t work anymore.

[tatanas]

And another one :
Using the printui command (same as the one used in client source code) remotely with psexec, generate a rights error from windows when -s argument is used (execute as system account).
As administrator, the printer is installed fine.

How fog client executes the printui command localy ? as system or logged on user ?

[tatanas]

EUREKA !

In the Fog service properties, I change the “Open session as” in Connection Tab from “Local system account” to “Administrator” with his current password.
Then I reset the client Encryption Data on the Fog web console, restart the Fog client service and Voilà ! All printers are installed.

Now we need to find why this problem appears “randomly” on host which was working fine ?

[Sebastian Roth]

@tatanas Great work!!!

Using the printui command (same as the one used in client source code) remotely with psexec, generate a rights error from windows when -s argument is used (execute as system account).
As administrator, the printer is installed fine.

You hit the nail on the head with this finding I reckon! It’s probably something MS changed due to the printer nightmare findings/issues that is now breaking the printer install through SYSTEM account (used to run FOGService).

We’ll need to do more research on this particular point and I am fairly sure we’ll find others in a similar situation.

https://libredd.it/r/sysadmin/comments/ppdztz/microsoft_september_rollup_just_broke_around_122/
https://www.reddit.com/r/sysadmin/comments/p5inas/deploying_printers_to_users_post_print_nightmare/

[tatanas]

@sebastian-roth Well well well… I just test the “fix” (change fog service to administrator access) on another computer and… it didn’t work.
I checked the KB installed too and the print nightmare one is not installed.

It seems the problem is coming from the printui command executed as system account but why ?

I read that printui is not verbose at all (pretty hard to debug) and printer installation should be done with WMI (like the Port installation in the Fog Client source code).

I will continue my tests.

[tatanas]

After few tests on different computers, the service trick seems to work. (I guess the failed computer was an exception…)
All the registry values related to nightmare patch don’t fix this problem.
There is something about the execution of printui as system account. And not all printui command because the one which delete printers (from Fog web console) works fine.

[tatanas]

Finally I found where the problem came from !

We are using a NAS Synology to share the printers drivers. It’s a share accessible without password (guest account enable on the NAS). We’ve got no access problem to this share at anytime.
This NAS is joined to the domain… And here is the problem !

As soos as we unjoined the NAS from the domain, FOG printers are pushed without problem.

I don’t know why but if you execute printui command as local system account when the drivers files are shared on a NAS member of a domain, there is an access error. If you try the same command as local Administrator, it works…

So unjoining the NAS from the domain was the solution.