• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Unable to install printer

Scheduled Pinned Locked Moved
Bug Reports
4
30
4.4k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S
    Sebastian Roth Moderator
    last edited by Oct 1, 2021, 2:15 PM

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

    Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

    Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

    G 1 Reply Last reply Oct 2, 2021, 1:25 PM Reply Quote 0
    • G
      george1421 Moderator @Sebastian Roth
      last edited by Oct 2, 2021, 1:25 PM

      @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.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      1 Reply Last reply Reply Quote 0
      • T
        tatanas
        last edited by Oct 4, 2021, 6:23 AM

        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

        T 1 Reply Last reply Oct 4, 2021, 8:25 AM Reply Quote 0
        • T
          tatanas @tatanas
          last edited by Oct 4, 2021, 8:25 AM

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

          1 Reply Last reply Reply Quote 0
          • T
            tatanas
            last edited by Oct 4, 2021, 1:15 PM

            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 ?

            1 Reply Last reply Reply Quote 0
            • T
              tatanas
              last edited by Oct 4, 2021, 2:10 PM

              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 ?

              1 Reply Last reply Reply Quote 1
              • S
                Sebastian Roth Moderator
                last edited by Sebastian Roth Oct 4, 2021, 10:16 AM Oct 4, 2021, 4:07 PM

                @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/

                Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                T 1 Reply Last reply Oct 5, 2021, 6:56 AM Reply Quote 0
                • T
                  tatanas @Sebastian Roth
                  last edited by tatanas Oct 5, 2021, 1:03 AM Oct 5, 2021, 6:56 AM

                  @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.

                  T 1 Reply Last reply Oct 5, 2021, 1:09 PM Reply Quote 0
                  • T
                    tatanas @tatanas
                    last edited by Oct 5, 2021, 1:09 PM

                    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.

                    1 Reply Last reply Reply Quote 0
                    • T
                      tatanas
                      last edited by Oct 13, 2021, 6:42 AM

                      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.

                      1 Reply Last reply Reply Quote 2
                      • 1
                      • 2
                      • 2 / 2
                      • First post
                        Last post

                      234

                      Online

                      12.0k

                      Users

                      17.3k

                      Topics

                      155.2k

                      Posts
                      Copyright © 2012-2024 FOG Project