Best Practices for Private Cloud Hosting

Organisations are increasingly looking to reduce the overhead incurred with managing their IT infrastructure locally, opting instead for cloud-based solutions that allow for critical services to be hosted remotely. Solutions hosted in the cloud broadly fall into two camps, each with its own unique benefits and possible drawbacks depending on your organisation’s needs:

1. Public Cloud
   The solution is hosted in a multi-tenant configuration managed by the solution provider, typically in a SaaS model (Software as a Service)

2. Private Cloud
   The organisation deploys and manages the solution themselves in a single-tenant configuration, using one or more servers provisioned from a cloud hosting provider

PaperCut offers two Public Cloud print management solutions, PaperCut Pocket and PaperCut Hive, which can eliminate the need for any managed on-site print infrastructure (well, besides those pesky printers). However, multi-tenant offerings like these may be unsuitable for some organisations, and others might require the extended feature set our more seasonsed products can offer. For those organisations, deploying PaperCut MF or PaperCut NG in a single-tenant Private Cloud configuration is a great option, with both having proven success in the field.

As we continue to see more of our customers opting for a cloud-based print management solution, and with many of them wishing to first test the waters with PaperCut MF or PaperCut NG in a Private Cloud model, there’s a growing need for guidance on how best to tackle the transition away from traditional on-site print management. This article will serve to compile and document various best practices, considerations, and caveats around PaperCut products and the Private Cloud. Watch this space, as we’ll be sure to add new learnings and topics as more and more of our users take the leap from cloud-curious to cloud-hosted!

Migrating to the Private Cloud

Migration of your PaperCut MF Applicaton Server from on-site infrastructure to a cloud platform host from a provider such as Google, Microsoft, or Amazon shares all of the same steps as migrating between two servers hosted on-site. The difference lies in the additional work you will undertake beforehand to ensure that cloud hosting is appropriate for your organisation, and afterwards to validate that your solution performs as expected now that it resides on remote infrastructure.

Things to Consider First

Before you begin planning such a migration, it’s wise to address the following questions:

If your location dictates that your internet connection is prone to outages or not particularly fast, then moving to a cloud-hosted solution may present problems. MFDs may occasionally behave strangely if their connection to the remote Application Server is unstable, and users may notice delays with print job submission and release.

With the PaperCut MF Application Server hosted in the cloud, an internet outage may prevent your users from printing until the outage is resolved. One way to mitigate this is to deploy a Site Server locally, but you may obviously wish to avoid doing so if the goal is to greatly reduce or fully eliminate the need for on-site infrastructure.

Secondary Servers or Direct Print Monitors hosted locally can be configured using failure modes to enable printing to continue in the event that the Application Server is unavailable, with print jobs being logged once connectivity is restored, but MFDs integrated with PaperCut MF may not be able to facilitate copying and scanning during any such outages.

With a sufficiently speedy and stable internet connection, it is often possible to host your print server/s in the cloud alongside your PaperCut MF Application Server. Print jobs will be routed from your user’s workstations over the WAN link to the remote print server, and then back to the physical printer at your site upon release.

Print job spool files can be quite large, however, so the utilisation of bandwidth for this purpose may prove costly dependent on your plan and Internet Service Provider’s policies. If your connection is not particularly quick, your users may also find that printing is not as responsive as it was with a local print server; their jobs may take more time to become available for release, and they might notice a delay between releasing a job and the printer physically outputting it.

If you wish to alleviate the strain on your WAN connection, or otherwise do not wish for your users’ print jobs to traverse the internet, you can continue to host your print server/s locally, with a Secondary Server deployed to communicate print job details to the remotely hosted Application Server, and enforce any print policies accordingly.

If print servers are amongst those pieces of locally hosted infrastructure you’d like to free yourself from, another option is to switch to using our Direct Print Monitor, most easily used in conjunction with Print Deploy. With these features, print jobs can be kept local to a user’s workstation throughout the entire print and release workflow. This will prove a significant change in architecture if you have up until this time relied upon a traditional print server and client model for printing, so please carefully revise the documentation available to ensure it suits your needs!

It is imperative that a VPN or VLAN is configured to secure communications between your cloud-hosted server/s and the local MFDs and workstations, as some proportion of the network traffic involved in your solution solution may otherwise traverse the public internet in an unencrypted format, exposing private data to prying eyes.

PaperCut MF’s satellite solution components largely ensure that extremely sensitive data is only ever transmitted in an encrypted format, protecting it from such unwanted observation even within your local network; for example, passwords for authentication purposes will never be exposed in cleartext. However, without the use of a VPN or segregated network connection, some data might be able to be extracted from packets transferred back and forth between the local and remote solution components.

If print jobs themselves are kept local, this data could include elements such as usernames, document names, and internal network IP addresses. If print jobs themselves are routed over the public internet, and the print protocol used is not encrypted, the contents of printed documents themselves could be exposed. It is therefore strongly recommended that you only proceed with a Private Cloud solution if you are able to employ a VPN or similar method to safeguard all user data as it moves between endpoints.

Thankfully, common cloud hosting providers are geared towards this exact style of use, with the intention to make any remote servers simply appear as though they were joined to your local network. It is very much possible, not to mention expected, to have your Private Cloud deployment as secure in pratice as a locally hosted equivalent!

Preparation Checklist

Our server migration planning guide should form the basis of your Private Cloud migration plan, as it lays out everything you might need to consider when moving your PaperCut Application Server from one host to another:

Plan your PaperCut Application Server Migration

After all, with the right architecture, a server hosted in the Private Cloud is effectively the same as the one in your server room. However, we recommend these additional checks and basic tests be performed prior to any planned migration of solution components onto Private Cloud infrastructure in order to validate that what you’ve got is, in fact, the right architecture!

These should be performed prior to the beginning of the Preparation Checklist found in our gold-standard Server Migration guide:

1. Inform your PaperCut partner

If you’re running PaperCut MF, it’s always a good idea to inform your PaperCut partner of any potential major changes to your architecture. They are often intrinsically involved in a site’s original deployment, and may be privvy to specifics about your implementation which need special consideration in a cloud environment. You can find your PaperCut partner’s contact details in the PaperCut MF Admin web interface by first heading to the About tab and then scrolling down to the Support section of the page.

2. Test impact of change in latency and throughput

If you intend to have your print server reside in the cloud, testing of general print responsiveness is advised. From a laptop, submit a large print job via your on-site print server to a queue that points to an MFD you can observe directly. For this test, Hold/Release should be disabled on the print queue, such that the job moves from the workstation to the print server and on to the MFD without halting for user interaction. Time how long it takes for the print job to start being physically output at the MFD.

Now, connect the same laptop and MFD to the VPN or VLAN to which your cloud-hosted server/s are connected. Add a print queue on the cloud-hosted server that points to the MFD, and share this print queue with the laptop. Submit the same large print job as before, again timing how long it takes for the MFD to begin outputting pages. If there is a significant difference in the time taken when the large job is routed via the cloud-hosted server, you will need to consider if the delay incurred will be acceptable under general use.

3. Preflight your commonly used features

Install a copy of PaperCut MF to the Private Cloud server, and setup a basic equivalent of the set of features you intend to use with your migrated instance. This allows you to test that each of the features behaves as expected when provided remotely. For example:

• Check to ensure that the Admin and User web interfaces can be reached from a workstation, to validate that the requisite Firewall Ports used by NG & MF are open between the local and remote machines
• Try to integrate one of your MFDs with the cloud-hosted Application Server, and ensure the functionality commonly used still works as expected
• Check that you can still synchronise users and groups from your configured synchronisation sources

Your PaperCut partner can provide you with a PaperCut MF installer package for this testing. A trial copy of PaperCut NG can also be used, albeit without the ability to test integration with your MFDs.

4. Confirm satellite solution components can communicate

Your Application Server may be facilitating a number of satellite solution components, and we’ll need to be sure they can each successfully interact with a cloud-hosted equivalent. Some examples include:

• Site Server
• Secondary Server
• Integrated MFDs
• Direct Print Monitor
• User Client
• Print Deploy Client
• Mobility Print Server
• Mobility Print Client

Although our standard server migration guide covers tests for such components, and we provide other articles for both MFDs and general components that deal with a potential change in server hostname or IP address, it’s a good idea to confirm early in the process that the introduction of a VPN hasn’t brought along unexpected network segmentation or blocked ports.

If you’re continuing to use any of these components on your local hardware, or perhaps even on other cloud-hosted servers (e.g. an external database server), try setting up a new instance of it that points to your test Application Server in the cloud. Any errors encountered could lead you right to a network limitation that our Firewall Ports used by NG & MF article can then help you address.

Post Migration Considerations

The post migrations considerations for a cloud migration are much the same as for moving between two locally-hosted servers, but you might wish to extend the period of observation, and take special care to gather feedback from users concerning any changes to performance or their general experience with the solution.

Other Resources

• Plan your PaperCut Application Server Migration
• Wide Area Networks (WAN) Considerations