Troubleshooting printer discovery problems in a DNS environment
“Help! I’ve set up 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?”
- On a Windows client I see the error message "Failed to retrieve printer list. Do you want o retry?"
- Make sure clients have the correct DNS settings
- If clients have the correct settings
- Check your DNS records
On a Windows client I see the error message 'Failed to retrieve printer list. Do you want to retry?'
If you're using Windows clients, run the 'Mobility Print Printer Setup installer' file and see the error message: Failed to retrieve printer list. Do you want to retry? follow the checks on this page to troubleshoot the problem.
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 correct DNS settings. Here's where you'll find the settings:
- Windows: Network Connections > IPv4 > Properties > Advanced > DNS Tab
- MacOS: System Preferences > Network > Advanced > DNS Tab
- iOS: Settings > WiFi > select the network > Configure DNS
- Chromebooks: From any Chrome tab, go to chrome://system. In the left column, find network-status; then click Expand. Under IPConfigs, find the NameServers and SearchDomains attributes.
- Android: It’s possible to check the DNS server.
Confirm:
- the DNS Server IP address is correct
- the DNS Search Suffix (also known as the Search Domain) exactly matches the Forward Lookup Zone where the Mobility Print records were created.
For example, “pdx.papercutsoftware.com” is not the same as “papercutsoftware.com”
If clients have the correct settings
Check the Mobility Print server is able to verify all of the records
When verifying your DNS records in the Mobility Print Admin interface, if you see any red Xs on the Configure DNS screen, then compare them to these examples to make sure they are set up correctly.
Confirm that at least one printer is being published
Log in to the Mobility Print Admin interface. 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 on the print server that has Mobility Print installed.
- If at least one print queue is installed, in the Mobility Print Admin interface click Select printers and toggle the printer to ON.
- If there are no printers published, install a print queue on the print server where Mobility Print server is installed.
Mobility Print will ignore any shared print queues from another print server.
Make sure theMobility Print server is installed on the print server that has the required print queues.
If you have subnet filtering, check that the changes made to the printer.conf.toml file are not causing the problem
Remove the rules from the file and check if printer discovery works. If it doesn't, subnet filtering is causing the problem. Have a look at Troubleshooting subnet filtering.
Verify the clients can access the required ports on the Mobility Print server
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.
TCP Port 53 warrants a special note. It might be blocked because before the days of DNSSEC it was commonly advised to block this port to prevent all of the DNS records on a server being disclosed through a zone transfer.
On your Mobility Print server, TCP Port 53 must be open because DNS uses this port for any packet over 512 bytes. If the port is blocked, then it’s possible to share one or two printers using Mobility Print, but when a larger number of printers are shared, printer discovery will fail.
Check for conflicting applications on the Mobility Print server
Make certain that Mobility Print has not been installed on a DNS server or Domain Controller, for example another BYOD printing solution that listens on port 53 or the DNS server role.
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 no other applications are using ports 53 and 5353.
Check if there is a proxy or content filter between the clients and the Mobility Print server
This is rare, but there have been a few situations where managed Chromebooks were configured to pass through a content filter that was configured to block DNS-SD or mDNS traffic.
Check testing is being done with the most up-to-date version of the DNS records
- While testing, make sure that the DNS servers are fully replicated.
- 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.
- 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, in an elevated command prompt run ipconfig /flushdns.
- To flush the DNS cache on macOS open Terminal, run sudo killall -HUP mDNSResponder.
- To flush the DNS cache on Chromebooks, in the Chrome browser address bar type chrome://net-internals/#dns, then click Clear host cache.
Check the client can connect to the Mobility Print server
Try opening a web browser on a client, and make sure 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 Mobility Print server over the network and that port 9163 is open. The correct output is a list of printers, or a JSON file containing a list of printers.
- If this is inaccessible, then it suggests that 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 tests to ensure 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. Take a look at Configure printer discovery using DNS.
Check your DNS records
If your Mobility Print server isn’t able to verify the DNS records you set up, then here are some things you can try to test your configuration.
You can use a DNS check tool (for example, dig or nslookup) to verify some of the key DNS records. If you don't know how to use the tools, find that out before you continue here.
Below is an example set of commands, their expected output, and the steps for how to perform the checks.
Click on each box in the diagram below to go to the steps that guide you through the process.
Test the IPPS pointer records (DNS server)
Command:
OK:
Error:
Test the Browse record
Command:
OK:
Error:
Test the Legacy Browse record
Command:
OK:
Error:
Test the IPPS pointer records (Mobility Print server)
Command: (10.100.64.35 is your Mobility server)
OK:
Error:
Test the NS record
Command:
OK:
Error:
Test the A record
Command: (mobility is your Mobility Print server's hostname)
C:\>ping mobility.myorg.com
OK:
Error:
or
Check the Client Search Domain
Make sure the zone to which you have added the records matches the search domain your clients get from DHCP. To see what search domain is configured on your clients:
-
On iOS clients:
- Go to Settings > Wi-Fi.
- Click the (i) icon next to your Wi-Fi connection name.
-
On windows clients:
-
Open a command prompt and run
ipconfig /all
-
Locate the search domain under one or more of the headings below:
- Primary DNS Suffix
- DNS Suffix Search List
- Connection-specific DNS Suffix
-