Knowledgebase: PaperCut > Troubleshooting
When PaperCut Published Google Cloud Print Printers Show as Offline
on 19 August 2020 11:53 PM

We have an alternative to Google Cloud Print, check out PaperCut Mobility Print. It provides you a simple way to print from your Mobile & BYOD devices like iOS, Android, ChromeOS, Windows and MacOS. There’s a migration article over here

What to do when PaperCut-published Google Cloud Print printers show as offline

Sometimes you might notice that Google Cloud Print printers published through the PaperCut admin console show as offline to users trying to print from the Chrome browser or Chromebooks. There are a few network-related things we think you should check that have proved to have an effect on the way PaperCut publishes printers and delivers print jobs from the cloud.

Does your organization use Securly DNS filtering services?

If so please take a look at the KB article they published that addresses proxy issues with GCP here: In one instance we discovered the workaround of assigning the PaperCut app server a static IP and pointing it to a different DNS server entirely. Not that there’s anything special about or, but in this case, the primary method of delivering content filtering was through DNS and telling the server to resolve through an unfiltered DNS server was the most expedient way to verify PaperCut was bypassing the filter.

Another instance of offline GCP printers came down to rules in a customer’s Fortigate firewall, which could be relaxed. In that case, their Fortigate device was also facilitating DNS and content filtering on-top of other intrusion protection stuff.

Adaptive network security appliances and services

Keep in mind that PaperCut’s GCP implementation requires an ‘always-on’ connection to GCP services in the cloud. To some adaptive network security appliances and services, this looks like a compromise in security, so it gets shut down. Your security services should be able to produce a log that can identify these events; a packet capture tool like Wireshark can help too. The suggestion here is to whitelist communications on the following ports and between the PaperCut server and these remote hosts:

443 TCP (HTTPS), with connections to:


5222 TCP (XMPP, using STARTTLS), with a persistent connection to:


By default, this needs to be achievable without the use of a proxy, unless that proxy is “transparent” on TCP ports 80 and 443, and requires no authentication. If running version 17.3 or later of PaperCut, a proxy server which is not “transparent” may be able to be configured using the instructions found in this section of the User Manual .

Inappropriate content sharing among students

Along these lines is something described by an educational customer regarding user restrictions on the network. At one point a packet shaping implementation had been put in place to intercept XMPP/Jabber traffic to prevent inappropriate content sharing among students. XMPP happens to be the same protocol that Google Cloud Print uses to perform printer discovery and authentication management with PaperCut. What we learned from this scenario is that If XMPP is traffic is restricted, then PaperCut will not be able to perform printer discovery and authentication management. In this case, the symptom was that the customer had a persistent issue with their Google Cloud Printers showing offline.

Re-publishing and re-sharing printers to your organization

Finally, as another customer related, re-publishing the printers helped get them back “online”. However, sharing several dozens or hundreds of printers to your districts, staff, faculty, and students can be a daunting task. This customer was able to leverage the open-source Google Apps Manager command line tool to export the Google printer IDs and concatenate with the user groups to more expediently share printers to the organization than through the default GUI method. That topic is covered on the project’s GitHub and in KB.