Troubleshooting Printer Discovery with Mobility Print

KB Home   |   Troubleshooting Printer Discovery with Mobility Print

Main.MobilityPrintersNotFound History

Hide minor edits - Show changes to output

February 13, 2019, at 06:18 AM by Mel Zouzoulas - Removed the category because it's in the help center now
Changed lines 84-85 from:
----
''Categories:'' [[Category.MobilityPrint|+]]
to:
January 11, 2019, at 11:30 PM by employee 82 - Steps on finding NameServers and SearchDomain attributes for Chromebooks.
Changed lines 21-22 from:
*'''Android and Chrome''': it's possible to check the DNS server, but not the DNS Search Domain from these devices.
to:
*'''Chromebooks''': From any Chrome tab, go to @@chrome://system@@. In the left-hand column, find @@network-status@@, then hit the Expand button, then under @@[=IPConfigs=]@@, find the @@[=NameServers=]@@ and @@[=SearchDomains=]@@ attributes.
*'''Android
''': it's possible to check the DNS server, but not the DNS Search Domain from these devices.
September 24, 2018, at 05:16 PM by Aaron Pouliot - Clarified TCP Port 53 note
Changed line 43 from:
** TCP Port 53 warrants a special note... Before the days of DNSSEC it was common advice to block this port to prevent all of the DNS records on a server being disclosed through a zone transfer.  However, there's no benefit to blocking TCP Port 53 on your Mobility Print server, and it is necessary to work because if a packet is over 512 bytes, DNS will switch from using UDP port 53 to TCP port 53.  If this port is blocked, then a funny situation happens where it's possible to share 1 or 2 printers using Mobility, but when a larger number are shared then printer discovery will fail.  Long story short: make sure TCP Port 53 is open.
to:
** TCP Port 53 warrants a special note... Before the days of DNSSEC it was common advice to block this port to prevent all of the DNS records on a server being disclosed through a zone transfer.  However, there's no benefit to blocking TCP Port 53 on your Mobility Print server, and it is necessary to work because DNS will use TCP port 53 for any packet over 512 bytes.  If this port is blocked, then a funny situation happens where it's possible to share 1 or 2 printers using Mobility, but when a larger number are shared then printer discovery will fail.  Long story short: make sure TCP Port 53 is open.
September 24, 2018, at 05:14 PM by Aaron Pouliot - Clarified TCP Port 53 note
Changed line 43 from:
** TCP Port 53 warrants a special note... This port was commonly blocked across networks because of old security vulnerabilities, however this is definitely needed for Mobility Print to work.  If a packet is over 512 bytes, DNS will switch from using UDP port 53 to TCP port 53.  If this port is blocked, then a funny situation happens where it's possible to share 1 or 2 printers using Mobility, but when a larger number are shared then printer discovery will fail.  Long story short: make sure TCP Port 53 is open.
to:
** TCP Port 53 warrants a special note... Before the days of DNSSEC it was common advice to block this port to prevent all of the DNS records on a server being disclosed through a zone transfer.  However, there's no benefit to blocking TCP Port 53 on your Mobility Print server, and it is necessary to work because if a packet is over 512 bytes, DNS will switch from using UDP port 53 to TCP port 53.  If this port is blocked, then a funny situation happens where it's possible to share 1 or 2 printers using Mobility, but when a larger number are shared then printer discovery will fail.  Long story short: make sure TCP Port 53 is open.
September 12, 2018, at 11:46 PM by Aaron Pouliot - Removed the http://rpc.pc-printer-discovery:9163/printers test because this doesn't always work.
Deleted lines 74-76:
*http://rpc.pc-printer-discovery:9163/printers
**This is the final test, and this is what the Mobility Print client will query to discover the printers.
**If you can't access this URL, then make sure that the client is configured with the correct DNS Search Suffix.
August 31, 2018, at 09:18 PM by Aaron Pouliot - Added more detail about TCP port 53.
Added line 43:
** TCP Port 53 warrants a special note... This port was commonly blocked across networks because of old security vulnerabilities, however this is definitely needed for Mobility Print to work.  If a packet is over 512 bytes, DNS will switch from using UDP port 53 to TCP port 53.  If this port is blocked, then a funny situation happens where it's possible to share 1 or 2 printers using Mobility, but when a larger number are shared then printer discovery will fail.  Long story short: make sure TCP Port 53 is open.
August 14, 2018, at 10:31 PM by Aaron Pouliot - Added link to new troubleshooting mDNS kb
Deleted lines 4-5:
'''Note that the troubleshooting steps below are for troubleshooting printer discovery if you have set up the DNS records. They are not relevant if you have configured Mobility Print to use mDNS.'''
Added lines 6-7:

'''Note that the troubleshooting steps below are only for troubleshooting printer discovery if you have set up the DNS records. If your Mobility Print server is sharing the printers using the default mDNS, please have a look at [[https://www.papercut.com/kb/Main/MobilityPrintWithMDNS|this article]] instead.'''
June 12, 2018, at 06:54 PM by Aaron Pouliot -
Deleted line 59:
[[<<]]
June 12, 2018, at 06:53 PM by Aaron Pouliot - Added note on how to check active ports.
Changed lines 46-47 from:
**Verify that no other BYOD printing software is installed, or that the services have been completely stopped.
to:
**Verify that no other BYOD printing software is installed, or that the services have been completely stopped.
**A simple way to check this on a Windows Mobility Print server is to open an elevated command prompt Window and run @@netstat -abn@@ to show what applications are listening on each port.  Make sure that no other applications are using ports 53 and 5353
.
Changed lines 59-60 from:
To flush the DNS cache in Windows, run @@ipconfig /flushdns@@ in an elevated command prompt.
[[<<]] To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
to:
**To flush the DNS cache in Windows, run @@ipconfig /flushdns@@ in an elevated command prompt.
[[<<]]
**
To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
June 04, 2018, at 03:40 PM by Mel Zouzoulas - Added link to the Mobility Print help center = good SEO
Added lines 81-82:

For more information about Mobility Print, check out the [[https://www.papercut.com/products/ng/mobility-print/manual/| Mobility Print Help Center]].
May 08, 2018, at 10:01 PM by Aaron Pouliot - mentioned TCP and UDP ports
Changed line 42 from:
**Confirm that ports 9163, 9164, 53 are open on the server, and are not being blocked on a network or host-based firewall.
to:
**Confirm that TCP ports 9163, 9164, as well as TCP & UDP ports 53 are open on the server, and are not being blocked on a network or host-based firewall.
April 30, 2018, at 05:53 PM by Aaron Pouliot - Added Category MobilityPrint
Added lines 82-83:
----
''Categories:'' [[Category.MobilityPrint|+]]
April 24, 2018, at 05:27 PM by Aaron Pouliot -
Changed lines 48-49 from:
*'''Are only MacOS and iOS devices having trouble discovering the printers? Confirm the subnets match.'''
This only applies if you specified the subnets when setting up the DNS records (to restrict printer access per subnet or because the domain name ends in .local) because this will create a different type of DNS records for Apple devices where the B and LB records are stored within a reverse lookup zone.  However, for this to work successfully  the reverse lookup zone exactly match the subnet of the device. If creating DNS records for two subnets like 10.0.1.0/24 and 10.0.2.0/24, then 10.0.1.0/23 cannot be used as a shortcut. See the [[https://www.papercut.com/kb/Main/MobilityPrintDNSRecordExamples|DNS Record Examples]] knowledge base article for more details on how this works.
to:
*'''Are only [=MacOS=] and iOS devices having trouble discovering the printers? Confirm the subnets match.'''
**This only applies if you specified the subnets when setting up the DNS records (to restrict printer access per subnet or because the domain name ends in .local) because this will create a different type of DNS records for Apple devices where the B and LB records are stored within a reverse lookup zone.  However, for this to work successfully  the reverse lookup zone must exactly match the subnet of the device. If creating DNS records for two subnets like 10.0.1.0/24 and 10.0.2.0/24, then 10.0.1.0/23 cannot be used as a shortcut. See the [[https://www.papercut.com/kb/Main/MobilityPrintDNSRecordExamples|DNS Record Examples]] knowledge base article for more details on how this works.
April 24, 2018, at 05:25 PM by Aaron Pouliot - Added information to explain why MacOS and iOS devices can't discover printers
Added lines 47-49:

*'''Are only MacOS and iOS devices having trouble discovering the printers? Confirm the subnets match.'''
This only applies if you specified the subnets when setting up the DNS records (to restrict printer access per subnet or because the domain name ends in .local) because this will create a different type of DNS records for Apple devices where the B and LB records are stored within a reverse lookup zone.  However, for this to work successfully  the reverse lookup zone exactly match the subnet of the device. If creating DNS records for two subnets like 10.0.1.0/24 and 10.0.2.0/24, then 10.0.1.0/23 cannot be used as a shortcut. See the [[https://www.papercut.com/kb/Main/MobilityPrintDNSRecordExamples|DNS Record Examples]] knowledge base article for more details on how this works.
March 27, 2018, at 03:24 PM by Artuto Almaguer -
Changed line 37 from:
*'''Were any changes made to the printers.conf.toml file to restrict printer access per subnet?'''
to:
*'''Were any changes made to the printer.conf.toml file to restrict printer access per subnet?'''
March 15, 2018, at 05:18 PM by Aaron Pouliot -
Added line 53:
**If the client has multiple DNS servers in their network settings, make sure the DNS server with the Mobility Print records comes first in the list.
Deleted line 56:
**If the client has multiple DNS servers in their network settings, make sure the DNS server with the Mobility Print records comes first in the list.
March 14, 2018, at 02:28 AM by Mel Zouzoulas - separated the commands to flush the DNS for Windows and MacOS
Changed line 55 from:
\\ To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
to:
[[<<]] To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
March 14, 2018, at 02:27 AM by Mel Zouzoulas - separated the commands to flush the DNS for Windows and MacOS
Changed line 55 from:
/n To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
to:
\\ To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
March 14, 2018, at 02:27 AM by Mel Zouzoulas - separated the commands to flush the DNS for Windows and MacOS
Changed line 55 from:
<br>To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
to:
/n To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
March 14, 2018, at 02:26 AM by Mel Zouzoulas - separated the commands to flush the DNS for Windows and MacOS
Changed line 55 from:
To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
to:
<br>To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
March 14, 2018, at 02:22 AM by Mel Zouzoulas - separated the commands to flush the DNS for Windows and MacOS
Deleted line 54:
March 14, 2018, at 02:22 AM by Mel Zouzoulas - separated the commands to flush the DNS for Windows and MacOS
Added line 55:
March 14, 2018, at 02:22 AM by Mel Zouzoulas - separated the commands to flush the DNS for Windows and MacOS
Changed lines 53-55 from:
**After making any changes in DNS, be sure that you flush the DNS cache on the client before testing again. To flush the DNS cache in Windows, run @@ipconfig /flushdns@@ in an elevated command prompt. To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
to:
**After making any changes in DNS, be sure that you flush the DNS cache on the client before testing again.
To flush the DNS cache in Windows, run @@ipconfig /flushdns@@ in an elevated command prompt.
To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
March 05, 2018, at 09:29 PM by Aaron Pouliot -
March 05, 2018, at 09:29 PM by Aaron Pouliot -
Changed lines 34-35 from:
**Log into the web interface of the Mobility Print server, if it still says "Discovering your printers..." then make sure you have at least one print queue set up on the server.
to:
**Log into the web interface of the Mobility Print server, if it still says "Discovering your printers..." this is because no printers have yet been found.  Make sure you have at least one print queue set up on the server.
**Note that Mobility Print will ignore any shared print queues from another print
server.
March 05, 2018, at 09:27 PM by Aaron Pouliot -
Changed line 34 from:
**Log into the web interface of the Mobility Print server and click on Printers.
to:
**Log into the web interface of the Mobility Print server, if it still says "Discovering your printers..." then make sure you have at least one print queue set up on the server.
March 05, 2018, at 07:08 PM by Aaron Pouliot - Added reference to new subnet filtering KB.
Added line 38:
**If you are attempting to set up these rules, then have a look at the troubleshooting steps [[https://www.papercut.com/kb/Main/SubnetFiltering|here]].
March 05, 2018, at 06:24 PM by Aaron Pouliot - Added screenshots for client DNS setting examples
Changed lines 18-20 from:
*'''Windows''': Network Connections >  [=IPv4=] > Properties > Advanced > DNS Tab
*'''
[=MacOS=]''': System Preferences > Network > Advanced > DNS Tab
*'''iOS''': Settings > [=WiFi=] > select the network > Configure DNS
to:
*'''Windows''': Network Connections >  [=IPv4=] > Properties > Advanced > [[https://www.papercut.com/kb/uploads/Main/Windows%20Client%20DNS%20Settings.png|DNS Tab]]
*'''[=MacOS=]''': System Preferences > Network > Advanced > [[https://www.papercut.com/kb/uploads/Main/MacOS%20Client%20DNS%20Settings.png|DNS Tab]]
*'''iOS''': Settings > [=WiFi=] > select the network > [[https://www.papercut.com/kb/uploads/Main/iOS%20Client%20DNS%20Settings.png|Configure DNS]]
March 01, 2018, at 01:18 AM by Aaron Pouliot - italics
Changed line 3 from:
"Help! I've set up PaperCut Mobility Print and created the DNS records on my server, but devices still can't see the printers on the network! What should I check?"
to:
"''Help! I've set up PaperCut Mobility Print and created the DNS records on my server, but devices still can't see the printers on the network! What should I check?"''
March 01, 2018, at 12:08 AM by Aaron Pouliot -
Changed line 31 from:
**The the records are set up properly, then there should be a green check mark next to each after verifying them from the Mobility Print server. If not, then try comparing your DNS records these [[https://www.papercut.com/kb/Main/MobilityPrintDNSRecordExamples|DNS Record Examples]] to make sure they are set up correctly.
to:
**If you see any red X's when trying to verify your DNS records then compare them to these [[https://www.papercut.com/kb/Main/MobilityPrintDNSRecordExamples|these examples]] to make sure they are set up correctly.
March 01, 2018, at 12:05 AM by Aaron Pouliot - Added reference to new KB with DNS record examples.
Changed lines 30-31 from:
*Is the Mobility Print server able to successfully verify all of the records? 
**If not, then try comparing your DNS records these [https://www.papercut.com/kb/Main/MobilityPrintDNSRecordExamples|DNS Record Examples] to make sure they are set up correctly.
to:
*'''Is the Mobility Print server able to verify all of the records?'''
**The the records are set up properly, then there should be a green check mark next to each after verifying them from the Mobility Print server. If not, then try comparing your DNS records these [[https://www.papercut.com/kb/Main/MobilityPrintDNSRecordExamples|DNS Record Examples]] to make sure they are set up correctly.
March 01, 2018, at 12:03 AM by Aaron Pouliot -
Added lines 30-31:
*Is the Mobility Print server able to successfully verify all of the records?
**If not, then try comparing your DNS records these [https://www.papercut.com/kb/Main/MobilityPrintDNSRecordExamples|DNS Record Examples] to make sure they are set up correctly.
February 28, 2018, at 05:15 PM by Aaron Pouliot - Removed mention of port 5353, emphasized that these instructions are for DNS not mDNS.
Added lines 5-6:
'''Note that the troubleshooting steps below are for troubleshooting printer discovery if you have set up the DNS records. They are not relevant if you have configured Mobility Print to use mDNS.'''
Changed lines 10-11 from:
This is far and away the most common troubleshooting scenario.  In order to discover the published printers, clients must have the right DNS settings.  Note that the troubleshooting steps below are not relevant if you have configured Mobility Print to use mDNS.
to:
This is far and away the most common troubleshooting scenario.  In order to discover the published printers, clients must have the right DNS settings. 
Changed line 38 from:
**Confirm that ports 9163, 9164, 53, and 5353 are open on the server, and are not being blocked on a network or host-based firewall.
to:
**Confirm that ports 9163, 9164, 53 are open on the server, and are not being blocked on a network or host-based firewall.
February 28, 2018, at 12:58 AM by Aaron Pouliot - Adjusted formatting and wording on URL check method
Changed line 50 from:
!! Quickly check the configuration from a particular subnet or device type
to:
!!Check the configuration from a particular subnet or device type
February 28, 2018, at 12:56 AM by Aaron Pouliot -
Changed lines 50-54 from:
*'''Can you get to these URLs, from a test workstation connected to the correct network, with the correct DNS settings? Try these out, in the order provided:'''
**http://<mobility-print-IP-address>:9163/printers - tests that you can access the correct port and the mobility server IP address directly - you should see a bunch of text returned, listing all the properties of the printers you're advertising through Mobility Print. If you can't access this, check that you're connected to the right network... can you ping the mobility print server IP address... do you have a firewall blocking 9163...?
**http://<mobility-print-server-hostname>:9163/printers - tests the same thing, but ensures that DNS is able to resolve the Mobility Print Server hostname. If you can't access this, is the DNS A record for your Mobility Print Server correct?... Is the client pointing to the correct DNS server in the IP configuration...?
**http
://rpc.pc-printer-discovery.<domain-name>:9163/printers - ensures that the pc-printer-discovery record in the DNS setup is working correctly, without forcing it to use the search suffix. If you can't get to this URL, are your DNS records in place for pc-printer-discovery...?
**http://rpc.pc-printer-discovery:9163/printers - the final test, which ensures that you can get to the pc-printer-discovery URL to list the printers. If you can't access this URL, is the client configured with the correct DNS search suffix...?
to:
!! Quickly check the configuration from a particular subnet or device type
Try opening a web browser on a device, and make sure that you can browse to each one of these URLs in the order
provided:
*http://<mobility-print-IP-address>:9163/printers
**This tests that you can access the the Mobility Print server over the network and that port 9163 is open. 
**The correct output will be a list
of printers, or a JSON file containing a list of printers. 
**If this is inaccessible, then it could suggest the client cannot access
the port or IP of the Mobility Print server due to network configuration or firewall rules. 
*http://<mobility-print-server-hostname>:9163/printers
**This tests the same thing, but ensures that DNS is able to resolve the hostname of the Mobility Print server.
**If
this is inaccessible, then check the client DNS settings to confirm that the client pointing to the correct DNS server.
*http://rpc
.pc-printer-discovery.<domain-name>:9163/printers
**This test ensures that the pc-printer-discovery record is set up correctly in DNS.
**If this is inaccessible, then make sure that the DNS records are set up properly.
*http://rpc.pc-printer-discovery:9163/printers
**This is the final test, and this is what the Mobility Print client will query to discover the printers
. 
**If you can't access this URL, then make sure that the client is configured with the correct DNS Search Suffix.
February 23, 2018, at 08:41 PM by timg - Added URL steps.
Added lines 50-55:
*'''Can you get to these URLs, from a test workstation connected to the correct network, with the correct DNS settings? Try these out, in the order provided:'''
**http://<mobility-print-IP-address>:9163/printers - tests that you can access the correct port and the mobility server IP address directly - you should see a bunch of text returned, listing all the properties of the printers you're advertising through Mobility Print. If you can't access this, check that you're connected to the right network... can you ping the mobility print server IP address... do you have a firewall blocking 9163...?
**http://<mobility-print-server-hostname>:9163/printers - tests the same thing, but ensures that DNS is able to resolve the Mobility Print Server hostname. If you can't access this, is the DNS A record for your Mobility Print Server correct?... Is the client pointing to the correct DNS server in the IP configuration...?
**http://rpc.pc-printer-discovery.<domain-name>:9163/printers - ensures that the pc-printer-discovery record in the DNS setup is working correctly, without forcing it to use the search suffix. If you can't get to this URL, are your DNS records in place for pc-printer-discovery...?
**http://rpc.pc-printer-discovery:9163/printers - the final test, which ensures that you can get to the pc-printer-discovery URL to list the printers. If you can't access this URL, is the client configured with the correct DNS search suffix...?

Changed line 62 from:
[-Keywords: Mobility Print, Troubleshooting, Failed to retrieve printer list, DNS, Search Suffix, Search Domain, Printers not found, Secret squirrel -]
to:
[-Keywords: Mobility Print, Troubleshooting, Failed to retrieve printer list, DNS, Search Suffix, Search Domain, Printers not found, Secret squirrel -]
February 17, 2018, at 12:27 AM by Aaron Pouliot -
Changed line 56 from:
[-Keywords: Mobility Print, Troubleshooting, Failed to retrieve printer list, DNS, Search Suffix, Search Domain Secret squirrel -]
to:
[-Keywords: Mobility Print, Troubleshooting, Failed to retrieve printer list, DNS, Search Suffix, Search Domain, Printers not found, Secret squirrel -]
February 15, 2018, at 08:06 PM by Alan Morris - update keyword
Changed line 56 from:
[-Keywords: Mobility Print, Troubleshooting, Failed to retrieve printer list, DNS, Search Suffix, Search Domain-]
to:
[-Keywords: Mobility Print, Troubleshooting, Failed to retrieve printer list, DNS, Search Suffix, Search Domain Secret squirrel -]
February 08, 2018, at 05:51 AM by Aaron Pouliot - Edited formatting for readability.
Deleted line 19:
Changed lines 29-48 from:
!!!Can you confirm that at least one printer is being published?
*Log into the web interface of the Mobility Print server and click on Printers.

!!!Were any changes made to the printers.conf.toml file to restrict printer access per subnet? 
*If so, remove these rules until printer discovery can be tested first.

!!!Can you verify the ports are accessible and that clients can to access the Mobility Print server over the network?
*Confirm that ports 9163, 9164, 53, and 5353 are open on the server, and are not being blocked on a network or host-based firewall.

!!!Check for conflicting applications on the Mobility Print server, such as another BYOD Printing solution that will listen on port 53.
*Make certain that Mobility Print has not been installed on a DNS server or Domain Controller.
*Verify that no other BYOD printing software is installed, or that the services have been completely stopped.

!!!Is there a proxy or content filter in between the clients and the server? 
*This is rare, but we have heard of a few situations where managed Chromebooks were configured to pass through a content filter which was configured to drop DNS-SD or mDNS traffic.

!!!Examine the DNS records on the server to ensure they have been set up correctly.
*While testing, make sure that the DNS servers are fully
replicated.
*After making any changes in DNS, be sure that you flush the DNS cache on the client before testing again. To flush the DNS cache in Windows, run @@ipconfig /flushdns@@ in an elevated command prompt. To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
*If the client has multiple DNS servers in their network settings, make sure the DNS server with the Mobility Print records comes first in the list.
to:
*'''Can you confirm that at least one printer is being published?'''
**Log into the web interface of the Mobility Print server and click on Printers.

*'''Were any changes made to the printers.conf.toml file to restrict printer access per subnet?'''
**If so, remove these rules until printer discovery can be tested first.

*'''Can you verify the ports are accessible and that clients can to access the Mobility Print server over the network?'''
**Confirm that ports 9163, 9164, 53, and 5353 are open on the server, and are not being blocked on a network or host-based firewall.

*'''Check for conflicting applications on the Mobility Print server, such as another BYOD Printing solution that will listen on port 53.'''
**Make certain that Mobility Print has not been installed on a DNS server or Domain Controller.
**Verify that no other BYOD printing software is installed, or that the services have been completely stopped.

*'''Is there a proxy or content filter in between the clients and the server?'''
**This is rare, but we have heard of a few situations where managed Chromebooks were configured to pass through a content filter which was configured to drop DNS-SD or mDNS traffic.

*'''Is testing being done with the most up-to-date version of the DNS records?'''
**While testing, make sure that the DNS servers are fully
replicated.
**After making any changes in DNS, be sure that you flush the DNS cache on the client before testing again. To flush the DNS cache in Windows, run @@ipconfig /flushdns@@ in an elevated command prompt. To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
**If the client has multiple DNS servers in their network settings, make sure the DNS server with the Mobility Print records comes first in the list.
February 08, 2018, at 01:00 AM by Aaron Pouliot - attached screenshot
Added lines 4-5:

Attach:Failed_to_Retrieve_Printer_List.png
February 07, 2018, at 08:24 PM by Aaron Pouliot -
Changed line 24 from:
If the DNS Search Domain section is blank, then it can be manually configured on each user's device or it can be set on the DHCP server as DHCP Scope Option 119.The steps to do this will vary depending on what device is acting as DHCP server, but if you have a Windows DHCP server then follow these steps: https://technet.microsoft.com/en-us/library/dd572752.
to:
If the DNS Search Domain section is blank, then it can be manually configured on each user's device, although it would be much easier to set this for all clients on the subnet by configuring DHCP Scope Option 119 on the DHCP server. The steps to do this will vary depending on what device is acting as DHCP server, but if you have a Windows DHCP server then follow these steps: https://technet.microsoft.com/en-us/library/dd572752.
February 07, 2018, at 07:24 PM by Aaron Pouliot - formatting fixes
Changed line 46 from:
*After making any changes in DNS, be sure that you flush the DNS cache on the client before testing again. To flush the DNS cache in Windows, run "ipconfig /flushdns" in an elevated command prompt. To flush the DNS cache on MacOS open Terminal and run "sudo killall -HUP mDNSResponder".
to:
*After making any changes in DNS, be sure that you flush the DNS cache on the client before testing again. To flush the DNS cache in Windows, run @@ipconfig /flushdns@@ in an elevated command prompt. To flush the DNS cache on [=MacOS=] open Terminal and run @@sudo killall -HUP mDNSResponder@@.
Changed line 52 from:
Please send us a few screenshots of the DNS Records created for Mobility Print as well as the Mobility Print logs. To download the Mobility Print log files, simply click on the dots in the top right of the Mobility Print admin interface and then select Download Logs.&#8232; Then feel free to contact your Authorized Solutions Center for assistance, or log into our [[https://support.papercut.com/hc/en-us/requests/new/|Support Portal]] to start a request.
to:
Please send us a few screenshots of the DNS Records created for Mobility Print as well as the Mobility Print logs. To download the Mobility Print log files, simply click on the dots in the top right of the Mobility Print admin interface and then select Download Logs. Then feel free to contact your Authorized Solutions Center for assistance, or log into our [[https://support.papercut.com/hc/en-us/requests/new/|Support Portal]] to start a request.
February 07, 2018, at 07:21 PM by Aaron Pouliot -
Changed line 8 from:
In a nutshell...
to:
!!!Client DNS requirements:
Changed lines 12-17 from:
!!!Where to check the DNS settings on the client:

*Windows: Network Connections > IPv4 > Properties > Advanced > DNS Tab
*MacOS: System Preferences > Network > Advanced > DNS Tab
*iOS: Settings > WiFi > select the network > Configure DNS
*Android and Chrome: it's possible to check the DNS server, but not the DNS Search Domain from these devices.
to:
!!!Where to check the client DNS settings:

*'''Windows''': Network Connections >  [=IPv4=] > Properties > Advanced > DNS Tab
*'''[=MacOS=]''': System Preferences > Network > Advanced > DNS Tab
*'''iOS''': Settings > [=WiFi=] > select the network > Configure DNS
*'''Android and Chrome''': it's possible to check the DNS server, but not the DNS Search Domain from these devices.
February 07, 2018, at 07:16 PM by Aaron Pouliot -
February 07, 2018, at 07:16 PM by Aaron Pouliot -
Changed line 12 from:
!!!How to check the DNS settings on the client:
to:
!!!Where to check the DNS settings on the client:
February 07, 2018, at 07:15 PM by Aaron Pouliot -
Changed line 6 from:
This is far and away the most common troubleshooting scenario.  In order to discover the published printers, clients must have the right DNS settings.
to:
This is far and away the most common troubleshooting scenario.  In order to discover the published printers, clients must have the right DNS settings.  Note that the troubleshooting steps below are not relevant if you have configured Mobility Print to use mDNS.
February 07, 2018, at 07:10 PM by Aaron Pouliot -
Added lines 1-55:
(:title Troubleshooting Printer Discovery with Mobility Print:)

"Help! I've set up PaperCut Mobility Print and created the DNS records on my server, but devices still can't see the printers on the network! What should I check?"

!!Make sure clients have the correct DNS settings
This is far and away the most common troubleshooting scenario.  In order to discover the published printers, clients must have the right DNS settings.

In a nutshell...
*The client must be pointed towards the correct DNS server.
*The DNS Search Suffix (also known as the Search Domain) must exactly match the Forward Lookup Zone where the Mobility DNS were created.

!!!How to check the DNS settings on the client:

*Windows: Network Connections > IPv4 > Properties > Advanced > DNS Tab
*MacOS: System Preferences > Network > Advanced > DNS Tab
*iOS: Settings > WiFi > select the network > Configure DNS
*Android and Chrome: it's possible to check the DNS server, but not the DNS Search Domain from these devices.

Confirm that the DNS Server IP address is correct and that the DNS Search Domain matches the forward lookup zone where the Mobility Print records are stored exactly. For example, "pdx.papercutsoftware.com" is not the same as "papercutsoftware.com".

!!!What is a DNS Search Suffix?
When a DNS Search Suffix or Search Domain is specifed, the client will add this on to the end of any DNS query, allowing it to lookup a hostname on the DNS server without needing to know the domain. With regards to Mobility Print, the client must know this setting or it will not be able to look up the records on the DNS server.

If the DNS Search Domain section is blank, then it can be manually configured on each user's device or it can be set on the DHCP server as DHCP Scope Option 119.The steps to do this will vary depending on what device is acting as DHCP server, but if you have a Windows DHCP server then follow these steps: https://technet.microsoft.com/en-us/library/dd572752.

!!Clients have the right settings, but still can't see printers

!!!Can you confirm that at least one printer is being published?
*Log into the web interface of the Mobility Print server and click on Printers.

!!!Were any changes made to the printers.conf.toml file to restrict printer access per subnet?
*If so, remove these rules until printer discovery can be tested first.

!!!Can you verify the ports are accessible and that clients can to access the Mobility Print server over the network?
*Confirm that ports 9163, 9164, 53, and 5353 are open on the server, and are not being blocked on a network or host-based firewall.

!!!Check for conflicting applications on the Mobility Print server, such as another BYOD Printing solution that will listen on port 53.
*Make certain that Mobility Print has not been installed on a DNS server or Domain Controller.
*Verify that no other BYOD printing software is installed, or that the services have been completely stopped.

!!!Is there a proxy or content filter in between the clients and the server?
*This is rare, but we have heard of a few situations where managed Chromebooks were configured to pass through a content filter which was configured to drop DNS-SD or mDNS traffic.

!!!Examine the DNS records on the server to ensure they have been set up correctly.
*While testing, make sure that the DNS servers are fully replicated.
*After making any changes in DNS, be sure that you flush the DNS cache on the client before testing again. To flush the DNS cache in Windows, run "ipconfig /flushdns" in an elevated command prompt. To flush the DNS cache on MacOS open Terminal and run "sudo killall -HUP mDNSResponder".
*If the client has multiple DNS servers in their network settings, make sure the DNS server with the Mobility Print records comes first in the list.

!!Still not working?
We're definitely happy to help you troubleshoot the issue.

Please send us a few screenshots of the DNS Records created for Mobility Print as well as the Mobility Print logs. To download the Mobility Print log files, simply click on the dots in the top right of the Mobility Print admin interface and then select Download Logs.&#8232; Then feel free to contact your Authorized Solutions Center for assistance, or log into our [[https://support.papercut.com/hc/en-us/requests/new/|Support Portal]] to start a request.

----
[-Keywords: Mobility Print, Troubleshooting, Failed to retrieve printer list, DNS, Search Suffix, Search Domain-]

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on February 13, 2019, at 06:18 AM
Printable View   |   Article History   |   Edit Article