Large Shared Account Deployments
Last modified on 22 March 2016 10:41 AM
Since 15.3 there have been steady improvements in optimising how PaperCut handles Shared Account requests. This article is designed to be of a reasonably high level and help avoid any need to redesign after deployment.
When deploying a large volume of Shared Accounts, it is important to consider the scalability of the solution ahead of installation.This includes
Using an External Database
Any site with a large number of Shared Accounts (or users / devices) will see performance gains from using an external database. Using an external database will help future proof an install by providing scalability. For information please see: Upsizing to an External RDBMS
Decreasing Loading Times on the MFD:
Install or upgrade to v15.3 or later.he code for this has been further optimised to only load the required number of results needed for a request. The 15.3 update leads to considerable improvements in the loading time of a large number of Shared Accounts. The workflow has been improved to rely on the databases ability to sort and order large collections of data rather than perform these operations in memory ourselves. .
Optimising the Desktop Client Experience
When using Shared Accounts, the account list is downloaded to the Desktop Client from the PaperCut server if the list on the server is newer than the version the Desktop Client has (i.e., new accounts being added). This download is triggered in response to a print job. If the accounts list is updated on a regular basis, then this could lead to a delay in the client experience proportional to the number of accounts in the system, and increased network traffic during every print request.
While the list is in a compressed format, it can be a beneficial when dealing with 10’s of thousands of Shared Accounts to load this client list from a file shared on the network. The file approach is beneficial if you have a lot of clients on the network, instead of each client calling the database and querying the Shared Account list the call is made once and a file is created with the Shared Account list. You then configure the PaperCut client to watch this file instead of the main PaperCut database. This file can be distributed to remote sites as well to save traffic over a WAN link. This file creation can be scheduled so the account list is updated as often as the customer requires. We discuss the client file in more detail in the manual here: Managing Large Client Account Lists on Distributed Sites The additional benefit of this approach is that the PaperCut clients will import an updated file into the client before a print job is triggered, reducing the wait time for the user.
Please note - There is a minor limitation of using the client account file method. When the account selection popup is used, it will display all shared accounts regardless of user permissions. No need to panic, the PaperCut server still enforces the Shared Account security so users can only charge to the accounts they have permission to access.
Any successful deployment will require careful planning. The following documents should put any install off to a good start.
What Size Server Do I Need to Run PaperCut?
Shared Account setup suggestions:
While there is no right or wrong way to setup Shared Accounts a popular method is to use a parent and child structure as per the below screen grab.
Having the name and the code make searching for a Shared Account in a list much easier.
If we send a print job the client will display all Shared Accounts I have access to:
I can then filter this list by using the search box, in this example I searched for 2222 and it returned two sub (child) accounts that contain 2222 in their code. The client will also display the top level (parent) account so you can be sure the correct Shared Account is selected.
Shared Account Import and Export Options
There is a multitude of options for moving Shared Account lists between PaperCut and other sources. Out of the box (and via the intuitive Admin UI) there are options to import manually a file, as long as it is in a tab delimited format. The Admin UI also allows you to synchronise against a text file or a folder/directory structure; this is useful when a 3rd party application is creating the Shared Accounts you wish to import.
Taking the import a step further it is possible to use options such as SQL Server Integration Services (SSIS). Integrators can write custom SSIS package that takes their accounts lists (be it a CSV file, file structure or any format from any other database system). The SSIS package then calls the PaperCut XML Web Services API to perform checks so it can:
At the same time, it is possible to directly query the papercut database to help with this process.
It is possible to achieve this without using SSIS, for example, an .exe file or PowerShell script would give you much the same results. SSIS is a good option as it allows some control over the scheduling of the updates (perhaps they need to be every 15 minutes or only out of hours)
All the tools (API, server commands etc.) available work in a similar fashion. The Web Services option can be more responsive when running in parallel and has the advantage of not needing direct access to the PaperCut server file system
Regardless of the import option used it is vital the source data be in a format that PaperCut understands before it is imported, this may involve some manipulation during export. Other things to be aware of include; No two top level or sub-level (parent / child) accounts for the same top level Shared Account can have the same name. If there is to be a parent / child structure, then this must be explicit in the source data before import.