This type of environment is typical in larger businesses that have interconnectivity between their offices. With this type of setup, each office has the ability to connect and use resources from all offices.
The environment might consist of a central office, usually the company head office, and a range of smaller to larger offices around the state, country, or globe. All offices have constant direct connectivity back to the head office only via a VPN connection (commonly known as hub and spoke).
The other main setup for these types of customers involves all sites being connected with a constant direct connection between multiple sites. For example, a head office in Melbourne has direct connectivity with offices in Portland in Oregon, and Bracknell in England. There is also a direct connection between Portland Oregon and Bracknell England (full interconnectivity between sites).
Businesses of this size often have a mixed setup in their environments, with a number of their servers hosted internally and some SaaS solutions. These customers leverage the best of both worlds and only choose to move to SaaS solutions when they make the most sense in regards to security, flexibility, and cost.
Typical customers include:
- Universities
- medium to large businesses
- healthcare.
Recommended solution
There are a few different methods by which customers set up printing in these environments. The right solution for you depends on how you want printing to work.
Scenario 1: Allow anyone to be able to print and release to any printer in the organization
If you want all users to be able to print and release to any printer in the organization, you’ll want to allow edge nodes to communicate across all sites and subnets.
You need to ensure that you open comms between the edge nodes on your VPN connections. Check out our Firewall ports and networking webpage. This allows the edge nodes to transfer print jobs across the VPN to your other sites.
As a user, you will be able to submit a job from anywhere in your network and release the job to any printer in the network.
Scenario 2: Minimise VPN traffic/bandwidth
Many organizations run VPN connectivity for highly important internal systems, such as VOIP traffic, server redundancy, and database access. In most organizations, cross-site printing just doesn’t meet the brief, with organizations wanting to keep print jobs and printer communications local to each site.
If you want to limit the printing bandwidth across your VPN connection, look to allow edge node connectivity between subnets at each local site, but restrict edge node communications across the VPN link. You can find the edge node ports on our Firewall ports and Networking page.
You’ll still be able to allow site-to-site printing - just enable the cloud node in your environment.
For example, you print a job at site 1 and then attempt to release the job to site 2. The cloud node accepts the print job from site 1 and delivers it to an edge node at site 2, bypassing your VPN connection.
How printing with PaperCut Hive and Pocket works
For a summary of how printing works with PaperCut Hive and Pocket, take a look at the How it works page in the manual.
For a detailed look at the print job process and release print job process, including the ports and communications at each step, refer to The print process and The release print job process below.
Pros and cons
Pros | Cons |
---|---|
Users can easily move and print between sites - offers greater flexibility. | WAN traffic could increase due to communications between edge nodes, if allowed. |
More edge nodes could be available, using all sites, depending on network configuration. | If the WAN unreliable, it might introduce printing issues if the job is replicated to other sites. |
All devices can talk to the printers, making job routing simple and easy. | If edge nodes are used for print jobs at other sites, this might slow printing. |
Network diagram
Scenario 1 - Allow anyone to be able to print and release to any printer in the organization
Scenario 2 - Minimize VPN traffic/bandwidth
Ports
If you’re running the Full Embedded app, some platforms (MFDs) need additional ports to allow communications. For the complete list of ports, refer to Firewall ports and Networking .
The print job process
We are going to assume at this point that you have already read through the articles about getting your users joined to your print environment and that their computers or devices are configured to print. If you haven’t, read Getting started for administrators , which details the prerequisites and how to get your users set up.
Let’s now run through the process involved when a user prints in this environment.
Printing from Windows/Mac/Chromebook/Android
Action | Comms |
---|---|
1. The user submits a print job from their computer or device (client). | N/A |
2. PaperCut Hive or Pocket communicates to PaperCut Cloud Services and requests a list of available edge nodes to submit the print job to. | HTTPS/MQTT via Port 443 |
3. A list is returned. The client works down the list to find a suitable edge node (Win/Mac computer) to submit the job to and then sends it. | HTTP/S via Port 9263 (Chromebook) 9264 (Win, MacOS, Android) 9265 (Win, MacOS, Android) |
4. An edge node accepts the job from the client and contacts PaperCut Cloud Services to verify that the document has been submitted by a valid source. It then requests a list of available edge nodes to replicate the job to. | HTTPS/MQTT via Port 443 |
5. The edge node checks the list and delivers the job to an additional 2 edge nodes (Win/Mac computers) in the network. | HTTP/S via Port 9263 (Chromebook) 9264 (Win, MacOS, Android) 9265 (Win, MacOS, Android) |
6. The job is stored on these 3 edge nodes in an encrypted format using a multi-part encryption key to ensure they cannot be read. | N/A |
Printing from iOS devices
Action | Comms |
---|---|
1. The user submits a print job from their mobile device, which is connected to the local WiFi network. | N/A |
2. The PaperCut app on the mobile device communicates with the local super node(s) to submit the print job. | HTTP/S via Ports 9264, 9265 |
3. The super node accepts the job from the PaperCut app and contacts PaperCut Cloud Services to verify that the document has been submitted by a valid source. Then the super node requests a list of available edge nodes to replicate the job to. | HTTPS/MQTT via Port 443 |
4. The super node checks the list and delivers the job to an additional 2 edge nodes (Win/Mac computers) in the network. | HTTP/S via Port 9263 (Chromebook) 9264 (Win, MacOS) 9265 (Win, MacOS) |
5. The job is stored on these 3 edge nodes in an encrypted format using a multi-part encryption key to ensure they cannot be read. | N/A |
The release print job process
When it’s time for the end-user to release the print job, there are two different methods:
- MFD Release
- mobile device release.
MFD release
Action | Comms |
---|---|
1. At the MFD, the end-user uses the touchscreen to log in to PaperCut Hive. | HTTPS via port 443, plus potential additional ports brand specific |
2. PaperCut Cloud Services returns a list of available jobs for release. The jobs are displayed on the touchscreen. | HTTPS via port 443 |
3. The user selects the print job(s) they want to release, makes any modifications to the job, for example, sets double-sided, then selects Print. | HTTPS via port 443 |
4. PaperCut Cloud Services contacts the edge nodes on site to issue the job release command, specifying to deliver the job to the printer the user is logged in to. | HTTPS/MQTT port 443 |
5. The edge node holding the job tries to reach the specified printer. | SNMP 161/162 |
6. If the printer can be reached and the printing ports are available, the edge node sends the job to the printer via the configured delivery method (for example, IPPS), and the job is printed. | IPP/IPPS printing via ports 80/443/631 Windows print queue RAW 9100 |
Mobile device release - via cloud service
Action | Comms |
---|---|
1. The user launches the PaperCut Hive or Pocket app on their mobile device (iOS, Android), which contacts the PaperCut Cloud service looking for the user's print jobs. | HTTPS via port 443 |
2. The PaperCut app displays on the mobile device a list of print jobs ready for release. | HTTPS via port 443 |
3. In the app, the user selects the print job and makes any modifications to the job, for example, sets double-sided printing. | N/A |
4. In the app, the user selects Print Document, then selects the printer to output their job. (There will be various methods available depending on what the administrator has configured, for example, QR code.) | HTTPS via port 443 |
5. The cloud node contacts the edge nodes on site to issue the job release command, specifying the printer to deliver the job to. | HTTPS/MQTT port 443 |
6. The edge node holding the job tries to reach the selected printer. | SNMP 161/162 |
7. If the printer can be reached and the printing ports are available, the edge node sends the job to the printer via the configured delivery method (for example, IPPS) and the job is printed. | IPP/IPPS printing via ports 80/443/631 Windows print queue RAW 9100 |
Mobile device release - offline mode
If the link to the cloud services is unavailable, for example, your Internet Provider has gone offline, you can still release print jobs using your mobile device connected to your local WiFi. Here’s what the comms looks like.
Action | Comms |
---|---|
1. The user launches the PaperCut Hive or Pocket app on their mobile device (iOS, Android). The PaperCut Hive or Pocket app detects that the internet is offline (that is, it can’t reach the cloud node). The PaperCut app switches to looking for local edge nodes instead. | HTTPS via port 9266 |
2. The edge nodes send a list of available print jobs to the PaperCut app. | HTTPS via port 9266 |
3. In the app, the user selects the print job and makes any modifications to the job, for example, sets double-sided printing. | N/A |
4. In the app, the user selects Print Document, then selects the printer to output their job. (There will be various methods available depending on what the administrator has configured, for example, QR code.) | HTTPS via port 9266 |
5. The edge nodes communicate with each other to find the right node holding the print job to issue the release command. | HTTPS via port 9264 |
6. The edge node holding the job tries to reach the selected printer. | SNMP 161/162 |
7. If the printer can be reached and the printing ports are available, the edge node sends the job to the printer via the configured delivery method (for example, IPPS) and the job is printed. | IPP/IPPS printing via ports 80/443/631 Windows print queue RAW 9100 |
Comments