Here is the issue, I’ll try to make this clear as possible.
We have 7 printers which are located offside, and have a direct tunnel to this site. Two different domains are able to print to these printers, but we are having an interesting issue with just 1 printer.
-Domain 1 (mine) prints through either a 2003 or 2008r2 print server. Users are either on a physical workstation or VM.
-Domain 2 prints direct TCP/IP from physical machines with 0 issues.
When I print to this printer from my VM, there are no issues. When I print from my physical workstation, I run into issues.
The issue is with spooling. I send the print job on my physical box, it spools a test page for 30 seconds, then begins to process the doc size, and eventually prints. My VM however, prints instantly. If the print job is multiple pages, this will spool to the point where it times out.
I’ve ruled out drivers, and it occurs when directly printing from both servers.
I want to say this is on the network layer and how the VLANs are configured, but don’t want to point the finger just yet… Is there anything I’m missing before pointing the finger elsewhere?
Another option to check is locally on the PC, go to the above settings and click the ports tab. Is it using a standard TCP/IP port?
<EDIT> Can domain 1 talk to the print servers without VPN connection? If so the VM maybe using that network to communicate to the print server, therefore making it faster. While the PC is using the VPN link (typically slower) and timing out. Check your routes.
The printer in question is at different building as our print servers. I was unsure of the connection between the two buildings, but it is VPN. The VPN only exists for our users, on our domain, under their roof.
Any physical PC, whether under my roof or their roof (on our domain), which points to the print server, has this spooling issue.
Any VM printing through the same print server, here or there, prints instantly.
VM’s and physical boxes are on a different VLANs… I did notice that the primary/secondary DNS addresses are flipped, which is getting me thinking about this theory.
If the primary DNS is not set correctly, and the physical workstations are hitting this address first…It will time out then look to the secondary DNS which allows it to print (which might explain the hanging…) Am I onto something here?
I took my shitty printer and ran Wireshark on my physical box while sending a test print. Filtering out the destination IP address I found that there were SNMP request('s) being sent to the printer, before the print job spooled.
The first request ran, and timed out every 3 seconds for 6 attempts. Then the second request went the same, 3 seconds for 6 attempts. Nothing was returned, and the print job eventually went through.
Okay, so 12 attempts at 3 seconds each… About 36 seconds. Hmm…
Ran a Wireshark from the good printer. 2 requests, 2 responses in less than a second.
Went back to the print object and found a setting “Enable SNMP Communication” checked. Reviewed the firewall policy and found that VDI’s allow SNMP traffic, and physical workstations to be locked down. No other printers are running SNMP, so I just unchecked it.
That was my next suggestion. I ran into that with our color printer. THe SNMP box was checked and set to use some weird name. Printed to it…wouldn’t go through. Sometimes I’d get lucky and it’d print by the end of the day. Tried updating the firmware. Instead of updating it, the printer physically printed out the firmware. Cleared the box…everything worked like a charm.
