Troubleshooting Printer Discovery with Mobility Print
KB Home | Troubleshooting Printer Discovery with Mobility Print
This was originally written by Aaron Pouliot on the PaperCut Support team, but you should know all of these steps have been incorporated into the Mobility Print Help Center. Eventually, this page may be retired or redirected to the new article in the Help Center.
“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?”
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 this article instead.
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.
Client DNS requirements:
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.
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.
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, 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.
Clients have the right settings, but still can’t see printers
Is the Mobility Print server able to verify all of the records?
If you see any red X’s when trying to verify your DNS records then compare them to these these examples to make sure they are set up correctly.
Can you confirm that at least one printer is being published?
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.
Were any changes made to the printer.conf.toml file to restrict printer access per subnet?
If so, remove these rules until printer discovery can be tested first.
If you are attempting to set up these rules, then have a look at the troubleshooting steps here.
Can you verify the ports are accessible and that clients can to access the Mobility Print server over the network?
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… 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.
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.
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.
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 DNS Record Examples knowledge base article for more details on how this works.
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.
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, run ipconfig /flushdns in an elevated command prompt.
To flush the DNS cache on MacOS open Terminal and run sudo killall -HUP mDNSResponder.
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:
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.
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. Then feel free to contact your Authorized Solutions Center for assistance, or log into our Support Portal to start a request.
This release contains an updated Java version which no longer supports 32-bit workstations. If you have any 32-bit users launching the User Client or Release Station from a network share, see this Knowledge Base article for more information.