Creating a Test Environment

What do I need to keep in mind when creating a test environment?

There’s a few things that come up when looking at creating test systems - whether you’re creating the test system from scratch, or when you’re creating a clone of your current system in order to test something out!

This article runs through what to keep in mind from the network side of things and also down to the PaperCut settings configured on your test instance.

Some ground rules:

• A PaperCut database has to be unique per Application Server - so you can’t set up a test App Server and have it point to the same database as your production setup. You’ll need to set up another test database - or just use the built-in ‘derby’ database.
• Print providers can only talk to one Application Server at once, so you won’t be able to point your Production Print Server to your test App Server to generate test data (if you do, that means that the data will no longer be recorded on your Production Application Server).
• PaperCut clients can only talk to one Application Server at once, so make sure you change the server/IP address settings in the ‘config.properties’ files to point a test client to your test App Server.

What do I need to keep in mind when importing my production database into the test environment?

The database for PaperCut contains a whole host of data tables and configuration settings. This is great because it means that if your Application Server suffers a hardware failure of some kind, or some other failure - then you can get a new Application Server up and running pretty quickly.

However, that same simplicity can cause problems if you have two instances of that App Server on the same network.

You can head over to the System Backups section in the manual to see how to take a system backup from your production server (pick a quiet time to do the backup - just in case!). Then take a look through the Restoring from Backup article to see how to restore that backup to your new test system.

There are at least 3 different options for how to set up your testing environment with imported data:

Option 1 (best option) - no network connectivity

If you only want to test something that doesn’t need the App Server to communicate with other devices/services, consider restoring the database to a machine that doesn’t have network access. That way all your testing is sandboxed and there’s no chance of your test server interfering with other production services.

Option 2 (next best) - use a separate test network

This is a network which doesn’t have access to the servers, devices, printers or domain and email services available in your production environment.

It’s highly recommended to restore your production database to an App Server that doesn’t have network access to begin with. For physical machines, unplug the network, or put the machine onto a different network from your production environment. For Virtual Machines, temporarily disable the network adapter while you perform the import and configure the test App Server.

Once you’ve restored the database, and you’ve logged into your test Application Server, you’ll want to:

• Disable your Notifications, under Options → Notifications → SMTP Server Options, depending on whether you want notifications or emails to come from your test server at all. If you’re setting up a test server in a semi-permanent state, it’s worth setting up a dedicated test email address for your test server, so anyone receiving emails knows that it’s from the test system.
• Stop any scheduled reports, by deleting any scheduled reports under Reports → Schedule / Email Reports. You don’t want any confusing reports from a test system going to production users.
• Stop any Google Cloud Print Integration - head into Options → Mobile/BYOD → Google Cloud Print and uncheck ‘Enable Google Cloud Print integration’. You don’t want your test server falsely publishing printers to your users, or worse - interfering with the online/offline status of your production Google Printers.
• Stop any Email to Print Integration - head into Options → Mobile/BYOD → Email to Print and uncheck ‘Enable Email to Print integration’. You don’t want your test server logging into your Email to Print production email box and trying to process production print jobs.
• Disable your Sync Source - under Options → User/Group Sync - depending on whether you want your test system sync’ing with whatever cloud-based or on-prem directory source that you have. Normally this won’t be an issue, however if you have to use a highly restricted service account to be able to access your directory, you may not want to configure that on your test server - and so the sync’s will fail.

Do not connect the network adapter to your test server until you’ve done those steps, and you’re happy that you’ve disabled all the services which you need to.

Option 3 (if you really must) - a test server on your production network

This is a network where your test server can access your production servers, devices, printers and email and domain services.

It’s highly recommended to restore your production database to an App Server that doesn’t have network access to begin with. For physical machines, unplug the network, or put the machine onto a different network from your production environment. For Virtual Machines, temporarily disable the network adapter while you perform the import and configure the test App Server.

Once you’ve restored the database, and you’ve logged into your test Application Server, you’ll want to:

• Disable your Notifications, under Options → Notifications → SMTP Server Options, depending on whether you want notifications or emails to come from your test server at all. If you’re setting up a test server in a semi-permanent state, it’s worth setting up a dedicated test email address for your test server, so anyone receiving emails knows that it’s from the test system.
• Delete your embedded devices, under the Devices tab. If you spin up a new Application Server trying to manage the same set of devices, the test App Server will try and manage and ‘take over’ those production devices.
• Delete your Site Servers from the Sites tab. The communications for Site Servers are done from the Site Server to the App Server - so in theory this shouldn’t make a difference, but better safe than sorry.
• Stop any scheduled reports, by deleting any scheduled reports under Reports → Schedule / Email Reports. You don’t want any confusing reports from a test system going to production users.
• Stop any Google Cloud Print Integration - head into Options → Mobile/BYOD → Google Cloud Print and uncheck ‘Enable Google Cloud Print integration’. You don’t want your test server falsely publishing printers to your users, or worse - interfering with the online/offline status of your production Google Printers.
• Stop any Email to Print Integration - head into Options → Mobile/BYOD → Email to Print and uncheck ‘Enable Email to Print integration’. You don’t want your test server logging into your Email to Print production email box and trying to process production print jobs.
• Disable your Sync Source - under Options → User/Group Sync - depending on whether you want your test system sync’ing with whatever cloud-based or on-prem directory source that you have. Normally this won’t be an issue, however if you have to use a highly restricted service account to be able to access your directory, you may not want to configure that on your test server - and so the sync’s will fail.

Do not connect the network adapter to your test server until you’ve done those steps, and you’re happy that you’ve disabled all the services which you need to.

Still have questions?

Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.