PaperCut MF badge scanning

A little-known PaperCut feature on translating and transforming card formats. Perfect if you’ve just built or rebuilt your PaperCut infrastructure

As part of a recent IT upgrade, I rebuilt our entire printing infrastructure. There were some issues with how it was previously built, so this was a good time to start from scratch. One of the issues was our PaperCut MF installation, of which I’ve documented our challenges on this blog this year.

We use the badge scanning feature of PaperCut on our two copiers for secure print release and accounting purposes. (It also helps me make the case to those who want a personal printer that they don’t need one!) But I found that the badge format might produce a different format than what you’re expecting.

The setting is buried in the Config Editor (Options > Config Editor) as ext-device.card-no-converter. Here are the various values:

  • ascii-enc: Unpacks an ASCII-encoded card value
  • hex2dec: Converts hexadecimal (base-16) to decimal (base-10)
  • dec2hex: Converts decimal to hexadecimal
  • javascript:[path] – At the path provided, uses a selected JavaScript code to convert a card’s read value into something else.

Hopefully this will help someone working through a new PaperCut MF installation. I’ll write more later about some of the things I’ve learned from rebuilding out PaperCut.

Sometimes we get it wrong

Stories from misadventures in rolling out a new printing system, or: Sometimes we get it wrong

Back in January, we started down the path of migrating from PaperCut’s on-premises solution to their fully cloudy PaperCut Hive. Whilst I was initially skeptical about it at first, it seemed like it had enjoyed success in larger organizations, so certainly it should work for a small nonprofit of ~30 people?

Oops. Also, [expletive deleted].

Sometimes we get it wrong. The rollout went about as well as it could go. I’m still frustrated by the fact I had to manually deploy the print client to our users and that the software wasn’t any sort of identity- or directory-aware. Getting a executable file that’s coded in the installer for each user? That’s not nice. Requiring administrative permissions to install that? Go away or I shall replace you with a very small shell script.

What ultimately doomed the rollout for me was that we had users who had sporadic and random issues. There were no common threads among those who had printing errors (other than, presumably, they were trying to print and the day ended in y), so troubleshooting was next to impossible.

Since printing’s kind of a mission-critical task where I am, we made the decision to abandon Hive and go back to MF. And I’m fortunate that I have supportive management and colleagues who understand that sometimes, you get it wrong.

Five Things for PaperCut Hive

A return of the Friday Five and some of my observations on PaperCut Hive, a software stack I’m currently deploying

Where I work, we’re almost complete with a migration from PaperCut MF on-premises to the fully cloud PaperCut Hive product. For the most part, I’m pretty pleased with how it’s gone and how it supports some of our organization’s transition goals to less on-premises. But there are some things that have been some definite head-scratchers in the process.

1. There’s no migration. That’s right: there’s no migration. Any data or user provisioning settings in MF don’t transfer over. You’re starting from scratch. Do you have RFID badges for your employees that they use to authenticate to the copier or MFP? Gone. Custom scan locations? Gone. While I’m thankful that I have a small number of colleagues and they have been more patient with me than I deserve, imagine if you have to have hundreds or thousands of employees re-authenticate on the new system. At least it’s a one-time only process.

2. There’s an app, but you don’t need it. PaperCut makes a big push to have users download their app for print management. I have issues with making people download company software to their own personal smartphones. Thankfully, even though PaperCut makes this push, you can ignore them.

3. Communicate early, often, and concisely. One of the questions I received a lot was about why we were doing this and how this would affect them. Fortunately, by planning the deployment, I was able to say that except for two initial tasks, everything would remain the same. And I told them why this change was being made, which was to support our organization’s future technology stack.

4. If you have multiple copiers/printers/MFPs, don’t move everyone over all at once. Keep both printing systems running in parallel so that you don’t have to sweat it having some users unable to use the printers and you have to rush the migration. By having some machines on the new system and some on the old system, you don’t have to be so aggressive in moving everyone over.

5. What automation? What year is it again? There is no way to use automated tooling to deploy PaperCut Hive software to our colleagues’ computers. To install the software, I had to go to each machine, download the unique software that PaperCut generates for each user, install it using my administrative credentials, and go on. That worries me, because that means the software is not directory aware and also means that I can’t include it in a base deployment configuration. While I’ve heard that this may change in the future, had I known this limitation, I would have postponed our deployment until later.

Those are some of my observations about this. It’s been received well by my colleagues, but some of the initial challenges made for a fun week.