none
network printer (like \\server\printer) always takes 45 seconds to add after spooler service restart (firewall)

Answers

  • Ok, what firewall ports does the print server (print spooler service) need open?  I see in procmon, the client spoolsv is trying to go to port 49686 on the server (spoolsv), and it says success, but the length is 0.  That port isn't open on the firewall.  On a server on my desktop that works, the port is 49668.  I've seen port 63939 used too.  It looks like it fails with the high port, and then goes to port 135 (epmap) for everything.

    EDIT:  Is this registry entry safe to use?  HKLM\System\CurrentControlSet\Control\Print\DisableRpcTcp=1(dword)




    • Edited by JS2010 Thursday, May 17, 2018 8:30 PM
    • Marked as answer by JS2010 Friday, May 18, 2018 2:17 PM
    Thursday, May 17, 2018 4:37 PM
  • Ah, that explains the 45 second delay now if you are intentionally forcing the spooler back to Server 2003 days.  It's not a common practice to block the high port range so this issue is not that common but has been encountered previously as the linked post in this forum from 2011 points out.

    The spooler service uses a dynamic TCP port provided by the system when it starts.  So any port should be allowed between 49152-65535

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/e5046cbf-1e1f-4831-b51e-a3d4318b92b4/spoolsvexe-using-a-port-in-the-dynamic-range-how-to-set-it-to-a-static-port?forum=winserverprint

    Are you currently setting HKLM\System\CurrentControlSet\Control\Print\DisableRpcTcp=1?

    That should force the spooler to funnel all traffic to the client computers over ports 135 and 445 and force the spooler to use Server named pipes rather than Async RPC.

    How much printing is happening in the environment?  You can slow down the spooler when not using Async RPC.


    Alan Morris formerly with Windows Printing Team


    Friday, May 18, 2018 3:54 AM
    Answerer

All replies

  • Hi,
    Based on the complexity and the specific situation, we need do more researches. If we have any updates or any thoughts about this issue, we will keep you posted as soon as possible. Your kind understanding is appreciated. If you have further information during this period, you could post it on the forum, which help us understand and analyze this issue comprehensively.
    Sorry for the inconvenience and thank you for your understanding and patience.
    Best Regards,

    Frank

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, May 4, 2018 5:51 AM
  • I can reproduce the same behavior in a Windows 7 client.

    Monday, May 7, 2018 3:06 PM
  • Hi,

    Have you checked if this is related to downloading the print driver?

    You can check the c:\windows\inf\setupapi.dev.log file for the timestamp when the files are copied to the temp directory and when the files are staged into c:\windows\system32\driverstore\filerepository

    After a spooler restart, the service is not immediately active until a call is performed that kicks the service to wake up.  The default wait time is 60 seconds but an add printer call should get it stirring sooner. 

    Can you call get-printer *, then add-printer with faster response?

    I do suspect the print driver download has some weight here.  Type 3 print drivers are always downloaded even if they are already installed on the client machine.  If the downloaded version is the same as the preinstalled, then the spooler will kick it to the side and clean up the temp file download folder.


    Alan Morris formerly with Windows Printing Team

    Tuesday, May 8, 2018 5:31 AM
    Answerer
  • It's not related to downloading the driver.  Nothing new is in setupapi.dev.log at that time.  Running 'get-printer *' first doesn't help.  I'm running process monitor, and there's not much "category is write" i/o.



    • Edited by JS2010 Wednesday, May 9, 2018 12:32 PM
    Tuesday, May 8, 2018 7:31 PM
  • Just out of curiosity what kind of printer is it? 

    I have seen this issue in specific HP Printers, but Canon, Ricoh, and Xerox don't show the same issues.. 

    I was wondering if you had the issue in HP, in my findings it was caused by the stupid HP printer going to powersave Sleep mode causing the spooler service to hang since it couldn't find the active printer. 

    I was able to prove this theory by manually waking up the printer before rebooting the client, and there was no delay.. so they have all be replaced with canon's.. and no more issue.. 

    I tried to get HP to help, but they are about as useful as a printer that can't wake itself up. 


    Rob

    Tuesday, May 8, 2018 7:48 PM
  • I have different printers, HP, Kyocera, Ricoh.  The same thing happens whether they are asleep or awake.


    Strange, a print queue with a driver called 'PaperCut Global PostScript' (33k) adds fast in 1 second after a spooler restart.  It seems like something related to the size of the driver.  (EDIT:  This isn't always true.)


    EDIT
    Does loading or verifying the driver take that long?


    • Edited by JS2010 Friday, May 18, 2018 2:13 PM
    Tuesday, May 8, 2018 9:02 PM
  • I have different printers, HP, Kyocera, Ricoh.  The same thing happens whether they are asleep or awake.


    Strange, a print queue with a driver called 'PaperCut Global PostScript' (33k) adds in 1 second after a spooler restart.  It seems like something related to the size of the driver.



    The PaperCut is a driver designed for X86 machines, do you still have XP machines on your network? 

    Otherwise i would look at your drivers and remove the X86 drivers from the Print Server, this should actually greatly help performance across the board.. 

    If i remember correctly that driver is designed to help bridge the gap between the X86 print spooler service and printing to a multi-cartridge color copier.. something the early drivers didn't handle well.. 


    Rob

    Wednesday, May 9, 2018 12:13 PM
  • That Papercut driver is 64-bit according to Print Management.

    Wednesday, May 9, 2018 7:09 PM
  • Interesting, Guess that blows my solution out of the running.. LOL.. oh well good luck.. 


    Rob

    Wednesday, May 9, 2018 7:18 PM
  • So this isn't a common problem?

    Wednesday, May 9, 2018 7:20 PM
  • Honestly in all my years of running both Printer Servers, and Print servers using Microsoft Print services with Group Policy, usually the only issues i have run into is. 

    1. You have old drivers installed on the print server, that don't need to be there

    2. You have x86 drivers installed, being used on an x64 client, which causes issues too. 

    Outside of those two issues, they typically are just ps, or pcl driver, and done.. nothing really to maintain. 

    That said, when you have Citrix Terminals in the mix.. then you get other issues.. 

    But from the server side, there's not much to it.. 

    My only recommendation.. 

    Rebuild the print server, use 2016 and add the Print services into AD, and use Policy to publish printers, its super easy to setup, and will get rid of these hiccups since it is new.. 


    Rob


    Wednesday, May 9, 2018 7:24 PM
  • I've had no problems with lpr type printers in windows for years.  But now switching to per user \\server\printer type printers is becoming a challenge.  It took me weeks to figure out that CSR or Client-Side Rendering was saving users' printers and adding them back (or making the printer add fail) if their profile was deleted before logging in again.


    Now it doesn't look like any driver is faster than any other.










    • Edited by JS2010 Friday, May 18, 2018 2:21 PM
    Wednesday, May 9, 2018 8:55 PM
  • The PaperCut Global PostScript driver is 32bit and 64bit.  It's just a PPD that uses the core Windows pscript components so platform is not an issue.

    The driver download from the server would be the PPD, INF, and CAT files.  The other Windows components would be loaded by the client system not loaded from the server.


    Alan Morris formerly with Windows Printing Team

    Thursday, May 10, 2018 5:12 AM
    Answerer
  • Have you ruled out a DNS issue by using \\IPAddress\Printer vs the Servername? 


    Rob

    Thursday, May 10, 2018 3:51 PM
  • Yes, thanks.  Do you use \\server\printer style printers?

    Thursday, May 10, 2018 4:03 PM
  • I used to.. but now i have everything integrated.. 

    I run 2012R2 Domain controllers, one of the DC's i have Print manager installed, 

    and on one of my file servers i have Print manager installed where the printers are actually installed. The Print Manager on the DC is just used to publish my printers through group policy. 

    What does this do for me over \\Server\printer.. 

    On the one side i no longer install anything on anyone's machines, they are all setup to use group policy to publish printer directly on there machines, i don't install anything.. Group policy does this the moment they log into the machine. 

    If the user moves PC's to another location in the building the computer policy will install the correct printers based on the users physical location. 

    All printers and additional systems are setup to use IP address, nothing uses DNS, or Domain names, this is due to my Network though, as i created another /24 subnet with a different scope and setup a network hairpin through my router, to allow the other subnet(s) to communicate with my wired and wireless network devices, this allows me to segregate my printers and not chew up IP addresses that are used for desktops, which is another subnet from servers and wireless.. 



    Rob

    Thursday, May 10, 2018 4:15 PM
  • Ok, what firewall ports does the print server (print spooler service) need open?  I see in procmon, the client spoolsv is trying to go to port 49686 on the server (spoolsv), and it says success, but the length is 0.  That port isn't open on the firewall.  On a server on my desktop that works, the port is 49668.  I've seen port 63939 used too.  It looks like it fails with the high port, and then goes to port 135 (epmap) for everything.

    EDIT:  Is this registry entry safe to use?  HKLM\System\CurrentControlSet\Control\Print\DisableRpcTcp=1(dword)




    • Edited by JS2010 Thursday, May 17, 2018 8:30 PM
    • Marked as answer by JS2010 Friday, May 18, 2018 2:17 PM
    Thursday, May 17, 2018 4:37 PM
  • Ah, that explains the 45 second delay now if you are intentionally forcing the spooler back to Server 2003 days.  It's not a common practice to block the high port range so this issue is not that common but has been encountered previously as the linked post in this forum from 2011 points out.

    The spooler service uses a dynamic TCP port provided by the system when it starts.  So any port should be allowed between 49152-65535

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/e5046cbf-1e1f-4831-b51e-a3d4318b92b4/spoolsvexe-using-a-port-in-the-dynamic-range-how-to-set-it-to-a-static-port?forum=winserverprint

    Are you currently setting HKLM\System\CurrentControlSet\Control\Print\DisableRpcTcp=1?

    That should force the spooler to funnel all traffic to the client computers over ports 135 and 445 and force the spooler to use Server named pipes rather than Async RPC.

    How much printing is happening in the environment?  You can slow down the spooler when not using Async RPC.


    Alan Morris formerly with Windows Printing Team


    Friday, May 18, 2018 3:54 AM
    Answerer
  • We haven't tried disabling print rpc yet.  Where is the port range of 49152-65535 for the print spooler service documented?  I tried looking here under number 36., but it just says same as the "File and Printer Sharing" feature, which isn't on the page.  A lot of other services say "random port number".  https://support.microsoft.com/en-us/help/832017/service-overview-and-network-port-requirements-for-windows


    EDIT:  I would think it would be very common for some kind of external firewall to block these high ports.  Things still work, just not as well.  I don't think the print spooler ports used are clearly documented.




    • Edited by JS2010 Friday, May 18, 2018 2:42 PM
    Friday, May 18, 2018 5:44 AM
  • yes, that documentation is for the spooler design from Server 2003.  Clearly no one from the print team was involved with the doc.

    In Server 2008, the spooler defaults are not named pipes.  The spooler will fall back to this design when named pipes are not supported on the client, Windows XP for example, but the default is to use Async RPC rather than named pipes in the Server service.  Async RPC is more scalable than the 2003 methods used, thus the design change.

    There's a link in the doc above to set a limited port range in RPC if you wanted to go down the path.  I do not know if that would work but I suspect if RPC is limited to dishing out a lower port range, then the higher port range would not be available to the spooler service.

      


    Alan Morris formerly with Windows Printing Team

    Friday, May 18, 2018 5:31 PM
    Answerer
  • In our case, we resolved it with the VM dept.

    Friday, May 18, 2018 5:51 PM